You wired an agent up to a database, and now you have to decide where its state actually lives. The shortlist for 2026 keeps landing on the same three names — Lakebase, Neon, and Supabase — and the confusing part is that two of them are the same engine. Databricks bought Neon in 2025; Lakebase is Neon, wrapped in a lakehouse. So this isn't really a three-way database bake-off. It's a choice about what you want around the Postgres.
If you only take one thing away: choose by the surroundings, not the SQL. The query planner is the same Postgres in all three. What differs is whether the database ships alone, inside an analytics platform, or inside a full app backend.
The two features that actually matter for agents#
Before the grid, know what you're grading on. An agent loop stresses a database in two specific ways:
- Provisioning speed. Agents create databases programmatically — Neon says ~80% of its new databases are made by agents, not humans. A cold start measured in seconds breaks the loop; one measured in hundreds of milliseconds doesn't.
- Copy-on-write branching. An agent that mutates data needs a disposable, full-data copy to work in — one per task, per experiment, per PR — created in milliseconds and thrown away after. This is the single most agent-relevant Postgres feature of the last two years.
Grade the three on those, and the split gets clear.
Lakebase — when state belongs next to your analytics#
Lakebase is the Neon engine living inside Databricks, generally available since February 9, 2026. You reach for it when your agents already run in Databricks and their operational state benefits from sitting on the same governed plane as your analytics — same Unity Catalog, same lineage, no ETL hop between the app database and the warehouse. It's a supported LangGraph checkpointer backend on Databricks Apps and Model Serving, which means your long-running agents can persist their graph state without leaving the platform. The cost of that integration is gravity: you're committing to the Databricks ecosystem.
Neon — when you want disposable and independent#
Neon is the same technology, sold standalone and developer-first. Sub-500ms provisioning, scale-to-zero, instant copy-on-write branching — the full agent-native toolkit, minus the lakehouse. Reach for it when you want a bare, fast provisioning API your agents can hit to conjure and destroy databases cheaply, and you don't want that data living inside a warehouse vendor's platform. It's the purest expression of "Postgres as an agent primitive." (For persisting agent graph state on plain Postgres, see LangGraph checkpointer: Postgres vs Redis.)
Supabase — when you want the whole backend, not just a database#
Supabase is the odd one out, and deliberately so: it's not just Postgres, it's Postgres plus Auth plus Storage plus Realtime plus Edge Functions — the reason it became the default backend for AI-generated apps out of Bolt, Lovable, Cursor, and Claude Code. If your agent is the backend of a real app, that bundle saves you a stack of integrations.
The honest trade: Supabase's compute doesn't scale to zero on paid plans, so an idle database still bills, and its branching is migration-based (it replays schema changes) rather than instant copy-on-write. You give up the two agent-loop features to gain a batteries-included backend. For many app-shaped agents that's the right trade; for a swarm of short-lived task agents that idle constantly, it's the wrong one.
The one-line decision#
- Agent state should live beside your analytics and governance, and you're on Databricks → Lakebase.
- You want cheap, independent, disposable Postgres that scales to zero and branches instantly → Neon.
- You want a full app backend — auth, storage, realtime — that agents can target, not just a database → Supabase.
Two engines, three packages. Pick the wrapper that matches where your agents already live — the Postgres underneath will be fine either way. If you're still mapping the wider field (Turso, PlanetScale, and the edge-database crowd), start with Neon vs Supabase vs Turso, then come back here once you've decided agents are the primary customer.
