Deploying to the Edge is the new cool thing developers do. And why wouldn’t you? Being able to deploy code that runs everywhere without worrying about picking locations yourself, and always being a couple of milliseconds away from your users? What’s not to like?

It’s true: the internet “feels faster” once you step in the US. And it’s also true that Edge compute helps to make this better. But the moment you need to provide a dynamic experience, things get muddier. Likely your database is somewhere in the US, so fetching data from it will add a considerable amount of latency.

How databases compare

Vercel has recently announced a cool demo tool that allows you to pick a database, and test the latency from Edge functions to the database. Each database is assigned a preferred region, and the test will fire 10 requests directly to that region, and another 10 requests through the edge region closer to you.

Here’s an example of what the output is for me using the Planetscale database. The light blue line shows the regional latency — the latency when the edge function is executed closest to the database, and the purple line shows the latency when the edge function is executed closest to me, the user.

I am a couple of hours away from Toronto, so what the graph above shows is that life is great in North America. In particular, if you are on the East Coast. us-east-1 is AWS’s largest region, and it’s where databases tend to be. This graph shows me that there is an edge function even closer to the database, (the delta between the purple and light blue lines), but I am only 20ms away.

You can see from the graph in the right (end-to-end time) that there is around 100ms between me and their closest edge function, but ultimately, edge will work great for me: the database is always close!

Things are different in other places

But some other members of my team are not so lucky. For my colleague Athos, in Rio de Janeiro, Brazil, the situation is very different.

For the graph on the left, with browser time excluded: while the regional latency is unsurprisingly the same, the latency from his closest edge functions is over 120ms.

The graph to the right, which includes browser time, shows that ultimately it doesn’t matter much if he goes directly to the database or through his closest edge function. He’ll always be some 20 to 50 ms behind me.

Real life is often more complex

This example is quite simple. A single query, a single hop. What happens if we need to have a complex pattern, where you query the database 5 times in a row to serve a request? The Vercel demo also allows us to test that scenario, which is a lot closer to real life situations.

Here’s Toronto, with times over 300ms, still a reasonable experience:

But in Rio de Janeiro, we have now crossed the 500ms threshold, usually over 700ms.

The poor souls in Brazil won’t get a much better experience from either Supabase or Neon, two other SQL-based newcomers, either.

Supabase takes close to 3s to issue five end-to-end queries:

Neon is more than two times better than Supabase, but this query pattern still takes more than a second. Both Postgres-based offerings fare worse than Planetscale.

What are those graphs showing us?

Beyond the raw numbers, those graphs reveal something interesting: the light blue line that represents routing your requests directly to the US, is way faster! Sometimes by a factor of three.

The Edge is supposed to provide an architecture that abstracts location and just lets you automatically run your code close to your users, the moment databases enter the picture, the equation flips. Now it pays — and big — to be aware of where your database is and just route your requests there. Too bad for your global users.

Enter the Data Edge.

Turso is built differently. It is a full SQL database built for the Data Edge. It puts data replication front and center, with an architecture that makes it extremely affordable to run compute around the edge. Cheap enough that we can spread replicas in many locations (Our free tier offering already allows for 3 locations!) and make your queries fast wherever your users are.

Let’s look at my numbers again, from Toronto, this time using Turso, doing a single query:

This is much better. There’s barely any difference between going to the database’s “preferred” region and mine. But once more, we’ve grown used to good numbers in North America. So let’s once more see how my friend Athos is doing down in Brazil:

Athos now got the same ~10ms from Brazil that I got from Toronto. He can get his queries served, end-to-end, in less than 60ms. Even faster than I can! This means he’s physically closer to the closest point of presence than I am.

But there’s something more interesting lurking in the graph on the right: the light blue line is much higher. This means that forcibly going to the US is now much slower, as it should be. The whole round trip is now around 150ms, which is just around what physics dictates — a very similar number than what he got in the first example.

And for complex cases it shows even more

The difference is even more pronounced when he does 5 queries in a row. That is now under 130ms, a number more than 20 times better than Supabase, 10 times better than Neon, and 4 times better the ~250ms he got with the Planetscale example.

In summary: the purple line being lower than the light blue line means you can really code for the edge, move your data closer to your users, and make sure that the web is faster wherever your users are querying from.

As of today, Turso is available in 32 locations:

$ turso db locations
ID LOCATION
ams Amsterdam, Netherlands
arn Stockholm, Sweden
bog Bogotá, Colombia
bos Boston, Massachusetts (US)
cdg Paris, France
den Denver, Colorado (US)
dfw Dallas, Texas (US)
ewr Secaucus, NJ (US)
fra Frankfurt, Germany
gdl Guadalajara, Mexico
gig Rio de Janeiro, Brazil
gru São Paulo, Brazil
hkg Hong Kong, Hong Kong
iad Ashburn, Virginia (US)
jnb Johannesburg, South Africa
lax Los Angeles, California (US)
lhr London, United Kingdom
maa Chennai (Madras), India
mad Madrid, Spain
mia Miami, Florida (US)
nrt Tokyo, Japan
ord Chicago, Illinois (US)
otp Bucharest, Romania
qro Querétaro, Mexico
scl Santiago, Chile
sea Seattle, Washington (US)
sin Singapore, Singapore
sjc San Jose, California (US)
syd Sydney, Australia
waw Warsaw, Poland
yul Montreal, Canada
yyz Toronto, Canada

Give Turso a try. It’s free!

Turso is built for the Data Edge by the creators of libSQL, the popular open contribution fork of SQLite. Our service is free for every user, and includes replication at up to 3 locations. Start building with Turso today, and tell us your experience on our Discord channel!

#Vercel

Vercel benchmarks show Turso has low latencies everywhere: what the Data Edge is good for!