PostgreSQL UNLOGGED Tables vs. Redis: Where Postgres Caching Breaks

Every six months, a startup engineering team decides to rip Redis out of their stack and move all session caching and AI agent state into PostgreSQL UNLOGGED tables. On paper, the math looks great. You drop a $140/month managed ElastiCache cluster, eliminate cache-to-database network hops, and query your cached JSON blobs using standard SQL joins. Then traffic hits 2,500 writes per second. Latency spikes from 1.8ms to 190ms, disk I/O saturates despite Write-Ahead Logging (WAL) being turned off, and your primary database CPU pins at 94%.

Skipping WAL Does Not Skip MVCC Dead Tuples

The biggest misconception about CREATE UNLOGGED TABLE is that it turns PostgreSQL into an in-memory key-value store. It doesn't. Skipping the WAL only removes the sequential disk write required for crash recovery. Every single UPDATE on an UNLOGGED row still obeys PostgreSQL's Multi-Version Concurrency Control (MVCC) rules.

When an AI workflow updates a conversation state row 15 times during a single multi-step tool call, Postgres does not overwrite that 12KB JSONB payload in place. It marks the old tuple dead and writes 15 brand-new tuples into the heap page. If your primary key index isn't getting HOT (Heap-Only Tuple) updates because you indexed a secondary expires_at or tenant_id column, every state mutation rewrites the B-tree index too.

We audited a logistics platform where a 400MB active session cache ballooned into an 18GB UNLOGGED table in 36 hours. Because the default autovacuum_vacuum_scale_factor waits until 20% of a table changes before kicking in, dead tuples piled up faster than background workers could reclaim them. Sequential scans and index lookups had to wade through thousands of dead row versions just to read a single active session token.

The Failover Trap Nobody Tests in Staging

Read the PostgreSQL documentation carefully and you will spot a brutal operational reality: UNLOGGED tables are automatically truncated whenever the database restarts after an unclean shutdown. Most teams shrug this off because a cache is supposed to be ephemeral.

Here is what actually breaks in production. First, UNLOGGED tables are not replicated to physical standby nodes. If you trigger an automated RDS or Cloud SQL failover during a traffic spike, or if your primary instance hits an Out-Of-Memory (OOM) kill, the promoted replica comes up with zero rows in your cache table. Any read query hitting a physical read replica throws ERROR: cannot read from unlogged relation. Suddenly, 100% of your application traffic slams cold storage at the exact moment your database is recovering from a crash.

When UNLOGGED Tables Actually Work (And How to Tune Them)

We still use PostgreSQL UNLOGGED tables in production, but only for specific workloads: idempotency keys, webhook deduplication windows, and write-once-read-many LLM semantic caches under 1,000 requests per second. If your workload mostly inserts a key, reads it four times, and deletes it an hour later, Postgres handles it at ~0.6ms p50 read latency straight out of shared_buffers.

If you build a Postgres-backed cache, you cannot leave table storage parameters at their defaults. You must override autovacuum per table (autovacuum_vacuum_scale_factor = 0.01, autovacuum_vacuum_cost_limit = 1000) and set a fillfactor = 70 so updates have room on the same 8KB heap page to trigger HOT updates. For TTL expiration, never run a massive DELETE FROM cache WHERE expires_at < NOW() every hour—that locks pages and floods the free space map. Run a pg_cron job every 60 seconds using DELETE ... WHERE ctid IN (SELECT ctid FROM cache WHERE expires_at < NOW() LIMIT 5000) SKIP LOCKED.

Drawing the Line Between Postgres and Redis

Keep Redis when you need atomic rate-limiting counters, pub/sub fan-out for streaming agent events, or high-frequency state mutations where each key gets updated dozens of times per second. Use PostgreSQL UNLOGGED tables when your cached payloads are write-once, under 10,000 RPM, and benefit from joining directly against tenant permission tables.

If your database CPU is creeping up from background job state or your cloud bill is bloated with idle caching clusters, check how Enorexa architects lean backend infrastructure or talk to us to benchmark your production workload before you migrate.