Someone on the team asked me a few days ago: we are a learning company, what do we care about database speed?
Fair question. My answer was that this is not an infrastructure question. It is a question about who is allowed to ask.
DuckDB shipped a preview of its 2.0 release this week. The headline features matter less than the shape of the thing: an analytical database that runs in-process — no server, no cluster, no ticket you open so somebody can provision something for you — and answers a question about a few hundred million rows before your attention runs out.
That last clause is the whole story. Not the benchmark numbers. Not the SQL dialect coverage. The response time.
The corner shop and the wholesale market
Think about the shop at the end of your street.
You walk down there for one onion. You do not plan it, you do not make a list, you do not ask yourself whether one onion justifies the trip. Two minutes and you are back.
The wholesale market is cheaper and bigger and has everything — but you do not drive there for an onion. You go when you have accumulated a full list that justifies the forty minutes.
And there is the real difference: the corner shop lets you buy what you need right now. The wholesale market lets you buy what you can justify.
Queries work exactly the same way.
When a query takes a day, the only person who runs it is the person whose job the query is. They batch their questions because each one is expensive, and they ask the questions they can justify to somebody else.
When it takes ten seconds, the person who actually has the question runs it themselves. And then — this is the part that matters — they run the follow-up.
The follow-up is almost always the one that mattered. The first question is rarely the real question. The first question is the one you knew how to ask before you saw any data.
The threshold nobody designs for
Interface researchers have been describing this for forty years, and organisations keep rediscovering it.
Below about a second, the system feels like an extension of your thinking. Around ten seconds, you stay on task but you stop exploring. Past a minute you switch context, and the question you were holding in your head evaporates along with the rest of your working memory.
What gets lost at each step is not throughput. What gets lost is the chain — the third and fourth question that only exist because the second one surprised you. Nobody schedules a chain of exploratory queries. They either happen or they do not.
So a tool that moves a workload from four minutes to four seconds has not made analysis 60x faster. It has made a category of analysis possible that previously did not occur at all. Those are two very different claims, and only the second one shows up as an organisational capability.
(Illustrative, not measured data. The shape is the point: exploration collapses long before anyone would call the system slow.)
What this has to do with company memory
We spend most of our time thinking about how organisations hold on to what they know and how they pass it on. So this pattern is familiar to us, just wearing different clothes.
Teams do not fail to learn because the information is missing. In our experience the data is nearly always there — in the warehouse, in the logs, in one spreadsheet somebody maintains heroically. They fail because the cost of asking is high enough that nobody asks casually.
And the casual question is where most real understanding comes from.
The formal channels — the dashboard, the weekly report, the quarterly review — answer questions somebody anticipated in advance. That is their job and they do it well. But an organisation's understanding of itself is assembled out of thousands of small unplanned questions: is that normal? has it always done that? what happened the week before?
Those questions have no owner, no ticket and no budget. They only get asked when asking is nearly free.
Which is why we are sceptical of capability programmes that begin by building more reporting. Another dashboard adds answers to anticipated questions. It does nothing for the unanticipated ones, and the unanticipated ones are where learning lives.
But the governance bill arrives
None of this is free, and it would be dishonest to pretend otherwise.
Local-first analytics pushes governance out to the edges. Once anyone can pull a dataset onto a laptop and query it in-process, the questions of what is sensitive, what is derived and what is authoritative do not disappear — they just stop being enforced as a side effect of access being slow and centralised.
A great deal of data governance in large organisations is accidental. It works because the warehouse is the only door, and the door has a lock on it.
Remove that chokepoint and you inherit three problems at once:
Provenance — two people answer the same question differently because they pulled the extract on different days, and neither number is wrong.
Sensitivity — data that was governed by virtue of being hard to reach is now sitting in a downloads folder.
Authority — "the number" stops existing once anyone can produce one, and meetings turn into arguments about extracts.
All solvable — but only if you decide to solve them deliberately. The failure mode is discovering them eighteen months in and responding by reintroducing the chokepoint, which restores governance by destroying the thing that made the tool valuable in the first place.
What we would actually do
Treat response time as a capability metric, not an infrastructure one. Nobody reports it that way, which is precisely why it stays invisible.
Concretely: take the five questions your team asks most often about its own work. Time how long it takes a competent person who is not a data specialist to answer each one from a standing start.
That number — not your warehouse's p99 — is what decides whether your organisation gets to be curious about itself.
And if the answer is measured in days, you do not have a data problem. You have a learning problem that happens to be expressed in seconds.
If you want the design rationale from the people who built the thing, this talk is the clearest version of it:
Source: A Preview of DuckDB v2.0.
One email when we publish. Research, product decisions, and what teams report back.