Readyset Cloud is a query caching platform that helps development teams improve the performance and scalability of their applications without code rewrites, query optimization, or infrastructure overhauls.
This blog walks through the overarching process for how to set up Readyset Cloud as a caching layer for a data-driven application.
It’s intended as a high-level overview– for step-by-step instructions, see the official Readyset Cloud onboarding documentation.
Step 1: Create a Readyset cluster and connect it to your database
First, you’ll create a Readyset cluster and connect it to your database.
One of Readyset’s most powerful features is that it tracks all of the data changes being made to your database in real-time, and uses these to make sure that all cached query results are kept up-to-date. This ensures that your application is always served fresh data.
For Readyset to keep caches up-to-date automatically, a replication stream needs to be established between it and your database. Setting up this replication stream is straightforward– by providing Readyset with your database’s connection info, it’ll automatically open a replication slot and start receiving data change updates. See the cluster creation docs for more information.
Once Readyset connects to your database, it will also trigger a snapshot of the base tables. Readyset keeps a local copy of base tables on disk so that it never needs to query your database to maintain its internal cache state. By default Readyset snapshots all tables in the selected database. You can configure which base tables get pulled in to limit them to just the set that you’ll be caching from.
When Readyset is finished snapshotting, you’re ready to move on and start caching. You will be provided with a standard Postgres connection string you can start sending query traffic to.
Step 2: Understand how caching works in Readyset
Before moving on to the next step, it’s important that you first understand the high-level mechanics of how Readyset caches queries so you can decide how to use it in your context.
How caching in Readyset works
Readyset caches broad query patterns, which you can think of as prepared statements– queries without the parameters filled in. For example, you don’t need to tell Readyset to cache both:
“SELECT count(col1) FROM table WHERE table.col1 = 5”
as well as
“SELECT count(col1) FROM table WHERE table.col1 = 7”.
Rather, you just tell it to always cache:
“SELECT count(col1) FROM table WHERE table.col1 = ?” and both of the above queries would then be cached.
Readyset doesn’t cache all queries by default– caches are explicitly specified by users.
Proxying writes and uncached reads
All of the traffic sent through the Readyset connection that matches the cached query patterns gets resolved within Readyset’s caches, so reads will be lightning-fast.
Queries that don’t match the caches (including writes in the form of
DELETEs) are proxied along to your database.
Step 3: Start caching queries
Now that you understand how caching in Readyset works, you’re ready to create caches.
Point your app to Readyset
First, you’ll need to modify your app to start sending queries to Readyset. Since Readyset is wire-compatible with Postgres, all you have to do is swap out a connection string.
You can use your Readyset connection string from step one of this guide in your application as you would that of a primary database or read replica.
If you swap your primary database connection to be Readyset’s, your app will continue working as normal but you will be proxying writes and uncached queries to Readyset.
If you use Readyset as a read replica, then a subset of your reads will be sent to it, and within that subset, Readyset will only proxy uncached reads to your database.
Certain ORMs are more prescriptive on which option you choose. See the most up-to-date guidance for each ORM in the Readyset connection documentation.
Run traffic through Readyset
Once you point your app to Readyset, you’ll need to run some traffic through it so it can discover the queries your application runs. You can do this by clicking around in your application, or if you have a load generator, you can also use that.
After you run traffic through Readyset, it will show you all of the queries that are being issued by your application, and indicate which ones you are able to cache. Following our caching documentation to create the caches– you can do this in just a few clicks.
Step 4: You’re off to the races!
That’s it! With Readyset caching queries, you should start consistently seeing query latencies on the order of single-digit milliseconds, no matter how complex the computation.
That means you get much more bang for your buck in terms of how many queries you’re able to serve using the same amount of compute resources as compared to a standard database or a read replica.
Readyset Cloud therefore helps you scale more efficiently than traditional vertical or horizontal scaling approaches. And on top of that, no query optimization experience was required!
Now, try it out yourself
Readyset Cloud offers a full-featured one month free trial. Give it a try yourself!