Turso, The Data Edge

So you probably have heard about the Edge thing everyone has been talking about in the front-end world. In case you haven't heard of it, the Edge is two things. The first one means placing compute closest to your user, and the second one is runtime, a distributed network of v8 engines that waits to execute your code and then throws it away. We will be looking at the first one in this article.

So, there are a lot of solutions right now that can help you bring the compute closer to your users, these include Vercel Edge Functions or Cloudflare Functions. But when it comes to Databases at the edge the problem becomes too hard to solve or once you crack the cheat code, it becomes very expensive to operate. This is mostly because of the co-location problem where it is way cheaper to make the round trip to the databases when it close to the server rather than when it is closer to the user.

We can check this out by comparing different databases using this Vercel tool. This tools lets you to choose different databases and lets you compare the latency of each on of them. But first, let's clarify a few words used on these graphs. The first one is Regional latency, which is the latency when the Edge functions are executed closer to the Database, and the second one is Global latency which is when the query is executed closest to the user. The latter takes into account the total round trip of the queries made.

Now lets choose Planetscale DB and make a query from Toronto Canada, which is pretty close to us-east1 where the database is hosted (according to the Vercel tool). I am not currently in Canada, so I took this screenshot from this original article.

Now I leave in Tanzania, East Africa so let's see how making the same query will affect me.

Well as you can see the amount of latency and the total time it takes to query the database on my end. My internet speed is roughly 17Mbps, which is quite fast enough and still I get that amount of latency. It is good to note here that is way “fast” to make the query using the Regional edge functions as compared to the Global one when I am querying it from Tanzania. Check the first graph, it doesn’t matter whether you make the query using the global or the regional edge functions, you get roughly the same result.

Now enter the Data Edge. I found this cool database called Turso, where the creators call it the Data Edge. It solves the problem of colocation by making replicas close to the user, and the replica always are in sync with one primary. This means that instead of manually configuring the database location and routing it there, you just let the query go to the nearest Database, which is closer to the user. Now we can check again how the latency behaves from the two places.

The first one is Querying the Data Edge from Toronto

And the second one is querying the Data Edge from Tanzania

As you can see that it’s way cheaper to query the database using the global edge functions than the regional one. And you don’t even need to manually set up the location for each route, you just let the request go to the nearest replica closest to the user and Turso will handle everything for you.

What’s happening here is that for the regional edge function, you go to us-east where the edge function runs. That edge function calls the Turso instance in the us-east, and you get the response back. For the global edge function, it runs to the nearest region (in my case Cape Town) and then calls the Turso instance in Johannesburg and I get the response back. You can check where the Vercel edge function routes you to by running this command on the terminal

curl -v 'https://edge-functions-add-header.vercel.app/_next/data/uZdXi2GsLkZMAjEssKNy0/index.json' 2>&1 | grep "x-vercel-id" | awk '{print $3}'

You will then get sth that looks similar to this,

cpt1:cpt1::sr2mg-1683660654794–15bb5b6f40c1

You only need to interpret the first few characters in this case, cp1 which is Cape Town. You can find the list of regions from this list below.

arn1 eu-north-1 Stockholm, Sweden bom1 ap-south-1 Mumbai, India bru1 eu-central-1 Brussels, Belgium cdg1 eu-west-3 Paris, France cle1 us-east-2 Cleveland, USA cpt1 af-south-1 Cape Town, South Africa dub1 eu-west-1 Dublin, Ireland fra1 eu-central-1 Frankfurt, Germany gru1 sa-east-1 São Paulo, Brazil hkg1 ap-east-1 Hong Kong hnd1 ap-northeast-1 Tokyo, Japan iad1 us-east-1 Washington, D.C., USA icn1 ap-northeast-2 Seoul, South Korea kix1 ap-northeast-3 Osaka, Japan lhr1 eu-west-2 London, United Kingdom pdx1 us-west-2 Portland, USA sfo1 us-west-1 San Francisco, USA sin1 ap-southeast-1 Singapore syd1 ap-southeast-2 Sydney, Australia.

Now if you are an average developer like me you might look at these numbers and say “just another few ms optimization” and probably you’re right, probably these optimizations mean nothing to you and your users can afford these delay and your business will still do just fine without any changes. But if you’re a dev who cares about perfomance who cares that your users have the best smooth experience they can possibly get then you might want to look into this database.

The application of this Data Edge (Turso DB) includes an E-commerce application where you want your products to load as fast as possible so that users are hooked up to your database and outperform the competition. It can include applications that a small data change needs to reflect as fast possible to the user, this includes an application that includes stock listings and financial information, Detection warning systems, and even IoT systems. These niche of applications will really benefits from this new Database infra and gets that smooth experience that has been missing on the other side of the web.

As of this writing, Turso includes replicas in 32 locations and I really hope that new locations will be added in the near future. You can check out the docs and play around it more.