Postgres vs Redis Cache Performance: Benchmark Shows 2/3 Speed but Sparks Debate Over Test Validity

A recent benchmark comparing PostgreSQL and Redis for caching has stirred significant discussion in the developer community, with the results showing PostgreSQL achieving roughly two-thirds the performance of Redis while raising questions about the testing methodology itself.

The original study tested both databases using Kubernetes clusters with specific resource limits, finding Redis consistently outperforming PostgreSQL across different workloads. However, the benchmark has drawn sharp criticism from the technical community for its approach and conclusions.

Performance Comparison Results

Test Configuration:

• Hardware: 20 CPU cores limit, high memory allocation
• Database versions: PostgreSQL 15, Redis 7
• Dataset: 10 million entries
• Test duration: 1 minute per benchmark
• Cache hit rate: 80% for GET operations, 10% update rate for SET operations

Flawed Testing Methodology Undermines Results

The benchmark's validity has come under intense scrutiny from developers who point out fundamental issues with the test setup. Critics highlight that PostgreSQL was CPU-bound at 100% utilization on its allocated cores, while Redis was bottlenecked by the HTTP server rather than the database itself. This means the comparison wasn't measuring the true performance potential of either system under fair conditions.

The testing approach also failed to utilize performance optimization techniques available to both systems. For Redis, features like pipelining and auto-pipelining clients could potentially deliver 10x performance improvements. PostgreSQL similarly supports query pipelining through popular client libraries, which wasn't explored in the benchmark.

Resource Utilization During Tests

Redis Performance:

• CPU usage: ~1,200-1,280 mCPU (well below 2,000 mCPU limit)
• Memory usage: 3,800-4,300 MB
• Bottleneck: HTTP server, not Redis itself

PostgreSQL Performance:

• CPU usage: 100% of allocated 2 cores (2,000 mCPU limit)
• Memory usage: 5,000-6,000 MB
• Bottleneck: Database CPU utilization

Key Finding: PostgreSQL was CPU-bound while Redis was limited by the HTTP server, making the performance comparison potentially misleading.

The Real-World Performance Question

Beyond the methodological concerns, the community debate reveals deeper questions about practical performance needs. The benchmark showed PostgreSQL handling around 1,500 requests per second, which translates to over half a billion requests per day. For most applications, this level of performance far exceeds actual requirements.

Many developers argue that the choice between Redis and PostgreSQL for caching shouldn't be based purely on raw performance numbers. The decision often comes down to operational complexity, existing infrastructure, and whether the performance difference actually matters for the specific use case.

Operational Trade-offs and Dependencies

The discussion has highlighted significant operational considerations that pure performance benchmarks miss. Redis offers built-in features like automatic key expiration (TTL) that are essential for effective caching. Implementing similar functionality in PostgreSQL requires additional components like cron jobs and custom expiration logic.

Having the ability to set a TTL on the cache key is a critical feature of a cache, not something that can be tacked on later.

However, proponents of the PostgreSQL approach argue that avoiding additional dependencies can be valuable, especially for smaller projects. They point out that most applications already require a database, so using PostgreSQL for caching eliminates the need to manage another service. The cost considerations also favor this approach, as PostgreSQL instances are often underutilized and can handle additional caching workload without extra expense.

Alternative Solutions and Future Directions

The debate has also brought attention to hybrid solutions like Redka, which provides Redis API compatibility backed by SQLite or PostgreSQL. This approach attempts to combine the familiar Redis interface with the operational simplicity of SQL databases.

Some developers have suggested that PostgreSQL could benefit from native caching features, such as the ability to mark timestamp columns as expiry columns that would be automatically handled by the database's vacuum process. Such features would make PostgreSQL more competitive for caching use cases without requiring external tools.

The benchmark controversy ultimately reflects a broader tension in software architecture between performance optimization and operational simplicity. While Redis clearly offers superior raw performance for caching workloads, the real-world decision involves weighing that advantage against factors like infrastructure complexity, cost, and actual performance requirements. For many applications, the good enough performance of PostgreSQL may be more valuable than the peak performance of Redis, especially when considering the total cost of ownership and operational overhead.

Reference: Redis is fast - I'll cache in Postgres