The practical path for DBOS may not be replacing Linux. It may be becoming the durable runtime inside the isolated environments we are already building for AI agents.
I have been thinking about Michael Stonebraker’s DBOS idea again because AI agents make an old systems argument feel unexpectedly current.
The original DBOS proposal from 2020 made a radical claim: operating system state could be represented uniformly as database tables, with operations over that state expressed as queries and transactions.
The later VLDB paper on DBOS went further. Instead of composing a traditional operating system with separate cluster schedulers, distributed filesystems, IPC mechanisms, analytics systems, and high-availability machinery, the authors explored putting a distributed transactional DBMS near the bottom of the stack and implementing many OS services over it.
I do not think AI agents prove that we should replace Linux with a database.
I think they validate a more practical version of the same idea:
The database can become the durable runtime for autonomous computation.
More importantly, the agent ecosystem may have created a new insertion point where we can test this idea without asking infrastructure teams to replace their operating system at all.
Agents Have an Execution-State Problem
A normal web request is short:
request
|
application
|
database
|
responseuser request
|
LLM
|
tool call
|
LLM
|
database query
|
wait for approval
|
API call
|
another agent
|
LLM
|
...That workflow might run for minutes, hours, or days.
Now imagine the process dies at step 47.
Starting from step 1 may be wrong. Earlier steps may already have sent an email, changed a database row, opened a pull request, or charged a customer.
This is why long-running agents increasingly need durable execution rather than simple retry logic.
Current DBOS agent documentation makes this an explicit use case. A workflow persists its progress in a database so it can recover after process crashes, server restarts, network failures, deployments, or long pauses for human input.
There is also an LLM-specific reason this matters.
LLM calls are nondeterministic.
result = llm(prompt)Calling that function again does not guarantee the same result. A retry can change the future path of the program.
A durable runtime therefore wants something closer to:
LLM(prompt)
|
result
|
checkpoint result
|
continueDBOS’s Vercel AI SDK integration, for example, checkpoints completed model calls in Postgres. During recovery, completed calls can be replayed from those checkpoints instead of contacting the model provider again.
The model output is no longer just API response data. It has become part of the execution history of the program.
That is a very database-shaped problem.
Agent State Is Already Scattered Across Systems
A production agent can easily accumulate several state stores:
Postgres -> business and application state
Redis -> cache, locks, temporary coordination
Vector DB -> semantic retrieval
Workflow DB -> execution history
Object store -> files and artifacts
Tracing DB -> model and tool tracesEach system exists for a reason. I am not arguing that one relational database should physically replace every specialized store.
The more interesting question is:
Can everything required to understand and recover an agent’s computation have one authoritative transactional representation?
Large artifacts can still live in object storage. Vector indexes can remain specialized. GPU memory and model KV caches can remain ephemeral.
But goals, messages, tool-call results, approvals, checkpoints, permissions, budgets, execution history, and references to artifacts are structured state.
That is the part that looks increasingly like an operating-system problem expressed as data.
The OS Analogy Becomes Stronger With Agents
An agent runtime needs concepts that look surprisingly familiar:
- Process -> Agent or workflow
- Thread -> Task or sub-agent
- Scheduler -> Agent scheduler
- IPC -> Agent messages
- Files -> Memory and artifacts
- System call -> Tool call
- Credentials -> Tool permissions
- Process tree -> Agent delegation tree
- Resource limits -> Token, time, and dollar budgets
- Checkpoint -> Workflow checkpoint
- Trace -> Agent provenance
- Crash recovery -> Agent resume
The useful state of an autonomous agent might look like this:
Agent 4312
goal
context
memory
permissions
messages
tool calls
model calls
pending work
completed work
human approvals
budget
artifacts
execution historyAlmost everything in that list can have a durable database representation.
The 2025 DBOS retrospective is interesting in this context. It describes how the research project evolved, including work on provenance and a Python and TypeScript programming environment.
Provenance becomes much more important when the program itself is making decisions.
Why did the agent take this action?
Which model response caused it?
What data did it see?
Which tool did it invoke?
Did the tool actually execute?
How much did the path cost?
Where can execution safely resume?Those are naturally queries over execution state.
The New Insertion Point: Agent Sandboxes
This is the part I find most interesting.
The original DBOS vision had a difficult adoption problem. Replacing the operating-system architecture of an existing infrastructure stack is a very large commitment, no matter how compelling the research argument is.
But AI infrastructure is currently creating a new execution boundary almost from scratch: the agent sandbox.
A growing set of platforms now gives agents isolated environments for running code and tools. Modal Sandboxes are secure containers intended for untrusted user or agent code. Daytona provides isolated agent runtimes and uses Linux containers by default. E2B integrates persistent isolated sandboxes directly with the OpenAI Agents SDK.
This creates an interesting opportunity.
replace Linux
|
deploy DBOS everywhere
|
rewrite infrastructureLinux host
|
Agent sandbox
|
DBOS durable runtime
|
Postgres
|
Agent + toolsLinux still provides the kernel, namespaces, filesystem, networking, process isolation, and device support.
The DBOS-style layer becomes the durable control plane for the agent’s computation.
That is a much smaller adoption step.
It also gives us a clean experimental boundary.
An Experiment I Would Like to Run
I would build the same long-running agent in two environments.
A. Conventional Agent Runtime
Agent sandbox
|
agent framework
|
workflow/state infrastructure
|
LLM + toolsB. DBOS-Backed Agent Runtime
Agent sandbox
|
DBOS workflow runtime
|
Postgres
|
LLM + toolsThen I would inject failures at random points in the same workload.
Kill the process after an LLM response.
Kill it during a tool chain.
Restart the sandbox.
Interrupt it while waiting for human approval.
Crash a worker after an external API succeeds.
task completion rate
successful recovery rate
duplicate side effects
repeated LLM calls
repeated tool calls
token and API cost
p50 / p99 latency overhead
throughput
time to diagnose a failed run
ability to reproduce executionI would also measure task quality, but I would not expect DBOS itself to make the model smarter. The interesting question is whether better execution semantics improve the reliability of the overall agent.
There is an important caveat here.
DBOS does not magically give exactly-once semantics to arbitrary external APIs. Its step documentation explicitly notes that steps execute at least once.
If an external side effect succeeds and the process dies before its result is checkpointed, that step can execute again. External systems still need techniques such as idempotency keys.
For database writes, however, the durability boundary can be much stronger because application state and workflow state can participate in transactional execution.
This is exactly why I think the comparison would be useful.
The goal is not to prove that databases remove distributed-systems failures.
The goal is to see whether a database-centric execution model gives us a smaller and more understandable failure surface.
DBOS May Have Moved Up One Layer
The most interesting evolution of DBOS may therefore be conceptual rather than literal.
The original idea was roughly:
Applications
|
OS services
|
Distributed DBMS
|
small kernel
|
HardwareThe practical agent version could be:
Agent
|
Durable execution runtime
|
Database
|
Linux / sandbox / cloud
|
HardwareThe database is no longer the operating system for the whole machine. It becomes something closer to an operating system for the computation. That distinction matters because an LLM agent does not really care about POSIX as its programming model. The abstractions it cares about are goals, context, memory, messages, tools, permissions, approvals, budgets, and persistent execution history. Those abstractions map surprisingly naturally to records, transactions, and queries.
I do not know whether a DBOS-backed agent runtime would outperform conventional agent infrastructure. That is an empirical question, and I would rather benchmark it than assume the answer. But the architecture now has something the original DBOS proposal did not have: a low-friction adoption path. We are already creating new isolated runtimes specifically for agents.
That means we do not have to convince a company to replace Linux across its infrastructure. We can put a database-backed durable runtime inside one class of agent sandbox, run the same workload beside a conventional implementation, inject failures, and measure the result.
If the database-centric version makes recovery, provenance, reproducibility, and coordination significantly simpler without unacceptable overhead, that would be a meaningful validation of Stonebraker’s original thesis, just one layer higher in the stack.
Perhaps the future of DBOS is not:
Database replaces the operating system.
Database becomes the operating system for long-running autonomous computation.
That feels like an experiment worth running.
