Redis vs Postgres for AI Agent Memory, Actually Measured

Test setup and methodology: we seeded 2,000 fake agent sessions into a local PostgreSQL 18.1 table and a local Redis 8.4.0 instance. Each held a roughly 1.2KB JSON payload modeled on a real agent memory record: a couple of chat turns, a few extracted facts, a timestamp. We then ran 3,000 write-then-read operations against each backend, on the same machine. We measured latency per operation with process.hrtime.bigint(). This is a same-host microbenchmark, not a production load test with network hops or concurrent clients. The numbers below describe the floor for each engine, not what you'll see in production.

Key Takeaways

• At small scale, Redis beat PostgreSQL on both write and read latency, but by less than half a millisecond per operation: Redis averaged 0.109ms writes and 0.105ms reads, PostgreSQL averaged 0.188ms writes and 0.171ms reads.
• PostgreSQL's p99 write latency was 1.09ms, about 4x Redis's 0.27ms p99 — the tail is where PostgreSQL's extra overhead (WAL, indexing, MVCC bookkeeping) actually shows up, not the average case.
• PostgreSQL can filter agent memory by its contents directly — "sessions where the plan is pro and more than 10 orders" ran in 2.3ms with a plain SQL query. Plain Redis cannot do this without a secondary index product like RediSearch, because a Redis string value is opaque to Redis itself.

What we actually measured

Agent memory is the state an AI agent keeps between turns or sessions: recent conversation history, extracted facts about the user, task progress. Every agent framework needs somewhere to put it, and the two most common answers are a key-value store like Redis or a relational table in Postgres, often with the pgvector extension bolted on for semantic recall.

We built the smallest fair comparison we could. Same payload. Same operation pattern: point write, then point read, keyed by session ID. Same machine. No batching, no connection-pooling tricks, no cache warm-up beyond the initial seed.

The latency numbers

Backend	Write avg	Write p50	Write p99	Read avg	Read p50	Read p99
PostgreSQL 18.1 (JSONB table, PK lookup)	0.188ms	0.094ms	1.090ms	0.171ms	0.058ms	0.775ms
Redis 8.4.0 (SET/GET string)	0.109ms	0.103ms	0.271ms	0.105ms	0.101ms	0.216ms

Two things stand out. First, the gap in the average case is small, under a tenth of a millisecond on reads. If your agent calls memory once or twice per turn, this isn't what sets your user-facing latency. Your LLM call, at 500ms to several seconds, dominates completely.

Second, the p99 gap is real, and it matches how each engine works, per PostgreSQL's own write-ahead log documentation. PostgreSQL writes go through the write-ahead log, update index entries, and carry MVCC row-versioning overhead. Those exist for durability and concurrent correctness, not raw speed. Redis, with persistence disabled in this test, writes to an in-memory hash table and returns. That tradeoff is the whole story. Postgres pays a latency tax for guarantees Redis isn't making in this configuration.

What Redis can't do that Postgres can

Here is the part the latency table leaves out. We ran one more query. Find sessions where the plan is "pro" and the order count exceeds 10:

EXPLAIN ANALYZE
SELECT session_id FROM agent_memory
WHERE data->>'sessionId' LIKE 'sess_1%'
  AND (data->'facts'->>'orderCount')::int > 10
LIMIT 5;

That ran in 2.275ms, scanning the JSONB column type directly with no extra index. Plain Redis cannot answer that query at all. A Redis string value, the kind our SET/GET benchmark used, is an opaque blob to Redis. It can't look inside the JSON and filter by a field. Doing that means reading every key back to the client and filtering in application code. Or it means adding a secondary product, like RediSearch or RedisJSON, with its own indexing and operational overhead.

This is the actual decision point, not the millisecond difference above. If your agent only ever needs "give me everything for session X," Redis's raw speed wins and the query gap never matters. But say your agent, or your product's support team, or your analytics pipeline needs to ask "which sessions mention a refund," or "which users hit the plan limit this week." Anything that looks inside the memory record, rather than fetching it whole, has to be built on top of Redis. In Postgres, it is already there.

When each one is the right call

Pick Redis when: memory is purely per-session scratch state. You always fetch by the exact session key. You want the lowest possible tail latency, with no query language. Consider, for example, a chat session cache that only needs the last N turns for a currently-active conversation — a textbook fit.

Pick Postgres when: you need to query across sessions. That covers debugging, building a dashboard on what agents are doing, feeding structured facts back into a RAG pipeline, or running semantic search over past conversations with pgvector. The latency cost at this scale is sub-millisecond, and invisible next to your LLM call.

Consider both, in layers, when: you have real production traffic. Redis as a hot-session cache in front of Postgres as the system of record is a standard pattern for a reason. It gets Redis's tail latency on the hot path, and Postgres's queryability for everything else. The two aren't actually competing for the same job, once you look past the headline numbers.

FAQ

Is Redis faster than PostgreSQL for AI agent memory?

For a single key-value write or read, yes, on average — our benchmark measured Redis at 0.109ms average write latency and 0.105ms average read latency, versus PostgreSQL's 0.188ms and 0.171ms, on the same machine with the same 1.2KB payload. The gap widens more in the p99 tail: 0.271ms for Redis versus 1.090ms for PostgreSQL.

Can Redis query agent memory by its contents, like "find sessions with more than 10 orders"?

Not with plain Redis strings. A Redis string value is opaque to Redis's own query capability. Filtering by a field inside the stored JSON means reading every record back to the application and filtering there, or adding a secondary indexing product like RediSearch or RedisJSON. PostgreSQL can run that filter directly against a JSONB column, with ordinary SQL.

Should I use pgvector or Redis for agent memory?

It depends on what "memory" means for your agent. For exact-key lookups of per-session scratch state, Redis's latency profile is simpler and faster. For memory you need to search semantically, say "what did this user ask about before" without an exact key, the pgvector extension on PostgreSQL gives you vector similarity search alongside ordinary SQL filtering in the same database. Redis does not offer that without additional modules, per Redis's own module documentation.

Does the latency difference between Redis and Postgres matter for AI agents?

Usually not on its own. A typical LLM call takes 500ms to several seconds. That dwarfs the sub-millisecond difference measured here between Redis and PostgreSQL for a single memory read or write. The latency gap matters more at high request volume, or when an agent makes many memory calls per turn, not for a single lookup in an otherwise LLM-bound request.