Simeon Griggs [@simeonGriggs] | February 19, 2026Cloudflare recently launched Hyperdrive, which provides efficient pooling and fast queries for any MySQL or Postgres database—making optimizing how your application connects to your database incredibly easy. Once you're operating inside the Cloudflare network you get access to the full suite of features, including WebSockets—which we can use to build a real-time experience.In this post, I'm going to outline the decisions made along the way while building a real-time application backed by PlanetScale Postgres Metal.You may note an absence of “how to” code snippets for application code or SQL queries in this post. I’m anticipating that you’re building by describing what you want to an LLM, and so this blog post is describing what I did (and didn’t) do.The infrastructure stackPlanetScale Postgres Metal is the benchmarked fastest cloud Postgres, so it makes sense to pair it with the fastest cloud services. PlanetScale Metal databases are powered by blazing-fast, locally-attached NVMe SSD drives instead of network-attached storage.Cloudflare Hyperdrive enables fast access and automated connection pooling to Postgres and MySQL databases, making it an excellent, almost zero-config way to build high-performance applications. When hosted on Cloudflare Workers you unlock access to network benefits of being inside of the Cloudflare global network, including WebSockets, which can power real-time applications in combination with Durable Objects.That paragraph contains a lot of names of things—it's helpful to unpack each of these and understand how they intersect.The Cloudflare global network is infrastructure that runs all Cloudflare services with physical locations within ~50ms of 95% of the world's internet-connected population, along with faster-than-average connections to almost every service and cloud provider.Cloudflare Hyperdrive automates away the headaches of connection latency and pooling to turn your single-origin database into a globally distributed and cached source of truth. It is made of two separate yet equally important parts.The edge component runs globally from within every Cloudflare data center and prepares the 7 round-trip steps of creating a connection to your database within the Cloudflare global network.The connection pool is enabled physically close to your database and maintains warm connections to Postgres which are automatically given to incoming requests.Cloudflare Workers is a platform for globally distributing and running your application. While it may be beneficial to run your application close to your users, performance could be improved by moving the application closer to the database through "smart placement," which we'll cover later in this post.Durable Objects are stateful, single-origin request handlers for coordinating tasks. Each one lives in one data center and holds in-memory state—like a list of open WebSocket connections.WebSockets are supported by Cloudflare and in this post we'll use them to coordinate real-time updates from the PlanetScale Postgres database via a Durable Object.Hyperdrive vs direct connectionsIf you're interested in a demo comparing Hyperdrive vs direct connections to the database, Jilles Soeters at Cloudflare has a great demo you can check out: Globally Fast Applications with Cloudflare Hyperdrive and PlanetScale.The frontend stackOut of interest, I'm using React Router 7 as my front-end framework along with Tailwind CSS. I won't go into detail here because I'm not sure that these choices matter as much as they used to. I think React is an excellent choice because of the support it has for fast user interfaces.Cloudflare has a React Router 7 starter template preconfigured for deployment to Workers.I've historically enjoyed working with React Router 7, but while building this demo, rarely did I look at the internals of this application to see how it is written at the framework level.Piecing the puzzle togetherThese are all excellent choices for building fast applications. But how and where you put these pieces together still greatly impacts the performance.For example, if we're going to use a Durable Object to broadcast updates over WebSockets, it may be tempting to make the Durable Object the write path to the database. However, this negatively impacts performance. Durable Objects are single-threaded and hosted in a single location, making them a bad candidate for the write path.Instead the Workers will send transactions to the database via the Hyperdrive connection.There's also a question of when to leverage the global network or not. Globally distributing the application via Workers places it around the world, but these locations could be far from the database and the Hyperdrive connection pool—which both exist in a single origin, putting any latency between the Worker and your database. Through "smart placement" the Worker can be moved to a single location, moving latency between the user and the Worker while greatly reducing the latency to the database.In this application I’ve chosen not to use smart placement and keep the Worker closer to every user. Monitor your own application’s performance and needs closely to see if keeping the connection between Worker and database is more useful than between Worker and user.Finally, you need to determine whether WebSockets alone are considered a bulletproof source of real-time information in your application. In this demo, we'll leave out reconnection logic, which could help with any failed WebSocket updates. And we could have added periodic polling to run in addition to WebSockets to manually catch up any missed updates.Essentially, we've got to draw the line somewhere. This app is going to demonstrate extreme performance, but as always your mileage may vary and how suitable this is for you will depend on the workload of your application.Problem solvingIt is one thing to build an app which returns fast queries through Hyperdrive's connection pooling and caching. I want this demo to include more.In a nutshell, our demo app recreates the appearance of much of the functionality of a "prediction market," where users can buy options of either a "Yes" or "No" position on each market. The price of each option fluctuates based on the current volume of purchases on either position.This functionality creates several layers of complexity which will need to leverage all of the previously mentioned Cloudflare functions.Fast reads: Prediction markets are based on the outcome of real, live events. Therefore, the latency to retrieve the most up-to-date information is critical.Real-time updates: Users should not have to refresh the page in order to see up-to-date information and should be able to observe changes in real-time such as trends and purchase activity across the markets.Fast writes: Since the price of options can be volatile, it is important that transactions are sent with the currently correct price as well as updated in the database fast enough to broadcast updates to all other users.Step 1: Connecting HyperdriveYou can connect Hyperdrive to a database through the Cloudflare dashboard or CLI as well as during the creation of a PlanetScale Postgres database.In the PlanetScale dashboard I'll select the smallest Metal database, which starts at $50/month. Though the $5/month non-Metal database could be an option for this demo too.Once the cluster is ready I can choose to create a new role and follow the instructions to create a link between PlanetScale and Cloudflare.The result is a connection string which I add to my application's wrangler.jsonc file{