DuckDB's creator tells LDS why SQL won

DuckDB's founding idea, Muhleisen said, was one the database field treated as beneath it: that a database should be pleasant to use.

"The bet was that user experience is a legitimate design concern for a database system. That sounds too obvious to say out loud. It was not the consensus," he told Lets Data Science. "The field, the academic research community and industrial practitioners alike, optimised for benchmark numbers and for features you could put in a paper. Whether anyone would enjoy using the thing was nobody's department."

That priority came from watching data scientists suffer. The team had spent time with the R community, he said, and "found a room full of people who loved working with data and hated databases. Not the theory. They hated the install, the server process, the connection string, that process of asking your sysadmin for permission." The architecture followed from the requirement: "If setup has to be one install command, you don't get to have a server."

He was wrong about one thing. "I thought this would be a short project. We create a prototype, write a paper, then we can go back to doing more research. Mark and I then spent years of evenings and weekends on it. It turns out that SQL is far larger from the inside than it looks from the outside."

DuckDB runs in a single process on a laptop, a design that cuts against a decade of big data orthodoxy. Asked where a data scientist in 2026 still needs distributed systems, Muhleisen pointed at public evidence rather than opinion.

"This isn't opinion anymore, because the traces are public. Snowflake and Amazon both released real workload data from their fleets," he said. "The typical analytical query is small, comfortably fits within one machine, and the queries that truly need a cluster are a fraction of a percent."

He does not dispute that the tail is real. He disputes who the industry chose to serve. "If you're in that tail, you need distributed systems and I won't pretend otherwise. But notice who is in the tail. Organisations at that scale have the budget and the engineers. They were never the ones who needed help." The error, he said, was structural: "The mistake the community made, including the research community where I used to sit, was to spend twenty years building almost exclusively for that tail."

Asked what database people and dataframe people misunderstand about each other, Muhleisen split the blame evenly. Dataframe users, he said, miss the query optimizer: "In pandas you wrote the plan. Every filter position, every join order, every materialised intermediate was a decision you made without knowing it was one. In SQL you state the result and something else spends real effort deciding how."

The database world's failure was its own, and he claims it. "We spent forty years making queries fast and almost none making it fast to get the answer out. The client protocols were designed in the eighties for a few rows at a time and were never revisited," he said. "Then we were mystified that data scientists didn't want to use databases. They weren't wrong."

DuckDB also runs inside the browser through WebAssembly. Muhleisen frames the server model it displaces as an absurdity.

"Everyone interacting with a database already has a computer. It likely has many cores and a lot of memory and it is doing essentially nothing while they look at a dashboard," he said. "We required organizations to rent a second computer, in a data centre, for each of their people, so they can click around."

His ambition for client-side analytics is a level of speed the field stopped asking for. "We should be talking about dashboards at video-game frame rates, where you drag a slider and the chart moves with your hand. Instead we've spent a decade accepting ten-second responses." Because the data never leaves the machine, he added, "a hospital or a statistical office can hand someone a real analysis tool without their data crossing an organisational boundary."

His closing instruction on the subject was blunt: "The assumption I'd most like to kill is that the browser is where you put the toy version. It should be the same engine."

Asked what comes next, Muhleisen was candid about withholding. "The thing I'm most excited about is the thing I can't talk about yet. We expect to launch it this year."

In its place he offered something that breaks his own founding rule. "We recently shipped Quack, which gives DuckDB full client/server operation. The example that makes it click is a fleet of servers writing observability events into one central DuckDB with real transactional guarantees. That is not the workload anyone had in mind when we said in-process analytics."

He knows how that reads. "You could read that as a contradiction. DuckDB exists partly because client/server databases were miserable to use." He accepts it, because the alternative was dogma. "Refusing on principle would have meant telling those users that our self-image mattered more than their work."

Which returns him to the first answer. "Putting the user first isn't a slogan you adopt once and then defend. It keeps costing you things, including the architectural purity that we prided ourselves on."