What Is Turso? The Edge Database for AI-Built Apps

You Asked AI to Deploy Your App — and It Said "Turso"

Here is a scenario that happens every day. You have been building an app with Claude or Cursor. It works locally. You are ready to deploy. You type something like:

Deploy this Next.js app to Vercel with a database.
I need to store users and their projects.
What database should I use?

And the AI comes back with: "I recommend Turso for this — it is an edge database that will be fast for users everywhere, and it has a generous free tier."

You stare at the screen. You have heard of PostgreSQL. You have maybe used Supabase. But Turso? Is that even a real thing?

It is. And the AI picked it for a good reason. Let me explain what it is and why it matters — in plain English.

What Turso Actually Is

Turso is a database service that takes SQLite — the simplest, most widely-used database in the world — and makes it work across the internet.

Here is the core idea in one sentence: Turso copies your database to servers around the world so that your users always read data from a server that is physically close to them.

That is what "edge database" means. "Edge" is not a brand name or a fancy technology — it just means "close to the user." If someone in Tokyo opens your app, they read data from a server in Tokyo. Someone in London reads from London. Someone in Virginia reads from Virginia.

Traditional databases like PostgreSQL run in one location. If your PostgreSQL database is in Virginia, every user in the world connects to Virginia. A user in Tokyo waits for data to travel halfway around the world and back. That round-trip adds 100–200 milliseconds of latency on every single database query.

Turso eliminates that problem. Your data lives in one primary location (where writes happen), but read copies — called replicas — are spread across multiple regions. Reads are local. Fast. Practically instant.

The SQLite Connection — Why This Matters to You

If you have built anything with AI, you have probably already used SQLite without knowing it. SQLite is the default database that ships with Python, comes embedded in every iPhone and Android device, and is often the first database AI tools reach for when prototyping.

The important thing: Turso uses libSQL, which is an open-source fork of SQLite.

What does "fork" mean in this context? It means the Turso team took the SQLite source code and added features that SQLite's creator chose not to include — specifically, the ability to access the database over a network, replicate it to multiple locations, and support multiple users at the same time.

For you, this means:

• Same SQL syntax. If you (or your AI) know how to write SQLite queries, those same queries work with Turso. No new language to learn.
• Same data types. TEXT, INTEGER, REAL, BLOB — the SQLite basics carry over.
• Familiar tools. You can export a Turso database as a regular SQLite file, open it in any SQLite viewer, and inspect your data directly.
• Easy migration path. If you started with a local SQLite file during development, moving to Turso for production is straightforward — the schema stays the same.

Think of it this way: SQLite is a great tool for one person working on one machine. Turso takes that same tool and makes it work for thousands of users across the globe.

Why Turso Exists — the Problem It Solves

To understand why Turso exists, you need to understand the problem with traditional database setups for modern web apps.

Here is the old model:

1. Your app runs on a server (or serverless function) somewhere — say, AWS us-east-1 in Virginia.
2. Your database (PostgreSQL, MySQL) runs in the same region.
3. Every user in the world connects to that one location.

This works fine if most of your users are in the eastern United States. It works poorly if your users are in Europe, Asia, or Australia. Every database query adds that cross-continent latency.

Now, modern platforms like Vercel and Cloudflare Workers run your code at the edge — meaning your server-side code executes in whichever data center is closest to the user. A user in Tokyo runs your function in Tokyo. A user in London runs it in London.

But here is the mismatch: your code runs at the edge, but your database is still in Virginia. Your Tokyo user hits a function in Tokyo, which then calls a database in Virginia. You have optimized half the journey and left the other half slow.

Turso fixes this mismatch. It puts your data at the edge too. Your Tokyo function talks to a Turso replica in Tokyo. Your London function talks to London. The data is already there.

When AI Picks Turso (and When It Shouldn't)

AI coding tools are not randomly picking Turso. There are specific scenarios where it is the right call:

Turso is a great fit when:

• You are deploying to an edge platform — Vercel Edge Functions, Cloudflare Workers, Deno Deploy, or Netlify Edge. These platforms run code worldwide, and Turso is designed to match that distribution.
• Your app is read-heavy. Most apps read far more data than they write. A blog, a dashboard, a product catalog — the majority of operations are reads. Turso excels at this because every replica can serve reads independently.
• You want a simple, SQLite-based setup. If your data model is straightforward and you do not need the advanced features of PostgreSQL (like JSONB queries, full-text search, or stored procedures), Turso's SQLite foundation is simpler to work with.
• You are building a mobile app or desktop app. Turso supports embedded replicas — a local SQLite copy that syncs with the cloud. Your app works offline and catches up when connectivity returns.
• You want a generous free tier. 9 GB of storage, 500 databases, 24 billion row reads per month. For a personal project or early startup, you probably will not hit those limits for a long time.

Turso is NOT the right fit when:

• Your app is write-heavy. All writes go to one primary location. If you are processing thousands of writes per second — think real-time analytics, high-frequency trading, or social media feeds — a single write endpoint becomes a bottleneck.
• You need advanced PostgreSQL features. Full-text search, JSONB operators, materialized views, PostGIS for geospatial data, stored procedures — Turso does not have these. If your AI generated PostgreSQL-specific code, switching to Turso means rewriting those parts.
• You need a full backend platform. Turso is just a database. It does not include authentication, file storage, or real-time subscriptions like Supabase does. You will need separate services for those.
• You need strict consistency on reads. Replicas have a slight delay (typically under 100ms) before they reflect the latest write. For most apps this is invisible, but if you absolutely need every read to return the latest data, you should direct those reads to the primary.

How Turso Works in Your Code

When AI sets up Turso for you, the code is surprisingly simple. Here is what it looks like:

// Install the client
// npm install @libsql/client

// lib/turso.ts — connecting to Turso
import { createClient } from '@libsql/client';

export const turso = createClient({
  url: process.env.TURSO_DATABASE_URL!,
  authToken: process.env.TURSO_AUTH_TOKEN!,
});

// Create a table
await turso.execute(`
  CREATE TABLE IF NOT EXISTS projects (
    id INTEGER PRIMARY KEY AUTOINCREMENT,
    name TEXT NOT NULL,
    user_id TEXT NOT NULL,
    created_at TEXT DEFAULT (datetime('now'))
  )
`);

// Insert a row
await turso.execute({
  sql: 'INSERT INTO projects (name, user_id) VALUES (?, ?)',
  args: ['My Cool App', 'user_123'],
});

// Query rows
const result = await turso.execute({
  sql: 'SELECT * FROM projects WHERE user_id = ?',
  args: ['user_123'],
});

console.log(result.rows);
// [{ id: 1, name: 'My Cool App', user_id: 'user_123', created_at: '2026-03-19 12:00:00' }]

Notice the key differences from other database clients:

• The package is @libsql/client, not a Turso-branded package. This is because Turso is built on libSQL — the open-source fork of SQLite.
• You need two environment variables: a database URL and an auth token. The URL points to your Turso database, and the token authenticates your app.
• Queries use SQLite syntax. AUTOINCREMENT instead of PostgreSQL's SERIAL. datetime('now') instead of now(). ? for parameter placeholders instead of $1.
• Parameterized queries use args arrays. The ? placeholders get filled in order from the args array. This keeps your queries safe from SQL injection.

How Turso Works with Drizzle ORM

If you have been building with AI, there is a good chance it set up Drizzle ORM alongside Turso. Drizzle is a TypeScript ORM that generates type-safe database queries, and it has first-class support for Turso.

Here is what that pairing looks like:

// drizzle/schema.ts — define your tables in TypeScript
import { sqliteTable, text, integer } from 'drizzle-orm/sqlite-core';

export const projects = sqliteTable('projects', {
  id: integer('id').primaryKey({ autoIncrement: true }),
  name: text('name').notNull(),
  userId: text('user_id').notNull(),
  createdAt: text('created_at').default("(datetime('now'))"),
});

// lib/db.ts — connect Drizzle to Turso
import { drizzle } from 'drizzle-orm/libsql';
import { createClient } from '@libsql/client';
import * as schema from './drizzle/schema';

const tursoClient = createClient({
  url: process.env.TURSO_DATABASE_URL!,
  authToken: process.env.TURSO_AUTH_TOKEN!,
});

export const db = drizzle(tursoClient, { schema });

// Use type-safe queries
import { eq } from 'drizzle-orm';
import { projects } from './drizzle/schema';

// Insert
await db.insert(projects).values({
  name: 'My Cool App',
  userId: 'user_123',
});

// Select with type safety
const userProjects = await db
  .select()
  .from(projects)
  .where(eq(projects.userId, 'user_123'));

// userProjects is fully typed — your editor knows the shape

The Drizzle + Turso combination is popular because:

• Type safety. Your editor autocompletes column names and catches type errors before your code runs.
• Schema as code. Your database schema lives in TypeScript files alongside your app code. AI can read and modify both together.
• Migrations. Drizzle generates SQL migration files when your schema changes, so you can track database changes over time.

Turso vs. Other Database Options

When AI recommends Turso, it is choosing from a field of options. Here is how they compare for a vibe coder:

Turso vs. Supabase

Bottom line: Supabase gives you a complete backend. Turso gives you a faster, globally distributed database. If you need auth, storage, and real-time features out of the box, Supabase is easier. If you need global edge performance and are handling auth separately, Turso wins on speed.

Turso vs. PlanetScale

Bottom line: PlanetScale is a powerful MySQL-based platform, but it removed its free tier in 2024. For vibe coders just starting out, Turso's generous free tier and simpler SQLite model make it far more accessible.

Turso vs. Plain SQLite

Bottom line: Plain SQLite is perfect for prototyping and local development. When you need to go to production with real users, Turso takes the same SQLite foundation and makes it production-ready — accessible over the network, replicated, and backed up.

Free Tier and Pricing

Turso's free tier is one of the most generous in the database space:

• 9 GB total storage — across all your databases combined
• 500 databases — yes, five hundred. Useful for per-tenant architectures where each user gets their own database.
• 24 billion row reads per month — you will almost certainly never hit this
• 25 million row writes per month — sufficient for most apps below enterprise scale
• 3 locations — your primary plus two replicas

For context, the free tier can comfortably handle a SaaS app with thousands of users. You will not need to think about pricing until you are well past the "is this thing working?" phase.

Paid plans start at $29/month (Scaler) for higher storage, more locations, and increased write limits. Enterprise plans add dedicated support and custom SLAs.

Getting Started — What AI Usually Generates

Here is the typical setup flow when AI scaffolds a Turso project. Understanding each step helps you verify AI got it right:

# 1. Install the Turso CLI
brew install tursodatabase/tap/turso    # macOS
# or: curl -sSfL https://get.tur.so/install.sh | bash

# 2. Sign up / log in
turso auth signup    # creates account
turso auth login     # if you already have one

# 3. Create a database
turso db create my-app-db

# 4. Get your connection credentials
turso db show my-app-db --url         # your TURSO_DATABASE_URL
turso db tokens create my-app-db      # your TURSO_AUTH_TOKEN

# 5. Add those to your .env file
# TURSO_DATABASE_URL=libsql://my-app-db-yourname.turso.io
# TURSO_AUTH_TOKEN=eyJhbG...

That is it. Five commands and you have a globally distributed database ready to accept connections. Compare that to setting up PostgreSQL on a VPS — installing the server, configuring users, setting up SSL, managing backups, handling connection pooling — and you can see why AI reaches for Turso when deploying to the edge.

The Hidden Superpower: Embedded Replicas

One of Turso's most interesting features — and one AI rarely mentions — is embedded replicas. This means your app can keep a local SQLite copy of the database that syncs with the cloud.

// Using an embedded replica
import { createClient } from '@libsql/client';

const db = createClient({
  url: 'file:local-replica.db',          // local SQLite file
  syncUrl: process.env.TURSO_DATABASE_URL!, // remote Turso database
  authToken: process.env.TURSO_AUTH_TOKEN!,
  syncInterval: 60,                        // sync every 60 seconds
});

With this setup, reads happen against the local file — no network request at all. The client periodically syncs with the remote Turso database to stay current. This is especially powerful for:

• Server-side rendering — zero-latency database reads for SSR pages
• Mobile and desktop apps — works offline, syncs when connected
• Cost reduction — local reads do not count against your row-read limits

What AI Gets Wrong About Turso

Using Turso for write-heavy applications

AI sometimes recommends Turso for every project, including ones with heavy write workloads. All writes go to the primary database location. If your app processes thousands of writes per second — real-time chat, live analytics, high-frequency updates — the single write endpoint becomes a bottleneck. For write-heavy apps, PostgreSQL with connection pooling (or Supabase) is usually a better fit.

Not understanding eventual consistency

When you write data to Turso, the primary location updates immediately. But replicas take a moment — typically under 100 milliseconds — to receive the update. AI often writes code that creates a record and then immediately reads it from a replica, which might not have the new data yet.

The fix: for reads that must reflect the latest writes, direct those specific queries to the primary location. Turso supports this through the consistency: 'strong' option or by connecting directly to the primary URL.

Missing the @libsql/client driver

AI sometimes generates code using better-sqlite3 or the generic sqlite3 package to connect to Turso. These will not work — they are for local SQLite files only. Turso requires the @libsql/client package, which handles the network protocol, authentication, and replication.

If you see this error: "Cannot connect to libsql:// URL" — check that your code imports from @libsql/client, not another SQLite package.

Generating PostgreSQL syntax

When AI knows you are using an edge database, it sometimes still generates PostgreSQL-specific SQL: SERIAL instead of INTEGER PRIMARY KEY AUTOINCREMENT, $1 placeholders instead of ?, now() instead of datetime('now'). Always verify the SQL syntax matches SQLite conventions when using Turso.

What to Learn Next

• What Is a Database? — Start here if databases are brand new to you.
• What Is SQL? — Turso uses SQLite syntax. Understanding SQL basics makes everything click.
• What Is PostgreSQL? — The traditional alternative AI might suggest instead of Turso.
• What Is Serverless? — Edge databases like Turso pair with serverless platforms. Understand why.
• What Is Drizzle ORM? — The most common ORM paired with Turso in AI-generated code.
• What Is Supabase? — The full-platform alternative when you need auth and storage too.

FAQ