Postgres is the default answer — agent state included

When you're building agent systems, the state management question arises early: where do you persist conversation history, tool call results, execution checkpoints, and session metadata? The answer, increasingly, is the same answer that won the broader platform engineering battle: PostgreSQL. Not because Postgres is magically perfect for agents, but because it's the default substrate for structured state in 2026 — and agent state is structured state with a latency budget.

The case for Postgres as agent state starts with durability semantics. Agent workflows need write-ahead logs, checkpointing, and the ability to resume from arbitrary execution points after process death or redeployment. LangGraph's PostgresSaver, Temporal's persistence layer, and the durable execution pattern all converge on the same insight: the unit of agent state is not a cache entry but a transactional record with ACID guarantees. Redis can serve as a fast auxiliary layer for conversation history or tool call caching — and it excels at TTL-managed ephemeral state — but the durable checkpoint backend is a database job, not a cache job.

PostgreSQL's replication and high availability primitives map cleanly to agent runtime requirements. Streaming replication with synchronous commit modes gives you the durability spectrum: `remote_apply` for causal consistency when agent checkpoints must survive primary failure, `remote_write` for OS-buffer durability with lower latency, and asynchronous replication for read replicas that serve trajectory replay queries. Patroni automates the failover orchestration, using etcd or Consul as the distributed configuration store and enforcing split-brain prevention via watchdog integration. The maximum lag on failover setting becomes your agent's RPO bound — how much execution state you might lose if the primary dies mid-turn.

Connection pooling is non-negotiable for agent fleets. Postgres's process-per-connection model caps practical concurrency at a few hundred connections per instance, but agent runtimes often need thousands of concurrent sessions. PgBouncer sits in front, running in transaction pooling mode (the production default) to multiplex agent connections onto a smaller pool of backend connections. The SQL compatibility matrix matters here: prepared statements work as of PgBouncer 1.21, but certain session-level parameters aren't tracked, so you validate your ORM's startup behavior before committing. Pool sizing becomes a three-layer budgeting exercise: agent concurrency, tool call fanout, and checkpoint write frequency.

Multi-tenancy is where agent state meets compliance reality. Row-level security policies let you enforce tenant isolation within a shared schema — `CREATE POLICY tenant_isolation ON agent_states USING (tenant_id = current_setting('app.current_tenant')::uuid)` — with the `FORCE` option closing the owner-exemption loophole. For stricter isolation, the bridge model (schema per tenant) or silo model (database per tenant) trade operational complexity for regulatory compliance. Citus adds horizontal sharding when a single Postgres instance can't hold the state volume, but most agent deployments hit concurrency limits before storage limits, making connection pooling the first scaling decision.

Online schema migrations matter because agent state schemas evolve. The four-phase pattern — dual write, backfill, cutover, cleanup — applies when you add checkpoint fields or change message formats. `CREATE INDEX CONCURRENTLY` avoids blocking checkpoint writes during backfill, and `pg_repack` or `pgroll` handle the table rewrites that require exclusive locks. Logical replication becomes your online upgrade tool for major version changes, and `pg_stat_activity` is your forensic surface when migrations stall or checkpoints pile up.

Redis still earns its place in the architecture, just not as the durable substrate. Use Redis Lists for conversation history with `RPUSH`/`LRANGE` and `EXPIRE` for TTL-managed sessions. Use Redis Hashes for tool call caches keyed by deterministic `tool+args` hashes, with TTL varying by tool volatility. Use Redis Streams with consumer groups for durable, at-least-once delivery when you need coordination without database polling. But when the question is "where does agent state live," the answer is increasingly: Postgres, with Redis as a fast auxiliary layer for specific access patterns.

The concession: this default answer assumes you're building for enterprises that already run Postgres as platform infrastructure. If you're in a greenfield startup with no existing database operations, or if your agent state is genuinely ephemeral (chatbots with no memory requirements), the Postgres default carries operational weight you might not need. But for production agent systems that must survive redeployment, support trajectory replay, and enforce tenant isolation with audit trails, Postgres is the substrate that already solved these problems for the broader platform. Agent state is just another structured state problem — with the additional requirement that your checkpoint writes fit inside the agent's latency budget.