Many database services are out there to solve your problems. However, you might be overwhelmed with all the options available(Was it only me?🥲). I found a database benchmark tool that Vercel built. This may help you make your database decisions. In this post, I'll go over the basic terminologies, my benchmark results, and some insights. Hopefully, it'll be able to give you a general idea about performance.
Terminologies
Let's sort out all the terms we need to understand before moving on to the main point.
CDN(Content Delivery Network)
CDN caches static contents such as HTML, CSS, and media files distributed to servers around users so that users can receive the contents faster.
Edge Computing
Instead of running a distant server, you place multiple servers near the users to run computations. It reduces long-distance client-server communications.
Edge Database
We just said edge computing came out to reduce client-server communications. It will lose its main purpose if the database is far from the edge servers since most edge computations require database access. You can put data and computing around users altogether. That's where people came up with the idea of an edge database.
Distributed SQLite
- SQLite is fast so the server can read and write SQLite quickly.
- Vendors like Cloudflare D1, Turso, and fly.io offer distributed SQLite.
- Since they can be distributed, they align with edge databases and can be placed next to edge functions for fast access times.
- Turso stores the replicas of all databases in multiple regions by default.
What's the point of Edge Database?
- Turso's Selling point
You can consider edge databases when you want your users to get consistent latency wherever they are. This is more beneficial when your application needs to serve multiple regions(or countries). I'm planning to build travel apps and that's how I got more interested in Edge Database. The following is the real-life scenario I could think of.
Let's say you're American and traveling to Europe at the moment. When you open a mobile app, it loads slowly since your data should be in America. To solve this, the application can store your data around your current location(Europe) now and data access time will be reduced.
Note that using SQLite as a distributed database is not a matured technology and many people are still discussing(arguing)..
Benchmarks
I'll use a database benchmark tool a database benchmark tool to see how well each database provider performs. Note that I'm testing this in South Korea, so I'm far away from the original database enough to test the performance(US East). I set the test options in the following manner.
- Location option: Global function (Edge), Regional function(Edge / US East), and Serverless function (Node / US East)
- Waterfall: 5 sequential queries
- The number of samples for each location: 50
⚠️ Testing 50 requests might not be enough, but at least it gives you a general idea of the performance. Plus I set the Waterfall option to '5 sequential queries' to ensure real-life querying scenarios because each query usually depends on the result of the preceding queries(data dependency).
Supabase with Drizzle ORM
Latency distribution(processing time)
Latency distribution(end-to-end)
Supabase only runs on node, not on edge.
Its processing time is ~30ms, and end-to-end access time is ~250ms. The end-to-end access time increases since the database lives in US East region.
Neon with Drizzle ORM
- Latency distribution(processing time)
- Latency distribution(end-to-end)
- Global edge takes an extremely longer time than regional edge/node.
PlanetScale with Drizzle ORM
Latency distribution(processing time)
Latency distribution(end-to-end)
Global edge takes an extremely longer time than regional edge/node.
Upstash with Drizzle ORM
Latency distribution(processing time)
Latency distribution(end-to-end)
Global edge still takes longer time than regional edge/node
Turso with Drizzle ORM
Latency distribution(processing time)
Latency distribution(end-to-end)
Global edge still takes about the same time as edge/node.
Test Results in Korea
- Actually, there was no point in using edge databases in Korea.
- Apparently, it's better to access data on the origin server.
Since this result is significantly different from Turso's test result, I asked my friend in France to run Upstage and Turso tests there. Here's what she sent me.
Turso with Drizzle ORM in France
Latency distribution(processing time)
Latency distribution(end-to-end)
The real-life latency of the global edge is about 2 times lower than the others.
Upstash with Drizzle ORM in France
Latency distribution(processing time)
Latency distribution(end-to-end)
The real-life latency of the global edge is about the same as the others.
Conclusion
- Turso's edge database approach didn't work in South Korea. The rest of them either.
- Turso worked significantly better in France and Brazil.
- I assume this difference came from the fact that the closest edge location to Korea is Japan, while the other two countries have their own edge locations.
- Database Services other than Turso didn't work with Global Edge. While this means default Turso replicas outperform the others, PlanetScale can improve performance if you set up replicas in other 15 regions(enterprise plan).. Supabase supports 12 cross-regional read replicas configuration. Unfortunately, Neon only supports read replicas in the same region.
Top comments (0)