LATEST / 2026
SEPTEMBER · SQL pipelines get a wider lensAUGUST · DAGSmith preprint releasedMARCH · Mozafari continues at Keebo as co-founder and board member

People / Barzan Mozafari / Computing & consequence

Barzan Mozafari and the art of doing less

He learned algorithms before he owned a computer. From database research to Keebo and self-verifying AI, Barzan Mozafari has kept asking how much work a machine can spare its user.

Before Barzan Mozafari owned a computer, he had a keyboard made of paper. Growing up in Iran, he learned algorithms in fifth grade. Later, preparing for a competitive informatics examination, he copied a keyboard layout from a book and practiced finding the letters. He could devise a solution. Getting his fingers to deliver it was another matter.

He has recalled earning a silver medal despite that obstacle. His school friends had already supplied a nickname: Professor. The title arrived rather early; the computer, rather late.

Years later, Mozafari would help build software that asked a related question from the opposite direction. Once people have the machine, why must they spend so much time accommodating it? Why wait for a query, nurse a database through a slowdown, or keep adjusting the size of a cloud warehouse? A computer can be remarkably efficient at giving its owner another job.

His career has moved through university laboratories, open-source software, and Keebo, the company he co-founded. Across those settings, he has studied ways to reduce the effort required to get useful work out of data systems. The subject sounds dry until the monthly bill arrives. Then everyone develops an interest in databases.

A little uncertainty, delivered promptly

Mozafari earned his undergraduate degree in computer engineering at Shahid Beheshti University in 2006, followed by a master’s degree at UCLA in 2008 and a computer science Ph.D. there in 2011. He spent the next two years as a postdoctoral associate at MIT’s Computer Science and Artificial Intelligence Laboratory. In 2013, he joined the University of Michigan.

Among the projects from that period was BlinkDB, developed with collaborators including Sameer Agarwal, Aurojit Panda, Henry Milner, Samuel Madden, and Ion Stoica. Its proposition gave analysts a choice: specify an acceptable error bound or a response-time limit when asking questions of very large datasets.

A bounded approximation can be useful when the alternative is waiting too long for an exact calculation. The word “bounded” does considerable work here. A quick guess offers little comfort. An answer accompanied by an explicit account of its uncertainty gives the person using it something to judge.

BLINKDB / TWO WAYS TO ASK
Time budgetHow quickly do I need an answer?
Error budgetHow much approximation can I accept?
Put a boundary around the bargain. Conceptual illustration of BlinkDB’s query controls.

The BlinkDB paper won the EuroSys Best Paper Award in 2013; the work later received the conference’s Test-of-Time Award in 2023. Mozafari helped commercialize its ideas through SnappyData, which TIBCO acquired in 2019. The sequence matters: an academic result became part of a business, and its usefulness had a life beyond the original paper.

VerdictDB carried approximate-query processing into another setting. Rather than requiring an analyst to move everything into a special engine, it worked as a layer over existing systems. Its published evaluation covered engines including Impala, Spark SQL, and Amazon Redshift. The practical question was how to bring an idea to the software people already used. Elegant research still has to get through the door.

The expensive habit of being ready

At MIT, Mozafari also worked on DBSeer with collaborators including Carlo Curino and Samuel Madden. The problem was less glamorous than making a computer sound clever: predicting what a database would need and how it would behave.

Consider a service provisioned for its busiest moment. That arrangement offers reassurance, but it can leave resources underused during quieter periods. Being ready for every possible rush has a cost, even while the rush is elsewhere. DBSeer used workload and performance observations to build models of resource demand.

The distinction between an observed pattern and a large change in demand was central. Learning from familiar behavior helps with familiar situations. Predicting beyond that range calls for knowledge of how the database itself works. The project explored both statistical correlations and models informed by the system’s internal behavior.

This research addressed the ordinary questions that become urgent when an application slows: what changed, which resource matters, and what would happen if demand increased? Later work, including DBSherlock, examined the diagnosis of performance anomalies. The project names have a modest sense of theater. Prediction gets a seer; troubleshooting gets a detective.

Mozafari’s 2016 NSF CAREER award supported research into predictable databases. Predictability is an easily overlooked virtue. A system that is fast on average can still leave people waiting at precisely the moment they need it. The variation, as well as the average, deserves attention.

The professor picks a problem

Michigan supplied another kind of work: helping people choose what to investigate. Mozafari’s published mentoring plan describes a hands-on approach early in a student’s Ph.D., followed by greater autonomy as the student develops experience. He plans weekly individual meetings and group meetings in which students present progress and obstacles.

“Where I think I add the most value to my students is in helping them pick good problems.”

Barzan Mozafari, on doctoral advising

Choosing a problem is consequential work. A technically difficult question can absorb years without producing something anyone needs. A useful question gives the difficulty a purpose. In 2019, the university’s promotion recommendation described Mozafari’s teaching as accessible and patient, and recorded research collaborations and work adopted by database vendors.

One of those academic relationships became a business partnership. Yongjoo Park completed his Michigan doctorate in 2017 with Mozafari and Michael Cafarella as advisers, then worked as a research fellow with Mozafari. Park’s professional record dates his Keebo co-founder role to August 2019.

IDEAS WITH A SECOND LIFE
2013BlinkDB paper; Michigan faculty appointment
2019SnappyData acquisition; Keebo co-founded
2026Keebo board role; GenRewrite and DAGSmith

The connection puts a human scale on the phrase “academic commercialization.” Here were people who had already worked together on databases, carrying a research relationship into a company. The collaborations are part of the story, because the systems are collaborative work too. A founder’s biography can make the supporting names vanish rather too conveniently.

An iPad nobody had to buy

Keebo applies data learning to cloud warehouse optimization. It observes how workloads use resources and adjusts settings to improve the relationship between performance and cost. A warehouse sized appropriately for one stretch of the day may be an expensive choice for another.

In a conversation with Alteryx’s Megan Bowers, Mozafari described four barriers to adopting AI: implementation, maintenance, security, and return on investment. His account of Keebo emphasized designing around those barriers from the beginning, including learning from metadata rather than accessing the customer’s underlying data.

He also described a company joke with a measurable condition. If implementation needed more than 30 minutes of a customer’s time, Keebo would send an iPad. At the time of the conversation, he said, they had never needed to buy one. It is an unusually tangible way to express a software ambition. Somewhere behind the promise sits a purchasing department with nothing to purchase.

Barzan Mozafari speaking onstage at Databricks Data + AI Summit 2026
Plenty of stage, fewer knobs to turn. Mozafari presenting at Databricks Data + AI Summit 2026. Photo: Keebo.

In March 2026, Keebo appointed Eric Shoemaker chief executive. Mozafari remained a co-founder and board member. The announcement assigned Shoemaker responsibility for expanding enterprise adoption, partnerships, and go-to-market operations. Mozafari’s role had changed; the company’s focus on the economics of data infrastructure continued.

The next step costs more. The whole journey costs less.

His recent research turns from the resources surrounding a query to the query itself. GenRewrite, developed with Jie Liu and appearing at SIGMOD 2026, uses large language models to propose SQL rewrites. It retains lessons as natural-language rewrite rules and uses counterexamples to iteratively correct errors.

The point of rewriting is to express the requested computation in a form the database can execute more efficiently. Correctness remains part of the job. A fast query returning a different answer has merely arranged to be wrong sooner.

DAGSmith, a 2026 preprint by Liu, Lin Ma, and Mozafari, widens the frame to entire SQL pipelines. These pipelines contain dependent steps, with one result feeding later calculations. The system considers opportunities to reuse work, change what gets stored, and adjust when computations run.

DAGSMITH / ONE REPORTED EVALUATION

Less work on the meter

Elapsed time
-42.6%
Compute cost
-67.7%
Reported reductions on the open-source Tuva dbt project. Bars show the share remaining relative to the original pipeline. Research results, not a forecast for other workloads.

In September 2026, Mozafari explained a counterintuitive consequence: an intermediate query can become slower while the whole pipeline finishes faster. If its extra output saves enough work downstream, the apparent setback pays for itself. Measuring one step alone can reward the wrong improvement.

There is a limit to the checking. His explanation says DAGSmith tests rewrites against the project’s data and does not guarantee equivalence for every possible input. Users still need review or their existing testing process before deployment. The research aims to reduce work while keeping the remaining responsibility visible.

Who checks the checker?

Mozafari’s current agenda also includes self-verifying AI. The concern is what happens when a person can describe a desired outcome without anticipating every requirement. An AI system must fill gaps. Its assumptions can be mistaken even when the finished result looks plausible.

Checking that result can become a second task, handed back to the user who asked for help. His research asks how systems might verify and improve their own behavior. It extends the question beyond databases to the burden of supervising software that acts on incomplete instructions.

The continuity is striking. Approximate analytics makes uncertainty explicit. Performance models make resource decisions less opaque. Pipeline optimization asks whether a local improvement serves the whole job. Verification asks whether the job was the right one in the first place.

The paper keyboard could not execute anything. It helped a student prepare for the work a computer required of him. Mozafari’s later projects keep examining how that requirement might shrink. Faster answers are useful. So are smaller bills. There is also the quieter achievement of giving someone fewer things to tend.

Follow the work