by Alana Marzoev
Co-Founder and CEO
April 6, 2022 - 6 min red
To accomplish this, we're building a high-performance SQL caching engine and performance monitoring solution that pairs with your existing database to help ensure that query response latencies are always sub-millisecond. ReadySet makes it easy for developers to retrofit scalability and performance onto existing applications without code changes. It also enables developers to build new applications from the ground up without having to worry about performance from day zero.
Why We Built This
“The data access layer of a million-dollar idea starts out as a single-server relational database. You’re hardly worried about scale issues – you have an application to write! However, if your million-dollar idea ends up being worth even $100K, you’ll likely find your database struggling to keep up with the scale.” — Vova Galenchenko
Performance has arguably never been more important. Today we're dealing with larger and larger datasets, more complex queries, fundamentally higher request volumes. The Internet is a much bigger place than it used to be. In a sea of competing apps, being snappy and performant isn't an advantage anymore; it's table stakes. Laggy page load times have been shown to tank key business metrics like conversion rates, so our web apps need to be fast at any scale.
But how do you actually make a fast web app? There's an entire world of performance optimization on the frontend, from bundlers to lazy loading and even offloading complex interactivity to WebAssembly. But the biggest bottleneck in your app’s performance is probably the same as everyone else’s: it’s your database. Your app is only as fast as your slowest query, and as you scale up things inevitably get harder.
Current standards for scaling out databases
Outside of adding indexes for improving performance on specific queries, when confronted with database read performance regressions, there are a few common approaches:
Build custom caching layers on top of key-value stores like Memcached or Redis. This approach requires developers to write code to maintain the cache, ensuring that results are fresh, and also to rewrite the application to communicate with the new caching layer. Since homegrown caching layers tend not to be SQL-native, the application-cache communication code cannot rely on SQL-compatible tooling like ORMs.
Provision database read replicas and load balance between them. These read replicas are expensive, prone to replication lag, and since they still compute query results from scratch, often fail to meet latency requirements for the application.
Many workloads require both caches and read replicas, and the resulting tightly-coupled, Frankenstein data layers take significant engineering effort to build and maintain. Moreover, they introduce application and operational complexity that make them prone to failures and outages.
There are only two hard things in Computer Science: cache invalidation and naming things. — Phil Karlton
After speaking to countless developers about their pain points around database read scaling, my PhD labmate Jon Gjengset and I decided to start ReadySet to tackle this problem head on. ReadySet expands upon and commercializes the ideas introduced by the popular open-source research project database Noria, which was built over our time at MIT.
At ReadySet, we believe there is a better way. Today, we’re excited to introduce our namesake SQL caching engine that fully automates cache maintenance and can be used without code or database changes.
Sounds too good to be true? Here’s a little more about how this actually works:
ReadySet supports sub-ms query latencies at scale. Under the hood, ReadySet incrementally maintains SQL query result sets over time as the underlying data in your database changes due to writes. Rather than writing code to trigger a cache eviction once some staleness criteria is met, ReadySet automatically repairs existing cached results to reflect data changes due to writes. For example, if you’re caching a
COUNT, and there’s an additional row that gets written that adds to that count, rather than recomputing the result from scratch, ReadySet updates the prior
COUNT result by incrementing it by 1. You can read more about ReadySet’s internals (sneak peek: partially-stateful, streaming dataflow) here.
ReadySet horizontally scales read throughput for cached queries. ReadySet cache nodes can be sharded, replicated, and geo-distributed around the world. There is no inter-worker communication between these cache nodes on reads, so throughput scales linearly with the number of cores.
ReadySet provides developers with the straightforward experience of a single-node relational database. ReadySet is wire-compatible with MySQL and Postgres and can be integrated into existing applications by simply changing a connection string.
ReadySet’s mission is to help developers build faster applications with little or no effort required. Our first product helps speed up existing databases with a basic caching layer built on incrementally updating views of result sets, but there’s a lot more we’re excited about. Imagine a SQL-oriented CDN that intelligently caches query results around the world based on user access patterns, and automates compliance to data locality regulations introduced by legislation like GDPR with the goal of enabling companies to serve global user bases without re-engineering their data layer. We’re excited for a faster future.
Fueled by $28M from top VCs (read more about our funding here), we’ve grown the team to 19 people strong over the past year, and have partnered with a few early design partners to build out a strong product foundation. We’re actively hiring across tons of roles – check out our careers page for more information!
In the meantime, you can learn more about ReadySet by watching our demo and reading our docs. If you’re interested in getting early access to ReadySet, you can sign up for our waitlist here. If you have questions or comments, feel free to reach out at email@example.com.