Advanced11 min
Database & State Storage Patterns
Choosing and configuring storage backends for agent state: PostgreSQL for checkpoints, Redis for short-term state, and the tradeoffs between them.
Quick Reference
- →PostgreSQL: durable, ACID-compliant, ideal for checkpoints and long-term memory that must survive restarts
- →Redis: fast, in-memory, ideal for short-term session state, rate limit counters, and caching
- →Use PostgreSQL for checkpointing (AsyncPostgresSaver) and Redis for ephemeral state (session locks, cooldowns)
- →Connection pooling (pgBouncer, Redis connection pools) is mandatory at scale — raw connections exhaust database limits
- →Partition state by tenant ID for multi-tenant agents to enable per-tenant backup, migration, and data isolation
Storage Decision Matrix
Two databases, two jobs
PostgreSQL handles durable state that must survive restarts (checkpoints, conversation history, user memory). Redis handles ephemeral state that must be fast (session locks, rate limits, cache).
| Criterion | PostgreSQL | Redis | SQLite / MemorySaver |
|---|---|---|---|
| Durability | ACID, WAL, replicas | Optional AOF/RDB | Single file, no replication |
| Latency (p50) | 1-5ms | 0.1-0.5ms | 0.01ms (local) |
| Horizontal scaling | Read replicas, partitioning | Cluster mode, sharding | None |
| Max data size | Terabytes | Limited by RAM | Limited by disk |
| TTL support | Manual (cron/trigger) | Native per-key TTL | Manual |
| Best for agents | Checkpoints, memory, audit logs | Session state, rate limits, cache | Local dev and testing only |
| Production ready | Yes | Yes | No |
MemorySaver is dev-only
LangGraph's MemorySaver stores state in-process memory. It works for prototyping but loses all data on restart and cannot be shared across workers.
Most production agents need both Postgres and Redis. The pattern is simple: durable writes go to Postgres, hot reads and ephemeral counters go to Redis, and you pick the right tool for each piece of state.