Writing Low Latency Database Applications Even If Your Code Sucks

All latency lovers are used to the mystical experience of joy coming from aligning data to a cache line size and seeing your latency improve by hundreds of microseconds. But as transcendent as we can become, the laws of physics still apply to us.

That means that there is little we can do when data has to be fetched from across the planet. By putting data close to its users, you can save hundreds of milliseconds and still be faster than the most optimized code, even if your code sucks.

Massive data replication comes with challenges, though: how to keep the costs in check? How to make sure that a semblance of consistency is maintained? What about those pesky regulations that mandate data residency?

In this talk I will explore the Data Edge: a growing movement of databases that are overcoming those challenges to make your data always available where your users are.

1. Writing Low Latency Database Applications Even if your code sucks! Glauber Costa CEO at Turso

2. Glauber Costa CEO at Turso COMPANY LOGO Former VP Field Engineering at ScyllaDB Former contributor to the Linux Kernel Latency aficionado When I am not working, I take care of my 3 kids

3. Your application and your database How latency is commonly measured

4. Zoom out Is that the end-to-end latency?

5. Zoom out Is that the end-to-end latency? What do you mean “there are other countries” ???

6. Impact P99 goes from 10ms to 1ms. That’s 10x better. Roundtrip NYC to Sydney: ~250ms

7. Impact P99 goes from 10ms to 1ms: That’s 10x better. Roundtrip NYC to Sydney: ~250ms. Barbie not impressed. I don’t care about your 10ms savings, mate!

8. Solution 1 Write good code, but move your data closer to Sydney

9. Solution 2 Put your data everywhere. Just do whatever you want and save yourself 200ms.

10. Some estimates (approx) NYC to: Sydney 250ms Sao Paulo 150ms San Francisco 70ms Amsterdam 70ms Tokyo 180ms https://wondernetwork.com/pings/New%20York

11. The Edge Global coverage. Geographical Abstraction. Serverless: Cloudflare Workers, Vercel Edge, Netlify Edge, etc. Or VMs: Fly.io, Koyeb, etc.

12. The Edge Still bad!!

13. How? For per-user data: partitioning . Unfortunately for global data, there’s only one way: replication . But the problem with replication is: cost .

14. Reframing the problem How to build the cheapest possible database, so that it can replicate to a lot of locations? What is a lot? 30, not 3. Seasonality of traffic. Cost of a GB: ~$0.10/month Cost of a CPU (with reasonable memory): ~$20/month

15. What is the cheapest SQL database ? Hey, can we change SQLite to add the building blocks of replication? No. Ok… (disappointed face)

16. What is the cheapest SQL database ? l ibsql: fork of SQLite. Everybody welcome. Major changes: write-ahead-log virtualization hooks. server-mode

17. What is the cheapest SQL database ? Built on libsql for massive replication. Serverless or Embedded. Primary writes, replicated reads. Scale-to-zero. 1 command replication, single URL routing. Multitenancy.

18. What does it look like? Vercel’s Edge benchmark 5 waterfall queries from edge compute locations. Client in Brazil. Postgres Purple : latency from the client’s preferred location Blue: latency from the DB’s preferred location

19. What does it look like?

20. Summary Moving data close to users can eclipse lots of optimization work. Partition and replication are really the only way to do it. To make replication viable, it needs to be: Cheap, easy to set up, and easy to use.

21. Glauber Costa [email protected] @glcst https://turso.tech Thank you! Let’s connect.