Exploring Turso: The Managed Fork of SQLite

4min Snip

00:00

Play full episode

Summary

Transcript

Episode notes

This chapter examines the origins and functionality of Turso, a managed version of SQLite, along with the motivations for forking SQLite into libSQL. It highlights the team's expertise, the target users, and features such as Vector Search that enhance server-side database performance.

Scott and Wes chat with Glauber Costa from Turso about the evolution of databases and the fascinating technology behind Turso. They dive into topics like the benefits of massive multi-tenancy, vector search, and why Glauber made the switch from NoSQL to relational databases.

Show Notes

00:00 Welcome to Syntax!
00:36 Turso’s relationship with Drizzle.
02:10 What is Turso?
04:23 Brought to you by Sentry.io.
04:48 Using libSQL without Turso.
06:21 An explanation of Vector Search.
07:16 Vector databases are being ‘Sherlocked’ by larger databases.
09:24 Why did you move from NoSQL to Relational?
12:00 Allows for massive multi-tenancy - what does that mean?
15:27 Transactional schema changes.
16:30 Why would you want 10,000 databases?
19:02 What makes SQLite cheaper?
22:59 The strategy for building a business around an inexpensive tool.
26:13 Pull requests and branching within SQLite.
28:52 Database snapshots for rollbacks.
31:14 Driving the cost of a database to zero allows for rethinking architecture.
32:35 SQLite informing Turso’s edge functionality.
36:56 Automatic replica database syncing.
39:10 Is the database a bottleneck?
39:25 Embedded Replicas.
40:04 How do embedded replicas handle conflict resolution from offline users?
41:43 If the server is offline, can the database live in the client or WASM?
43:09 Conflict resolution.
44:47 What makes Turso stand out?
47:51 What was it like working on the Linux Kernel?
51:57 Do you use Linux?
52:46 Sick Picks & Shameless Plugs.