Cloudflare recently announced the "production ready" switch on three products: their serverless SQL database D1, time series Workers Analytics Engine, and database query optimizer Hyperdrive.
Cloudflare’s D1 introduces critical features such as support for 10GB and 50,000 databases per account, new data export capabilities, and enhanced query debugging, dubbed "D1 Insights." It also commits to maintaining the free tier and the pricing model introduced during the open beta.
Next, the Workers Analytics Engine leverages Cloudflare's established ClickHouse-based system. It enables scalable, unlimited-cardinality analytics by allowing workers to write data points and query them via an SQL API. It has become essential for various use cases, from monitoring service health to billing and customer usage analytics, now supported by a simple pricing model based on written data points and read queries without penalties for complexity or cardinality. Currently free, with planned pricing to include allocations for data points and queries, the engine supports developers in quickly creating custom analytics, inviting feedback as it prepares for broader pricing implementation.
Finally, Hyperdrive, launched into open beta last September and now generally available, optimizes centralized databases to perform globally using Cloudflare's network for faster access, connection pooling, and query caching. It supports popular drivers and ORM libraries without the need to re-learn or rewrite queries, and ongoing expansions include MySQL support and enhanced configurability for performance versus data freshness. Hyperdrive is provided free for developers on a Workers Paid plan.
InfoQ spoke with Rita Kozlov and Matt Silverlock, both senior directors of product at Cloudflare, about the D1 global database and Hyperdrive.
Cloudflare mentions the upcoming features for D1, such as global read replication and the ability to maintain session-based consistency, which is crucial for scalability and user experience. However, managing global data consistency while minimizing latency is a significant challenge in distributed systems.
InfoQ: Could Cloudflare share more about the technical strategies or algorithms it employs to ensure data consistency across global read replicas? How does Cloudflare balance the consistency, availability, and partition tolerance (CAP theorem) trade-offs in D1's architecture?
Rita Kozlov/Matt Silverlock: We discussed how D1 provides snapshot isolation in the "Building D1"; blog post that went out today. We also tend to think about databases in terms of formal consistency models vs. CAP theorem, which doesn’t often model real-world scenarios or use cases.
We use Lamport timestamps as part of a monotonically increasing "commit token" concept.
Suppose D1 gives applications a Lamport timestamp for every database query, and those applications tell D1 the last Lamport timestamp they've seen. In that case, each replica can determine how to make queries work according to the sequential consistency model.
D1 thus:
Associates a Lamport timestamp with every single request to the database. A monotonically increasing commit token works well for this.
Sends all write queries to the primary database to ensure the total ordering of writes.
Sends read queries to any replica but has the replica delay servicing the query until the replica receives updates from the primary database later than the Lamport timestamp in the query.
It was (is!) important to us to ensure that developers can benefit from the performance & latency gains of read replicas without being database consistency experts.
In addition, regarding Hyperdrive's impact on Legacy Database Performance, Hyperdrive is designed to make centralized databases feel global and faster by leveraging Cloudflare's global network. This service could significantly impact how developers interact with their existing databases and potentially alter the traditional database performance tuning practices.
InfoQ: Could Cloudflare provide insights into how Hyperdrive optimizes query performance and its implications on database design and optimization practices? Specifically, how do query caching and connection pooling work under the hood to reduce latency, and what best practices should developers follow to maximize the benefits of Hyperdrive for their applications?
Kozlov/Silverlock: In most serverless models, establishing a database connection per request is slow: really slow. It’s 6+ round-trips to set up a connection and to run a query, and that far eclipses the latency incurred from anything else in the application.
Hyperdrive instead maintains a set of connection pools within Cloudflare’s network — as opposed to just the connection pool next to the database — so that connections can be reused across function invocations. That’s on top of using our global network to get queries from the compute (potentially running close to the user) back to the database — using our backbone to take a faster, less congested path there.
On the query caching side, Hyperdrive knows the difference between a mutating (write) or non-mutating (read) query and can automatically cache read queries. For queries you run frequently—such as those generating product pages or inventory listings—being able to cache the results avoids having to a) go back to a database that is potentially far away from the user and b) reduce the load on the database by not having to query it at all!
Notably, developers don’t have to do much to benefit from Hyperdrive: we designed it that way. We didn’t want developers to use or learn a Cloudflare-specific library to talk to their database. They can replace one line of code in their existing database driver with the connection string Hyperdrive gives them and immediately benefit from it.