Introduction
ReadySet is a SQL caching engine that acts as a transparent proxy between your application and its database. It intercepts SELECT queries, caches the results in memory, and incrementally maintains those caches as the upstream database changes via replication stream processing. No application code changes are required.
What ReadySet Does
- Proxies MySQL and PostgreSQL wire protocols so applications connect without driver changes
- Caches SELECT query results in memory and serves them with sub-millisecond latency
- Incrementally updates cached results by consuming the upstream binlog or WAL in real time
- Lets you selectively choose which queries to cache via a simple CREATE CACHE command
- Falls through to the upstream database for uncached or unsupported queries transparently
Architecture Overview
ReadySet consumes the replication stream (MySQL binlog or PostgreSQL WAL) to build and maintain in-memory dataflow graphs. Each cached query is compiled into a graph of operators (filters, joins, aggregations) that process change events incrementally. When a row changes upstream, ReadySet propagates the delta through the graph, updating cached results without re-executing the full query. The proxy layer parses incoming SQL, routes cacheable queries to the dataflow engine, and passes everything else to the upstream database.
Self-Hosting & Configuration
- Deploy via Docker or binary alongside your existing MySQL 8.0+ or PostgreSQL 13+ database
- Set UPSTREAM_DB_URL to point at your primary database with replication privileges
- Use CREATE CACHE FROM to designate specific query patterns for caching
- Run SHOW PROXIED QUERIES to discover which queries are eligible for caching
- Configure --memory-limit to control maximum RAM usage for cached data
Key Features
- Wire-compatible proxy requires zero application code changes
- Incremental view maintenance keeps cached results consistent without periodic invalidation
- Sub-millisecond p99 read latency for cached queries regardless of upstream table size
- Selective caching lets you cache hot queries while passing others through to the database
- Dashboard UI shows cache hit rates, query latencies, and replication lag metrics
Comparison with Similar Tools
- Redis / Memcached — General-purpose caches requiring manual invalidation logic; ReadySet automates cache maintenance via replication
- Materialize — Streaming SQL engine for analytical views; ReadySet focuses on transparent OLTP query caching as a proxy
- ProxySQL — MySQL proxy with query routing and connection pooling; does not maintain incrementally updated result caches
- PgBouncer — PostgreSQL connection pooler; reduces connection overhead but does not cache query results
- Neon — Serverless Postgres with compute scaling; different approach to performance (scale compute) vs. caching results
FAQ
Q: Does ReadySet handle writes? A: ReadySet proxies all writes directly to the upstream database. It only caches and serves SELECT queries. Write performance is unaffected.
Q: What happens if ReadySet restarts? A: On restart, ReadySet replays the replication stream to rebuild its in-memory caches. During this warm-up period, queries fall through to the upstream database.
Q: Which query patterns can be cached? A: ReadySet supports a broad subset of SQL including JOINs, aggregations, subqueries, and WHERE clauses with parameters. Run SHOW PROXIED QUERIES to see which of your queries qualify.
Q: Does ReadySet guarantee consistency? A: Cached results are eventually consistent with the upstream database, bounded by replication lag. For most workloads this lag is under 100 milliseconds.