Announcing ChiselStrike Turso

Today we are proud to announce Turso, an Edge database offering that finally brings the full expressive power and streamlined developer experience of SQLite close to your users to unlock globally fast query performance. Turso alleviates application bottlenecks at the Edge while giving control over the secure geographical placement and compliance of your data. And all of the above leverages our open contribution fork of SQLite, libSQL, to preserve data portability.

ChiselStrike Turso is available today as a private beta. If you want to join, visit our website and add your email to the list.

#Ok, the boss is gone.

I think the investors, the managers, and the executives are gone. Now I can talk to you, the developer, because Turso was made by people like you, for you. Let's rip off the buzzwords.

#What the hell is Turso? ELI5.

ChiselStrike Turso is a SQLite-compatible database that you can query over HTTP and easily replicate to many regions around the world. Writes can happen from any replica location, but they are routed transparently to the primary. That does mean that writes will not be available should connectivity to the primary be lost, but reads are available from all replicas even if the primary is unreachable. While in that case you may read old data, you will not read inconsistent data (snapshot isolation at the transaction boundary).

Turso is based on sqld, the “server mode” of our fork of SQLite called libSQL, which is Open Source and Open Contribution. You can build and deploy it on your own, or you can use our hosted solution.

The product handles all the infrastructure, including replication and encryption, and eventually a bunch of stuff that your boss — the one who stopped after the first paragraph of the announcement — will likely require. Because that stuff is boring as hell, we'll make sure we package it all in a neat service.

#What difference does an embedded database make?

Embedded databases — such as SQLite — are easy to configure, easy to get started, and easy to use. Unit and integration tests are a breeze, because you don't have to connect to services, spawn docker containers, or anything like that. This code, for example, allows an environment variable to easily switch between sqld running remotely, or a local file using our TypeScript client library:

import { connect } from '@libsql/client';
async function example(): Promise<void> {
  const config = {
    url: process.env.DB_URI ?? 'file:foo.db',
  };

  const db = connect(config);
  const rs = await db.execute('SELECT * FROM projects');
  console.log(rs.results);
}
example();

You can provide a file with mock data for your integration tests, make sure your pipelines are sane, and work with data in a staged deployment.

That's great, but because production databases in real life are not like that (or were not like that), this sort of code rarely survives the prototyping phase. But with ChiselStrike Turso, you can add local SQLite-compatible files to your CI pipelines, make it green, and take it to production with a single environment variable flip.

Embedded databases can be used almost anywhere, with the same interface, so you can really push your data everywhere — even to the edge.

#What does an Edge database even mean?

Edge is a buzzword. Cutting through the hype, putting a database “on the edge” means two things for us:

#1. Awareness of how modern applications use the edge.

Edge functions are expected to run quickly with low latency for nearby end users. However, when the code is connected to a traditional centralized database, the benefits of edge computing are lost in the overhead of that network connection. To minimize the problem of latency and slow global networks, edge computing is best paired with an edge database.

Turso is designed to allow you to write your client code in two ways:

• Over HTTP: It's available everywhere. It's fast, reliable, and your entire stack already supports it.
• Using the SQLite API: You can run exactly the same code on a local database or a remote one, including using ORMs like Prisma. We'll auto-proxy the queries to the closest replica.

#2. Putting your data as close as possible to your application code.

Here's how you would use the Turso CLI to create a database with replicates in Denver and Frankfurt:

turso auth login
turso db create demo # create a database
turso db replicate demo den # replicate it in Denver.
turso db replicate demo fra # replicate it in Frankfurt

Writes are proxied to the primary automatically, so your application can write from everywhere to everywhere you have a replica.

#What's with the name “Turso”?

Turso is named after Iku-Turso, a Finnish beer brand that is itself named after a Finnish mythological creature. My cofounder is Finnish and used that as a codename. Everybody dug it, and because I had good luck prior in my career with mythological creatures, it felt cozy and homecoming. So it stuck.

#What's next?

We hope to deliver more features during the private beta. Some features are already available in the sqld repo, and some are still being developed. But in particular:

• Postgres protocol support: You will be able to query sqld using your favorite postgres tools.
• Local replicas: ChiselStrike Turso already makes replication to 20+ regions a breeze. But what if you could transparently replicate it inside your infrastructure? For long-running code, you will be able to avoid the network round trip entirely by hosting a copy of your data locally.
• Data placement controls: With declarative statements, you will have the ability to ensure that certain data must only exist in certain geographical regions, despite database replication configured elsewhere.

If you like what we have to offer, ChiselStrike Turso is now in private beta. You can sign up for early access and join our Discord channel to chat about it. And as a reminder, this is all built on open source technology, so you're welcome to check out our GitHub, and build with it!

And if you want to see it in action right now, watch this video: