The company photographs itself the way it photographs a database: a plain black square that turns out to be holding the whole operating system in its memory. Steady. Unbothered. Already recovering from the crash you haven't had yet.
Here is a fun fact about computers that nobody tells you until it ruins your afternoon: your program does not actually remember what it was doing. If the machine restarts halfway through charging a customer, shipping an order, or running a 40-step AI agent, the program does not resume politely where it left off. It forgets. DBOS, Inc. exists because a group of database people decided that forgetting is, fundamentally, a database problem.
The premise of DBOS is the kind of thing that sounds either obvious or insane depending on how many production outages you have personally lived through. The insane-sounding version goes like this: an operating system is really just a giant pile of state - which process is running, what it has done, what it is allowed to do - and databases are the single best technology humanity has ever built for managing giant piles of state. So why not store the operating system's state in a database? Why not, in fact, build the operating system on top of the database, instead of the other way around?
This is not a rhetorical question that a random founder asked on a whiteboard. It is a question that Michael Stonebraker asked, and Michael Stonebraker is the person who built Postgres in the 1970s and later won the Turing Award, which is the closest thing computer science has to a Nobel Prize. When the guy who invented your database says "storing OS state is a database problem," the correct response is not to laugh. The correct response is to ask how much the round is and whether you can get in.
DBOS - the name stands for Database-Oriented Operating System - began as a joint MIT-Stanford research project around 2020, co-led by Stonebraker and Matei Zaharia, who created Apache Spark and is CTO of Databricks. That is an absurd amount of database and distributed-systems firepower pointed at a single idea. When the graduate students on the project finished their PhDs in 2023, they did the thing graduate students with a good idea do: they incorporated a company. Qian Li became CEO, Peter Kraft became CTO, Stonebraker took the architect seat, and Andy Palmer signed on as chairman.
Now, the grand "replace Linux" framing makes for excellent press releases, and DBOS got plenty of it: DBOS nabs $8.5M to challenge Linux with a database-powered operating system. But the product that actually shipped, and the reason developers care, is more modest and more useful than a new operating system. It is a library called DBOS Transact, and it does one genuinely valuable thing: it makes your program crash-proof.
The mechanism is almost anticlimactically simple. You write ordinary Python or TypeScript functions - the same functions you were going to write anyway. Then you sprinkle decorators on top, little annotations that say "this is a workflow" and "this is a step." Underneath, DBOS quietly checkpoints the state of your program into Postgres after each step. When the machine dies - and machines die - your workflow does not restart from zero and it does not run your credit-card charge twice. It picks up from the last completed step. Exactly once. Every time.
What is clever here is what DBOS doesn't require. Most durable-execution systems ask you to stand up a separate orchestration server, a whole new piece of infrastructure that your workflows phone home to. DBOS runs inside your existing application, using the Postgres database you already have. There is no new server to operate, no Kubernetes cluster to babysit, no vendor-shaped hole in your architecture. The reliability lives in the database, which is where DBOS thinks it belonged the whole time.
This turns out to matter a lot right now, because the hot new thing that needs crash-proofing is AI agents. An LLM agent that plans 30 steps, calls six tools, and runs for eleven minutes is exactly the kind of long, stateful, failure-prone process that databases-as-workflow-engines were built for. When the agent crashes on step 24 - and it will - DBOS lets it resume from step 24 rather than starting the whole expensive, token-burning odyssey over. The company leaned into this: DBOS Conductor is a control plane specifically for managing and observing agents and workflows, and the marketing language cheerfully promises "crash-proof AI agents."
The business model is the familiar open-core arrangement, executed with discipline. DBOS Transact is free and open source, which is how you get developers to try it on a Tuesday afternoon without asking anyone for budget. The money comes from DBOS Cloud, a serverless platform that hosts and runs these durable applications with automatic outage recovery and a "time-travel debugger" that lets engineers replay production state to see what actually went wrong. Free library, paid hosting: the same trick that built a dozen infrastructure businesses, applied to reliability.
You could reasonably ask whether the world needs another durable-execution company. Temporal exists. Restate exists. Inngest exists. AWS has Step Functions. The DBOS answer is architectural rather than featural: everyone else asks you to add infrastructure, and DBOS asks you to add a decorator. Whether that is a moat or merely a nice ergonomic difference is the kind of thing you find out over several years and several enterprise sales cycles.
The bet underneath all of it is a philosophical one, and it is the reason a Turing Award winner is spending his time on this instead of retiring. The bet is that reliability should not be a project. It should not be a platform team, a six-month migration, a runbook. It should be a property of the runtime - something you get for free because the database was always going to remember, and you just had to let it remember your program too.
Lightweight durable execution for Python and TypeScript (plus Go, Java, Kotlin). Decorate a function and get workflows that run to completion, exactly-once execution, and automatic OpenTelemetry traces - all persisted in your own Postgres.
A management and observability layer for orchestrating AI agents and long-running workflows built on DBOS Transact - the cockpit for crash-proof, resumable processes.
A transactional serverless platform for deploying reliable backends, workflows, and cron jobs - with automatic outage recovery and a production time-travel debugger for after-the-fact bug hunting.
DBOS lands wherever a program cannot afford to forget what it was doing. A rough map of the terrain:
Relative emphasis based on the company's stated use cases and positioning - illustrative, not measured.
Joint MIT-Stanford research project begins, co-led by Michael Stonebraker and Matei Zaharia, exploring an operating system built on a database.
DBOS, Inc. is incorporated to commercialize the research as the founding PhD students graduate.
Public launch: $8.5M seed round led by Engine Ventures and the release of the open-source DBOS Transact durable execution library.
DBOS TypeScript debuts on Show HN - "lightweight durable execution built on Postgres" - drawing heavy Hacker News discussion.
CEO Qian Li appears on Software Engineering Radio (ep. 681) to unpack durable execution and serverless computing.
Watch product demos and talks on the DBOS YouTube channel (@DBOS-Inc) - the fastest way to see durable execution recover from a crash live.