Databricks Lakebase: Serverless Postgres for AI Agents Goes GA

Databricks announced general availability of Lakebase, its serverless Postgres product for AI agents, which reached $100 million in annual recurring revenue in its first year. The company also closed a $5 billion funding round at a $190 billion valuation to invest in Lakebase, Genie, and Unity AI Gateway. Key features include copy-on-write database branching for instant forks and integration with PGlite, a WebAssembly-based Postgres for per-agent sandboxes.

Databricks crossed $7 billion in annualized revenue last week, growing more than 80% year over year. Lakebase — its serverless Postgres product for AI agents — hit $100 million ARR in its first year of existence. The same week, Databricks closed a $5 billion funding round at a $190 billion valuation https://techcrunch.com/2026/08/13/databricks-wanted-to-raise-1b-investors-wanted-15b-it-settled-on-5b-at-a-190b-valuation/ , with the stated plan to pour that capital into Lakebase, Genie, and Unity AI Gateway. This is not a preview or a beta announcement. Lakebase is generally available, it is making real money, and Databricks has bet its next chapter on it. If you are building AI agents and you are not on Databricks, you should still understand what changed here — because the architectural patterns Databricks is shipping will spread. Copy-on-Write Branching: Git for Your Database The standout developer feature in Lakebase is database branching. Fork a terabyte-scale production database in approximately one second. Zero storage cost at creation — branches use copy-on-write, sharing the parent’s data and only consuming space for bytes you actually change. The operation is O 1 , meaning it does not get slower as your database grows. For developers debugging AI agents against production state, this is a genuine solution to a real problem. You can fork production, let your agent run against real data, observe what breaks, and delete the branch when you are done. No snapshots to manage. No sanitized staging environments that do not match production. No risk of corrupting live data. Branch production for an agent debugging session databricks postgres create-branch --source production --name agent-debug-session Clean up when done databricks postgres delete-branch agent-debug-session The same pattern extends to CI/CD. Every pipeline run can get its own isolated Postgres branch. Schema migrations can be tested against a real copy of production before they touch it. Pair programming sessions can share a branch endpoint and tear it down when the session ends. Databricks’ branching documentation https://www.databricks.com/blog/enabling-evolutionary-database-development-database-branching-lakebase details the full branching lifecycle, including how branch storage accounting works in practice. PGlite: A Real Postgres Inside Every Agent Sandbox Databricks acquired Electric this month — the team behind PGlite — and the purpose is clear. PGlite is Postgres compiled to WebAssembly. It is small enough to run inside a browser tab, a serverless function, or an AI agent sandbox. Databricks is putting a local Postgres instance inside each agent https://www.databricks.com/blog/electric-joins-databricks-bring-wasm-postgres-ai-agent-sandboxes , not a connection to a shared database but a real, isolated Postgres namespace running in the same process as the agent itself. The architecture works like this: each agent gets its own PGlite instance with full Postgres semantics — transactions, indexes, constraints, the standard wire protocol. When the agent’s work is done, Electric’s real-time sync engine reconciles local state back to the central Lakebase cluster. Agents run in isolation and sync on completion. This matters because the shared-Postgres-connection-pool model breaks down as agent concurrency scales. Multiple agents writing to shared tables create contention, locking, and difficult race conditions. The per-agent Postgres model eliminates that class of problem. PGlite went from one million to 13 million weekly downloads in twelve months, so developers were already reaching for it independently. Databricks is formalizing the pattern and building production sync infrastructure around it. Agent Memory That Survives Restarts Lakebase integrates directly with LangGraph for agent state persistence. The implementation splits memory into two layers. Short-term memory uses LangGraph’s Checkpointer to store conversation state per session, keyed by thread ID, backed by Lakebase. Long-term memory uses LangGraph’s Store to persist cross-session context — user preferences, learned facts, prior decisions — across deploys. The practical result: an agent can resume a conversation from a different server, after a redeploy, or days later without losing context. Databricks ships a ready-made template for this: agent-langgraph-short-term-memory in the official app-templates repository https://github.com/databricks/app-templates . Full documentation is available at Azure Databricks agent memory docs https://learn.microsoft.com/en-us/azure/databricks/generative-ai/agent-framework/stateful-agents . Unity AI Gateway: Cost Controls That Actually Work Unity AI Gateway reached general availability on August 4, 2026. The pitch is straightforward: one control plane for all AI spending across your Databricks environment — hosted models, frontier APIs Claude, GPT-5.6, Grok 4.6 , coding agents, and custom agents. Attribute costs by user, team, tool, or use case. Set hard spend caps that automatically halt requests when a budget is exceeded. Smart Routing, currently in beta, goes further. It routes each task to the cheapest model that meets the quality threshold rather than defaulting everything to the most capable and most expensive option. Databricks reports 30% or more cost reduction per task https://www.databricks.com/blog/smart-routing-unity-ai-gateway-match-frontier-quality-30-lower-cost-task . For shops running high-volume agent workflows, that number compounds fast. Should You Switch? The honest answer depends on your starting point. If you are already on Databricks, using Lakebase is a straightforward decision — the lakehouse integration, Unity Catalog governance, and agent tooling all work together and you will not replicate that combination elsewhere. If you need standalone serverless Postgres with a strong developer experience and you are not on Databricks, Neon is the same underlying technology https://neon.com/docs/introduction/neon-and-lakebase with a friendlier onboarding path. If your application needs authentication, file storage, realtime subscriptions, and Postgres in one package, Supabase remains the right answer. Lakebase is not trying to be a full-stack BaaS and it does not pretend otherwise. The bigger pattern worth watching is the PGlite trajectory. WASM Postgres running inside agent sandboxes, syncing back to a central cluster, is an architectural idea that will outlive any single vendor’s implementation. Databricks is standardizing it and building production infrastructure around it. Developers working on agentic systems outside of Databricks should track what this unlocks — the pattern will appear in other ecosystems soon.