Lakebase vs self-managed Postgres for AI agent state: a 2026 cost and decision guide

Summary. An AI agent that forgets everything on restart is a demo, not a product, so agent frameworks persist state to a database. In LangGraph, the PostgresSaver checkpointer writes each step's state to a Postgres JSONB column keyed by a thread ID, and Postgres has become the default store for agent memory. The 2026 decision is where that Postgres runs. Serverless Postgres now has two Databricks options: Lakebase, which reached general availability on Azure on March 3, 2026, and Neon, which Databricks acquired in 2025 and reads from $0.106 per compute-unit-hour on its Launch plan and $0.35 per GB-month for storage. Both scale to zero when idle and branch production data in seconds. Self-managed Postgres, whether self-hosted or on Amazon RDS or Aurora, gives full control, no lock-in and on-premise residency, but bills for provisioned capacity around the clock and adds real operational work. This guide compares the three on cost, branching, latency, governance and lock-in.

Why an AI agent needs a state store

Without persistence, an agent's working memory disappears the moment the process stops. Frameworks solve this with checkpointing. LangGraph writes a checkpoint every time the graph moves to a new node, tags each run with a thread ID so different users and tasks stay separate, and reconstructs the agent's internal state from the last checkpoint when a thread resumes. The langgraph-checkpoint-postgres package stores that state in a Postgres JSONB column, which is why so many agent stacks end up on Postgres rather than a bespoke store.

There is a sharp edge worth naming. Because a checkpoint is written at every step, putting large blobs in agent state is expensive: a 50 MB PDF carried in state across 10 steps writes about 500 MB to Postgres. Keep large artifacts in object storage and put references in state. For engineering teams already running Postgres for agents, our production guide to PostgreSQL 19 and our patterns for stateful AI agents on Kubernetes go deeper on the data and runtime layers.

The three options in 2026

The choice is not two-way any more. There are three realistic paths, and two of them now belong to the same company.

Lakebase is Databricks' managed, serverless Postgres for the lakehouse. It separates compute from storage, writes operational data directly to lakehouse storage, and sits under Unity Catalog governance. Neon is a standalone serverless Postgres that Databricks acquired in 2025; it is the developer-facing product with public, consumption-based pricing. Self-managed Postgres is the classic path: you run community Postgres yourself on VMs or containers, or lean on a managed service like Amazon RDS or Aurora that still leaves you owning capacity and configuration decisions.

The practical distinction is that Lakebase and Neon share the serverless model, autoscaling and copy-on-write branching, while self-managed Postgres trades that elasticity for full control and portability.

Cost: the bill is dominated by idle time

Agent workloads are bursty. A support agent might be busy during the day and near-silent overnight; a batch of research agents spikes for an hour and then stops. That pattern is where serverless economics matter, because a serverless database scales to zero when idle and you pay only for the compute you actually use.

Neon's public pricing makes the numbers concrete: as of July 2026, compute is $0.106 per compute-unit-hour on the Launch plan and $0.222 on Scale, where one compute unit is roughly one vCPU and 4 GB of RAM, and storage is billed separately at $0.35 per GB-month. There is no monthly minimum on paid plans, so a project consuming $3 of resources is billed $3. After the Databricks acquisition, Neon cut storage from $1.75 to $0.35 per GB-month and roughly doubled the free tier's compute allowance to 100 compute-unit-hours a month. Lakebase uses the same usage-based, scale-to-zero model, billed through Databricks, which the company frames as lowest total cost of ownership because you pay for compute consumed rather than provisioned.

Self-managed Postgres inverts that. A provisioned instance runs, and bills, 24 hours a day whether an agent touches it or not, and you also pay a person to patch, back up, tune, monitor and fail it over. Managed services like RDS and Aurora reduce that labour but still charge for provisioned capacity and storage continuously. For a steady, high-utilisation workload the always-on instance can be cheaper per query; for spiky agent traffic, the serverless bill usually wins because idle time costs almost nothing.

Branching and developer velocity

Both serverless options support instant, copy-on-write branching: the data stays in one place and the system tracks only the deltas between branches, so a branch is nearly free to create and appears in seconds. For agent teams this is more useful than it first sounds. You can branch production data, run a risky prompt or schema change against realistic state in an isolated copy, and throw the branch away, without touching live users or copying a full database. Lakebase adds zero-copy clones and instant point-in-time recovery for the same reason. On self-managed Postgres you get this only by scripting dumps, restores or storage snapshots, which are slower and consume real space.

Latency and architecture

Serverless Postgres pays a design cost for separating compute from storage, because object storage is slower than a local disk. Lakebase adds a low-latency caching layer over that storage so reads and writes stay fast, and the architecture is invisible to the application, which still speaks standard Postgres and can use extensions like pgvector for retrieval and PostGIS for geospatial work. Self-managed Postgres on a well-tuned local disk gives predictable, low latency without that indirection, which is one reason latency-sensitive, always-on services sometimes stay self-managed. For most agent state, checkpoint writes and thread reads, both models are comfortably fast enough.

Governance, lock-in and residency

This is where the decision usually turns. Lakebase places operational data under the same Unity Catalog governance as analytics and AI, integrates with Microsoft Entra ID and Azure networking, and gives one access-control and lineage model across the estate. The trade is gravity: you are on Databricks and, for the generally available service, Azure. As Simon Gilles Fassot, Head of Global Data and Analytics at Hafnia, put it, "Azure Databricks Lakebase gave us one governed foundation for apps, analytics, and AI, so we stopped duplicating data and shipped real-time features faster." Neon is more portable but still a Databricks-owned managed service. Self-managed Postgres is the only option with no vendor lock-in and the freedom to run anywhere, including on-premise or in a specific region, which matters when data residency is a hard requirement.

India-specific considerations

For Indian teams, residency often decides the question. The Digital Personal Data Protection Act, 2023 pushes toward keeping personal data governed and, in many enterprise cases, in-region. Self-managed Postgres on infrastructure you control, or in an Indian region, gives the tightest residency story; serverless options are viable where the provider offers a suitable region and your data classification allows it. Agent conversation logs and tool outputs frequently contain personal data, so treat the state store as in scope for DPDP from the start. Our DPDP engineering playbook for Indian startups covers consent and data-handling design, and teams weighing infrastructure spend can compare it against our breakdown of India GPU cloud rental pricing.

How to decide

Pick Lakebase if you already run on Databricks and want agent state, analytics and governance under one roof without building pipelines between them. Pick Neon if you want serverless Postgres economics and branching without adopting the whole lakehouse. Keep Postgres self-managed if you need full control, no lock-in, or strict on-premise residency, and your workload is steady enough that always-on capacity is not wasteful. The honest rule of thumb: match the billing model to the traffic shape, because for most agent workloads the state store spends far more time idle than busy.

FAQ

How eCorpIT can help

eCorpIT is a Gurugram-based technology organisation, founded in 2021, appraised at CMMI Level 5 and MSME certified, with senior-led, multi-disciplinary teams and partnerships with AWS, Microsoft and Google. We design the data layer for AI agents, choosing between serverless and self-managed Postgres based on your traffic shape, latency needs, governance model and DPDP residency requirements, and we build the checkpointing, branching and backup workflows around it. If you are deciding where your agent state should live, talk to our team.

References

1. Azure Databricks Lakebase is generally available — Databricks

1. Lakebase: Postgres for data apps and AI agents — Databricks

1. Simplify AI agent orchestration with Lakebase Postgres — Databricks

1. Database branching with git-style workflows in Lakebase — Databricks

1. Neon plans and pricing — Neon

1. Neon serverless Postgres pricing 2026: complete breakdown — Simplyblock

1. Databricks raising a strategic round at a $188 billion valuation — Databricks

1. LangGraph persistence: checkpointers and state — Fastio

1. Enabling state persistence for LangGraph agents — IBM

1. Mastering state persistence with LangGraph and PostgreSQL — DEV Community

_Last updated: July 26, 2026._