Readyset widens its cache by rewriting more SQL into shapes its dataflow engine maintains

A conventional database executes a query when it arrives. Readyset builds a dataflow graph for each cache and updates the stored result as upstream rows are inserted, changed or deleted ^[3]. A read is then a lookup into a result that already exists ^[3]. Readyset sits between the application and an existing MySQL or PostgreSQL database ^[19].

The graph sets the limits. It is a set of operators that process changes over time ^[18]. According to Zarouba's April 28 post ^[2], the engine favors two-input joins on equality predicates and cannot execute a correlated subquery once for every row of an outer query ^[5]. SQL lets developers write the same task as a nested query, a common table expression or a join ^[12]. The engine takes only some of those forms. The compiler's job is to translate the others without changing their results ^[1].

It does that in order:

1. Normalization resolves tables and columns, expands SELECT * and rewrites JOIN ... USING as explicit join conditions ^[6]. 2. Deep rewrites turn some subqueries into joins and flatten derived tables where the meaning holds ^[21]. 3. Cleanup strips redundant clauses and replaces literals with parameters so structurally similar queries share one dataflow graph ^[7].

The third step is easy to overlook. Without it, each distinct literal value would describe its own query shape and its own graph ^[7].

The supported set moves between posts. Zarouba's August 20 follow-up ^[9] adds subquery rewrites in four positions ^[22], each a place where a careless rewrite returns a different answer ^[10]. I think the fallback is the best decision in the design. When the compiler cannot transform a query safely, the query goes to the upstream database without a cache ^[11]. A declined rewrite costs the application the same database query it was already running.

Speed is the wrong first question for this product. Any latency figure for a Readyset read describes queries that compiled ^[1]. For that figure to transfer to an existing app, the app's hot queries have to compile too. The share of read load Readyset absorbs is the share of query executions whose shapes the compiler accepts. A query can be valid upstream and still miss a deep cache ^[8].

Marzoev's founding thesis was that developers should not have to build and maintain their own cache-invalidation systems to scale reads ^[17]. The invalidation logic still has to exist somewhere, and Readyset's bet is that one compiler team writes it once ^[17]. The pitch goes to teams already weighing custom caches, read replicas or changes to their queries ^[16].