#201 The Database is the Operating System | Mike Stonebraker, CTO & Co-Founder At DBOS

ELI5/TLDR

Mike Stonebraker — the guy who designed Postgres in the 1980s and has spent his life building database systems — has decided the operating system itself should be a database. Linux is fifty years old, was designed when a computer had 48 kilobytes of memory, and now has to babysit machines with thirty-two thousand processors and many terabytes of storage. That is six orders of magnitude more stuff to keep track of, and keeping track of stuff is what databases are good at. His new project DBOS throws out almost everything between the bare metal and your application and replaces it with one big database. The payoff: distributed banking transactions become trivial, ransomware recovery becomes an eighteen-minute rewind, and you can ask “which user is hogging disk space?” by writing a SQL query.

The Full Story

Why Postgres won and what comes next

The interview opens with a soft question about Postgres. Stonebraker’s answer is unusually generous — he insists its success had almost nothing to do with him. In 1995 a “pickup team of programmers” adopted it and have shepherded it ever since. The other half of the story is that when Oracle bought MySQL, the world got nervous, and Postgres remained purely community-driven. Now the big cloud providers — what he calls the “cloud elephants” — are standardizing on the Postgres wire protocol, the small language databases use to talk to clients. If you and a colleague are picking a database in 2026 and you don’t already have a reason to choose otherwise, you pick Postgres.

He has a paper coming out with Andy Pavlo making a confident claim. There are no new data models worth getting excited about. The relational model — tables, rows, columns, joins — won and isn’t being dethroned. Where the action is: hardware (the cloud is forcing everyone to rewrite), and new application areas. One of those new application areas is the operating system itself.

The six orders of magnitude problem

Here is the core argument, and it’s worth slowing down on. Stonebraker’s first machine in 1974 was a PDP-11/40: one processor, forty-eight kilobytes of memory, twenty megabytes of storage. The thing that monitors all the resources of a computer — the operating system — was designed in that world. The MIT Supercloud, where DBOS now runs, has thirty-two thousand processors and many terabytes of memory. Same job, but with a million times more stuff to track.

What does an operating system actually do? It keeps track of files, processes, tasks, resources, users, network connections, permissions. When you have a million of each, keeping track of them is not a list problem anymore. It is a database problem. Imagine running a small village from a paper notebook versus running a country from one. At some point the notebook has to become a filing system, and the filing system has to become a database. Stonebraker’s claim is: the OS crossed that line a long time ago, we just papered over it.

Linux is old, and showing it

The other half of the argument is age. Linux is about forty years old, Unix is fifty. They are legacy code in the unflattering sense — patched and extended over decades, never redesigned. Two specific weaknesses:

There is no native multi-node Linux. If you want to run software across multiple servers — which is almost everyone now — you have to bolt on an orchestrator like Kubernetes. That orchestrator is itself a sprawling piece of software you now also have to maintain.

Linux is, in his memorable phrase, a “leaky security boat.” So people layer security software on top. Then more security software on top of that. You end up with a patchwork that is both a management nightmare and still leaks. Time, he says, to send Linux to the home for tired software.

What about Microsoft’s failed attempt?

The interviewer raises an obvious objection. Twenty years ago, Microsoft tried to put a database at the heart of Windows. The project was called WinFS, internally Longhorn. It died. What’s different this time?

Stonebraker says he poked around inside Microsoft to find out what happened. The verdict from people who were there: the idea was right. The execution was bad — internal politics and feature creep. The team kept adding more ambition before they had something running. He treats this as a lesson about startups generally. The worst thing any new project can do is keep adding features before the first version works. DBOS exists at all because they shipped a commercial version in roughly a year, then started asking customers what they hated.

The “once and only once” problem

When the team asked enterprise customers what they would care about, three groups paid attention.

The first was the three-letter agencies — defense and intelligence — who care about security above almost everything.

The second was financial services. A regional bank in the Northeast described what Stonebraker calls the “once and only once” problem. Imagine moving ten dollars from your account to mine. We are almost certainly on different banking systems. The transaction has to: debit your account, send a message, credit my account, send a confirmation back, and commit the whole thing atomically. If anything fails partway — the message gets lost, my account credits twice, your account debits zero times — money has been created or destroyed. This is called distributed commit, and the bank told Stonebraker that something like a third to a half of their entire application code is dedicated to getting this right. It is brittle, error-prone, and not for the faint of heart.

DBOS solves this almost by accident. Because the network is in the database, the message system is in the database, and the application state is in the database, all three pieces are sitting in one transactional system. The database can guarantee the entire operation either happens completely or doesn’t happen at all. Half the bank’s code base, gone.

The third group was what he calls “scuff-shoe enterprises” — companies that make physical things. One large conglomerate described their security setup: two seven-digit-a-year subscriptions, several hundred monitoring rules, hours between when an attacker knocks on the door and when a human responds. They are terrified of ransomware, which can take a billion-dollar enterprise offline for days. DBOS’s pitch to them is simpler than any security feature. Because every change to the operating system goes through the database, DBOS keeps a log of state and spools it to a data warehouse. If ransomware hit you seventeen minutes ago, you rewind eighteen minutes, step around the attack, and continue. Like Ctrl-Z for an entire operating system.

How DBOS is actually built

The architecture is severe. On the bare metal you have a microkernel — a tiny piece of code that gives you the basics. Right now they run on AWS’s Firecracker microkernel; eventually they may write their own. On top of the microkernel, one thing runs: the database. Everything else — the file system, the messaging system, the schedulers — is written on top of the database.

The messaging system is the cleanest illustration. There is a table with three columns: sender, receiver, payload. To send a message you do INSERT INTO messages .... To read messages you do SELECT * FROM messages WHERE receiver = me. That’s it. No TCP/IP inside the system, no separate message queue, no Kafka. The whole thing is one SQL line in each direction. When you need to talk to the outside world, there is a gateway. Inside DBOS, it is all just the database.

To build an application, you write a graph of small functions — Stonebraker calls them “micro operations” — in TypeScript. You tell DBOS the graph, it stores the graph in the database, and a tiny orchestrator wakes each function up when its inputs are ready. Because each function is a database transaction, you mostly avoid race conditions — the kind of bug Jim Gray named “heisenbugs” because they vanish when you look at them. Every web user has filed a bug report only to be told “we can’t reproduce it.” That whole category becomes much rarer when the underlying system is transactional.

SQL as an OS query language

Here is the part that opens up the mind a little. If everything in the OS is in a database, you can query the OS in SQL.

Who in my environment is using more than 100 gigabytes of space, counting only files bigger than one gigabyte?

Which three users are chewing up the most resources?

Is there anybody who has copied more than 20 files in the last 12 hours?

You cannot really ask those questions of Linux right now. You can write scripts that approximate them. In DBOS they are one-line SQL queries. The same goes for monitoring and debugging your own application — the application’s state lives in the same data warehouse, so you can ask “who has user X transitively sent messages to” with a single recursive query, which is exactly what a security analyst wants to ask about a suspected bad actor.

What Stonebraker is working on next

Two threads. First, networking. Inside the current DBOS, the slowest part is now the messaging — sending data between machines — because the database itself has gotten so fast. So they are looking at ways to send messages faster than inserting and reading database rows. The bottleneck has migrated, and the team is chasing it.

Second, large language models. Everyone is dabbling. The interesting question for him is what LLMs can do for structured data inside database systems — the boring tabular stuff, not the documents.

Key Takeaways

The operating system, conceptually, is already a database — it tracks files, users, processes, permissions. Linux just hides this badly.
Hardware has grown by six orders of magnitude since Unix was designed. The data-management problem inside an OS has therefore grown by six orders of magnitude too.
Distributed commit (making sure money moves exactly once between accounts) is one of the hardest problems in banking, and most banks write a third to a half of their code dealing with it. DBOS solves it for free because everything is in one transactional database.
Because all OS state lives in a logged database, ransomware recovery is just rewinding the log. Eighteen minutes back and you’ve stepped around the attack.
Microsoft tried this twenty years ago (WinFS / Longhorn). It died from feature creep, not from a bad idea.
Inside DBOS, the messaging system is a SQL table with sender/receiver/payload columns. Inserts send messages. Selects receive them. No Kafka, no TCP/IP internally.
The relational model won. Stonebraker doesn’t expect new data models to matter. The action is in hardware and new applications.

Claude’s Take

This is the kind of conversation that rewards a second listen. Stonebraker is in his eighties, has the credibility of having designed the database half the planet runs on, and is plainly enjoying himself. He talks about Linux the way an old plumber talks about copper pipes from the 1950s — useful in their time, but you wouldn’t put them in a new house.

The intellectual payload is one big idea: if you have to track a million of something, that is a database problem, whether you call it one or not. Every operating system has been quietly drifting toward this realization for decades. The OS keeps lists of processes, files, network connections, users, permissions — and those lists got long enough that scanning them linearly stopped working. Linux papered over this with caches, indexes, and special-purpose data structures bolted onto each subsystem. DBOS just says: stop pretending, put it all in Postgres-shaped storage, and let the database do what databases are good at.

The pitch is genuinely compelling for two specific audiences — banks and security-paranoid manufacturers — and weaker for everyone else, because everyone else has too much legacy code to rewrite. Stonebraker is candid about this. The honest claim is not “Linux is dying tomorrow.” It is “if you are building something new on the cloud, especially something that handles money or runs scared of ransomware, the math has changed.”

The eighteen-minute rewind for ransomware is the moment that stuck with me. It is so obvious in retrospect — if every state change goes through a logged database, every state change is reversible — that the question is why this isn’t the default. The answer is that operating systems were not designed with logging at this granularity because the hardware couldn’t afford it. Now it can.

Score 8/10. Loses a point because the interview is mostly Stonebraker explaining and not enough resistance from the host, and another half-point because the DBOS commercial story is still very early — most of what he describes is potential rather than delivered. But the underlying idea is one of the more interesting “what if we just started over” arguments in systems software, and Stonebraker is one of maybe five people on Earth qualified to make it.