Skip to content
Back to Deployment

Deploying with Turso

Edge SQLite with libSQL, multi-region replication, and per-user databases.

PlatformsIntermediate

Why

Turso runs SQLite at the edge with libSQL (SQLite fork with replication). Each user can have their own DB, and reads are served from the nearest region with sub-10ms latency.

Platform-as-a-Service adoption grew 24% in 2024 as teams shift from VM management to git-push deploys. the cloud infrastructure market reached $330B in 2024, growing 22% year-over-year (Synergy Research), and PaaS layers capture the majority of new workloads.

When

Use Turso for edge apps, multi-tenant SaaS (DB per user), and read-heavy workloads. Avoid for write-heavy or complex joins across DBs.

How

1. Create — turso db create mydb 2. Replicate — turso db replicate mydb <region> (multi-region) 3. Connect — libSQL client or sqlite3 with extension 4. Schema — turso db shell mydb < schema.sql 5. Per-user — create DB per tenant, manage with turso db list 6. Token — turso db tokens create mydb for auth 7. SDK — @libsql/client for JS/TS

Example

import { createClient } from "@libsql/client"; const client = createClient({ url: process.env.TURSO_DATABASE_URL!, authToken: process.env.TURSO_AUTH_TOKEN!, }); const result = await client.execute("SELECT * FROM users WHERE id = ?", [1]); # CLI turso db create mydb --location nrt # Tokyo turso db replicate mydb sfo # San Francisco turso db tokens create mydb # auth token

Common Problems

  • ⚠Writes go to primary only — write latency depends on primary region distance
  • ⚠Too many DBs — free tier limits, use groups for multi-tenant
  • ⚠Configuration drift between environments — use infrastructure-as-code (Terraform/Pulumi) to keep dev/staging/prod identical

Best Practices

  • ✓Replicate to user-heavy regions — reads served locally, writes async to primary
  • ✓Use turso db groups for multi-tenant — manage many DBs as one
  • ✓Set up health checks and graceful shutdown — handle SIGTERM to drain in-flight requests before exit

FAQ