Redis vs PostgreSQL

Quick verdict

Redis keeps its dataset in memory and serves it through commands on data structures (strings, hashes, lists, sets, sorted sets, streams, JSON and more). The current release listed in the Redis documentation is 8.10. Redis 8 and later are offered under a choice of RSALv2, SSPLv1 or AGPLv3; Valkey, the Linux Foundation fork of Redis 7.2.4, is BSD licensed and at 9.1.2 (1 September 2026). How Redis compares with a document database, including its persistence options and licence history in detail, is covered in Redis vs MongoDB.

PostgreSQL is an open source relational database under the PostgreSQL Licence, at 18.6. Every committed change is written to the write-ahead log (WAL) before it is acknowledged, unless you choose otherwise, and it offers SQL, constraints, MVCC transactions and jsonb. It is not an in-memory store, but it has several features that overlap with jobs teams often give to Redis.

This page is about that overlap: when Redis earns its place next to PostgreSQL, and when PostgreSQL alone is enough.

Side by side

Key differences

Complements first: Redis in front of PostgreSQL

The common architecture keeps PostgreSQL as the source of truth and puts Redis beside it for data that is read very often, changes quickly, or can be rebuilt: rendered pages or query results, session tokens, per-user rate-limit counters, feature flags, leaderboards in sorted sets, and background jobs in lists or streams. Redis gives each of these a purpose-built structure and per-key expiry, and it takes that traffic off the database's connections and buffer cache.

The cost is a second system: memory sizing, high availability, security, client libraries, and above all keeping the cache consistent with PostgreSQL. Every write path that changes cached data has to invalidate or update the cache, and the application has to tolerate a stale or missing entry. In our view that cost is worth paying when request rates are high or response times are tight, and often not worth it for a small internal application.

Queues: Redis streams versus SKIP LOCKED

Redis streams are documented as an append-only log with consumer groups: each message is delivered to one consumer in a group, tracked in a pending entries list until it is acknowledged, and can be claimed by another consumer if a worker dies.

// Redis (redis-cli): a job queue on a stream with a consumer group
XGROUP CREATE jobs workers $ MKSTREAM
XADD jobs * job_id 42 type send_email
XREADGROUP GROUP workers worker-1 COUNT 1 STREAMS jobs >
XACK jobs workers <id returned by XREADGROUP>

PostgreSQL can run the same pattern on an ordinary table. The PostgreSQL documentation says that SKIP LOCKED "provides an inconsistent view of the data, so this is not suitable for general purpose work, but can be used to avoid lock contention with multiple consumers accessing a queue-like table". Each worker claims a row that no other worker holds:

-- PostgreSQL 18: jobs table and a worker claiming one job
CREATE TABLE jobs (
  job_id     bigint GENERATED ALWAYS AS IDENTITY PRIMARY KEY,
  payload    jsonb NOT NULL,
  status     text NOT NULL DEFAULT 'queued',
  created_at timestamptz NOT NULL DEFAULT now()
);

UPDATE jobs
SET status = 'running'
WHERE job_id = (
  SELECT job_id FROM jobs
  WHERE status = 'queued'
  ORDER BY job_id
  LIMIT 1
  FOR UPDATE SKIP LOCKED
)
RETURNING job_id, payload;

The PostgreSQL version has one property Redis cannot offer: the job can be inserted in the same transaction as the business change that caused it, so an order and its "send confirmation" job commit or roll back together. The trade-offs are that every claim is a write with WAL and vacuum cost on the same server as your application data, and that very high job rates are where, in our view, a dedicated broker or Redis is the better fit.

Caching and durability: UNLOGGED tables and asynchronous commit

PostgreSQL lets you give up durability selectively. The CREATE TABLE documentation says data in an UNLOGGED table is not written to the WAL, "which makes them considerably faster than ordinary tables. However, they are not crash-safe: an unlogged table is automatically truncated after a crash or unclean shutdown." Their contents are not replicated to standby servers, their indexes are unlogged too, and partitioned tables cannot be unlogged. That profile matches a cache: losing it after a crash is acceptable.

-- PostgreSQL 18: a cache table with expiry handled in SQL
CREATE UNLOGGED TABLE cache_entries (
  cache_key  text PRIMARY KEY,
  value      jsonb NOT NULL,
  expires_at timestamptz NOT NULL
);

INSERT INTO cache_entries (cache_key, value, expires_at)
VALUES ('product:1001', '{"name": "Desk", "price": 120}', now() + interval '10 minutes')
ON CONFLICT (cache_key) DO UPDATE
  SET value = EXCLUDED.value, expires_at = EXCLUDED.expires_at;

SELECT value FROM cache_entries
WHERE cache_key = 'product:1001' AND expires_at > now();

-- run periodically: PostgreSQL has no per-row TTL
DELETE FROM cache_entries WHERE expires_at <= now();

Two limits matter. An unlogged cache lives on the primary only, so reads from replicas do not see it; and it still uses the same memory, connections and vacuum as the rest of the database. Redis, by contrast, expires keys itself and can evict under memory pressure with policies such as allkeys-lru.

For durable tables, PostgreSQL also offers asynchronous commit. The documentation explains that with synchronous_commit off, the risk is "data loss, not data corruption": the window is at most three times wal_writer_delay, and because transactions are replayed in commit order no inconsistency is introduced. It can be set per transaction. Redis offers a similar dial through its persistence settings (RDB snapshots, AOF with appendfsync everysec or always), but its defaults and its data model start from memory, while PostgreSQL's start from full durability.

Notifications: LISTEN/NOTIFY versus pub/sub

PostgreSQL's NOTIFY sends a message on a named channel to every session that has run LISTEN on it. The documentation states that notifications sent inside a transaction are not delivered "until and unless the transaction is committed", that the payload must be shorter than 8000 bytes in the default configuration, that identical notifications in one transaction are folded into one, and that if the notification queue (8 GB in a standard installation) fills up, transactions calling NOTIFY fail at commit. Sessions that are not listening at the time do not receive the message later.

-- PostgreSQL 18: wake workers when a job is queued
LISTEN jobs_ready;                       -- in each worker session
SELECT pg_notify('jobs_ready', '42');   -- in the producer, inside its transaction

That makes LISTEN/NOTIFY a good wake-up signal paired with a jobs table (workers still claim rows with SKIP LOCKED, so nothing is lost if a worker was offline), and a poor message bus on its own. Each listener also needs a dedicated session, which needs care behind connection poolers that reuse sessions per transaction. Redis pub/sub is likewise fire-and-forget; when messages must survive a disconnected consumer, Redis streams are the Redis answer.

Licences, Valkey and managed services

PostgreSQL's licence is permissive and has not changed. Redis moved from BSD to RSALv2/SSPLv1 with 7.4 and added AGPLv3 as an option from 8.0 (details in Redis vs MongoDB). Valkey continues the BSD-licensed line from Redis 7.2.4, and Amazon ElastiCache now offers Valkey, Redis OSS and Memcached, pricing Valkey lower than the other engines. Valkey is a separate code base, so features added to Redis after the fork, such as the Redis 8 JSON and search integration, should not be assumed to exist in Valkey; check its own documentation.

In our view, for a cache or queue next to PostgreSQL the client protocol and core commands are what most applications use, and both Redis and Valkey provide them. If licence terms are a concern for a self-hosted or redistributed deployment, read the licence texts; we describe them but do not give legal advice.

Pricing and licensing

Self-managed. PostgreSQL, Redis Open Source and Valkey are free to run under their licences. Using PostgreSQL alone for queues and caching avoids a second server; adding Redis means paying for memory sized to the working set.

Redis Cloud. Listed on the Redis pricing page in October 2026, in USD: Free (up to 30 MB), Essentials from 0.007 per hour (5 per month), and Pro from 0.014 per hour with a 200 per month minimum, on AWS, Google Cloud and Azure.

Amazon ElastiCache. Serverless (billed per GB-hour of data stored and per million ElastiCache Processing Units) or node-based (per node-hour). Listed on the ElastiCache pricing page in October 2026 for ElastiCache Serverless for Valkey in US East (N. Virginia): 0.084 USD per GB-hour and 0.0023 USD per million ECPUs. AWS states that Valkey is 33% lower than the other engines on Serverless and 20% lower on node-based clusters.

Managed PostgreSQL (Amazon RDS and Aurora, Azure Database for PostgreSQL, Google Cloud SQL, and others) is billed by each provider for instances or capacity units, storage and I/O; use the provider's calculator.

Pricing checked on the vendors' official pages on 7 October 2026. Prices change; confirm before buying.

Where each one leads

Limitations

When to choose each

When neither is right

• You need a durable event log with long retention and replay across many consumers: a dedicated streaming platform or message broker fits better than either.
• You are choosing a document database rather than a cache: see MongoDB vs PostgreSQL and Redis vs MongoDB.
• You want a serverless key-value store on AWS with per-request billing: see DynamoDB vs PostgreSQL.
• Your load is analytical rather than transactional: see ClickHouse vs PostgreSQL.

Final recommendation

Frequently asked questions

Sources

• PostgreSQL documentation: CREATE TABLE (UNLOGGED)
• PostgreSQL documentation: SELECT (locking clause, SKIP LOCKED)
• PostgreSQL documentation: NOTIFY
• PostgreSQL documentation: LISTEN
• PostgreSQL documentation: Asynchronous commit
• Redis documentation: What's new (Redis 8.10)
• Redis documentation: Streams
• Redis documentation: Persistence
• Redis licences
• Redis Cloud pricing
• Valkey project
• Amazon ElastiCache pricing
• PostgreSQL licence

Checked October 2026.

How we research comparisons: our editorial method.