Gold Lapel vs ReadySet

Overview

ReadySet is a caching proxy for PostgreSQL. It intercepts SELECT queries, maintains in-memory materialized views using Noria (a dataflow engine), and serves cached results with automatic invalidation when the underlying data changes. It is, in essence, a transparent Redis-like cache that speaks the PostgreSQL wire protocol.

Gold Lapel is an optimization proxy. Rather than caching results outside the database, it optimizes how PostgreSQL itself produces results — creating indexes for slow filters, materializing repeated aggregations as PostgreSQL materialized views, and batching N+1 query patterns. The optimizations live inside PostgreSQL, not in a separate data store.

Feature comparison

The philosophical difference

ReadySet's approach: move the data out of PostgreSQL and into a faster in-memory store. Serve reads from the cache. Keep the cache consistent via change data capture from the WAL.

Gold Lapel's approach: make PostgreSQL itself faster. Create the indexes it needs, precompute the aggregations it repeats, and batch the query patterns that waste round trips. The data never leaves the database.

ReadySet can deliver sub-millisecond reads because it serves from memory. Gold Lapel typically achieves 1-5ms reads because it still goes through PostgreSQL — but with the right indexes and views in place, PostgreSQL is remarkably fast.

When to use ReadySet

ReadySet excels at read-heavy workloads where sub-millisecond latency matters and the supported query patterns align with what ReadySet can cache. It is particularly effective for repeated point lookups and simple aggregations on datasets that fit in memory.

When to use Gold Lapel

Gold Lapel excels at complex query optimization — joins, aggregations, N+1 patterns, and workloads where the query diversity is high. Because it optimizes at the database level, it supports the full range of SQL features natively.