ElectraDB
Articles

Coming soon: databases that move closer to your application

Roadmap

Tell us where your application runs and we will place your database, and over time move it, to the servers with the lowest latency to it.

Why distance matters more than server speed

Every query your application sends travels to the database and back before your code can continue. Within one city, that round trip takes about 1 ms. Between two cities across Europe, it takes 20 to 40 ms, and no amount of CPU or memory on the database server makes light travel faster.

A single query rarely shows the difference, but most requests in a web application send several queries one after another: load the session, load the user, load the order, check the stock, write the change. An application that sends 10 queries in sequence for one page pays the round trip 10 times. At 1 ms that is 10 ms in total; at 30 ms it is 300 ms, before the database has done any work at all.

Choosing the right region already removes the largest distances: a database in the EU is far closer to an application in Frankfurt than one in the US would be. Within a region, though, our servers are spread over several sites on purpose, and the distance between your application and the site that runs your primary still decides a large part of your response time.

How placement works today

When you create a database, we pick its servers by capacity. A high-availability database gets two servers in different sites of your region, the ones with the most free memory, and with the server that holds the deciding vote they form its constellation; a single-node database gets the one server with the most free memory. Nothing in that choice looks at where your application runs.

After that, roles float. If the primary's server fails, the standby is promoted and stays the primary after the failed server is replaced (see What happens when a server fails). So even a database whose primary happened to start in the site nearest to you can end up serving from a site further away, and stay there.

You can already measure the distance before you choose a region. The create form has a Check latency from your servers option: you enter your server's public IP address, each of our data servers in the region pings it five times, and you see the result per site, rated Good (under 50 ms) or Poor. Today that helps you pick a region. The feature described here uses the same measurement to pick the servers inside it.

What we are building

You will be able to tell us where your application runs, and we will place your database close to it and keep it there.

  1. You give us the public IP addresses of your application servers. This is optional, set per database, and you can change it at any time, for example when you move your application to another data centre.
  2. We measure the latency from every data server in your database's region to those addresses, with the same ping probe as the latency check. We keep measuring after the database is created, because routes between networks change and new servers join.
  3. Placement prefers the closest site for the primary. The primary takes your writes and usually most of your reads, so it should be where the round trip to your application is shortest. A single-node database simply goes to the closest server.
  4. The standby goes to the next-best other site. High availability still needs two sites, so the standby never shares the primary's site. Where it goes is a trade-off: with synchronous replication, every commit waits for the standby, so the distance between the primary's site and the standby's site is added to each write. The standby is also where your traffic goes after a failover. We weigh both: the standby's distance to the primary and its distance to your application.
Where the primary and the standby goYour applicationthe IPs you give usYour regionSite ASite BSite CPrimaryshortest round tripStandbynext-best other siteNo membersynchronous replication
Each data server in the region measures its round trip to your application. The primary goes to the site with the shortest one; the standby goes to another site, weighed by its distance to the primary and to your application.

Moving closer over time

A good choice on the day you create a database does not stay good forever. Routes change, we add servers and sites to your region, and failovers move the primary to the other site. So the placement is not decided once: we will keep comparing where your database runs with where it would be best, and move it when the difference is worth it.

A move works like a plan change does today:

  1. We build a new copy of your database on the closer server, while the current members keep serving your traffic as before.
  2. Once the new copy has caught up and is a streaming standby, a planned switchover makes it the primary. This causes a few seconds of reconnects, as a plan change does.
  3. The copy that is no longer needed is removed.
Moving the primary to a nearer site1. Before2. New copy catches up3. After the switchoverNearer siteThe primary's site todayThe standby's siteNo copyPrimaryserves your appStandbyNew copycatching upPrimaryserves your appStandbyPrimaryserves your appOld copyremovedStandby
The current members keep serving while a new copy catches up on the nearer server. A planned switchover makes it the primary, and the copy that is no longer needed is removed. Your connection string stays the same.

Because the primary has a preferred site, a failover is no longer the end of the story. After the failed server is replaced, the primary can be moved back to the nearer site with a planned switchover, at a time we choose, rather than staying wherever the failover left it.

What it will not do

  • It never leaves your region. Your database, its standby and its backups stay in the region you chose. Latency picks servers inside the region, never outside it (see Regions and data residency).
  • It respects capacity. If the closest server is full, we use the next-best one. We do not overcommit a server to bring a database closer.
  • It does not flap. A database moves at most once in a while, and only when the gain is clear. Every move is announced in the database's events, so you see when and why it happened.
  • It does not change how you connect. Your hostname and connection string stay the same; the names follow the members, as they do after a failover today.
  • You stay in control. You can turn it off for a database, or pin a database where it is.

At first it will be opt-in: nothing changes for a database until you give us addresses for it. Placement for everyone else stays as it is today.

When it will be ready

We are building it now and do not promise a date. When it is released, it will be described in the guides, and this article will be updated with what changed from the design above.

Until then, the best way to keep your database close to your application is to choose the region with the latency check in the create form, and to write your application so it does not send more queries in sequence than it needs. If you have an application where this would help, or a case the design above does not cover, tell us at [email protected]. Feedback now is easier to act on than after the release.