Your global web application lags for users in other regions? A single datacenter database adds unnecessary latency. We solve this with Turso — distributed SQLite on Edge. In this article, we explain how to set up Turso with Drizzle ORM and embedded replicas for 0 ms read latency in Cloudflare Workers. Our engineers have 10+ years of experience in distributed systems and have delivered 15+ Turso projects, reducing average latency by 3x. Compared to regular SQLite, Turso cuts global latency by over 10x. Start with a free audit of your project — contact us.
Problems We Solve
Global latency. Users from South America or Asia wait 200–400 ms for a request to reach a European server. Turso places replicas in 20+ regions, executing the request on the nearest node. Write contention. In write-heavy scenarios, SQLite locks the entire database during writes. Turso solves this via replication: writes only to the primary, reads from any replica. Multi-region without pain. No need to set up a PostgreSQL cluster or worry about sync. Turso manages replication automatically, and the embedded replica gives zero-latency reads at runtime. Turso also supports the database-per-tenant model, simplifying data isolation for multi-tenant applications.
How Turso Works
Turso uses a primary + replicas model:
- Primary — accepts all writes.
- Replicas — read-only copies on the edge (e.g., Frankfurt, Singapore, São Paulo).
- Embedded Replica — local SQLite copy in the memory of a Cloudflare Worker or Node.js process.
For read-heavy applications, an embedded replica reduces read latency to zero — the request never leaves the runtime. On one project (a corporate blog with 100k unique monthly visitors), we achieved SSR response times under 50 ms at the 99th percentile.
Setting up Turso can save up to 70% on infrastructure costs for read-heavy applications compared to traditional solutions.
| Feature | Turso | Traditional SQLite | PostgreSQL (single server) |
|---|---|---|---|
| Read latency (global) | <10 ms | N/A (local) | 50–300 ms (region-dependent) |
| Write throughput | ~1k ops/s (single primary) | ~10k ops/s (local) | ~10k+ ops/s (with sharding) |
| Multi-region | Built-in | No | Requires configuration |
| Embedded replica | Yes | No | No |
| Cost (10 GB) | Low | Free | Medium |
How We Set Up Turso Turnkey
We complete the setup in 2 days. Here are the main steps:
- Audit schema and load — determine if the read-heavy scenario fits.
- Create primary and replicas — choose regions via CLI.
- Integrate with Drizzle ORM — typed queries, migrations.
- Configure embedded replica — for Cloudflare Workers or Node.js.
- CI/CD migrations — automatic schema application on deploy.
Example CLI and code
# CLI to create database and replicas turso auth login turso db create myapp --location ams turso db replicate myapp --location sin turso db replicate myapp --location gru turso db show myapp --url turso db tokens create myapp // libSQL client with embedded replica import { createClient } from '@libsql/client'; const db = createClient({ url: process.env.TURSO_DATABASE_URL!, authToken: process.env.TURSO_AUTH_TOKEN!, syncUrl: process.env.TURSO_DATABASE_URL!, syncInterval: 60, }); await db.sync(); const posts = await db.execute('SELECT id, title FROM articles'); How Drizzle ORM Integrates with Turso
We connect Drizzle for typed queries:
// db/schema.ts import { sqliteTable, text, integer } from 'drizzle-orm/sqlite-core'; export const articles = sqliteTable('articles', { id: integer('id').primaryKey({ autoIncrement: true }), title: text('title').notNull(), slug: text('slug').notNull().unique(), body: text('body'), publishedAt: integer('published_at', { mode: 'timestamp' }), }); // db/client.ts import { drizzle } from 'drizzle-orm/libsql'; import { createClient } from '@libsql/client'; const client = createClient({ url: process.env.TURSO_DATABASE_URL!, authToken: process.env.TURSO_AUTH_TOKEN!, }); export const db = drizzle(client); const posts = await db.select().from(articles) .where(isNotNull(articles.publishedAt)) .orderBy(desc(articles.publishedAt)) .limit(10); Why Choose Embedded Replica?
Embedded replica gives zero latency on reads — the query runs directly in the runtime, with no network calls. This is critical for SSR on Cloudflare Workers: a page renders in 10–20 ms instead of 100+. We ensure the embedded replica synchronizes with the primary at least once per minute. For most read-heavy applications, this is acceptable.
Timeline and Milestones
| Stage | Duration | Result |
|---|---|---|
| Audit and design | 4 hours | Architecture plan, region selection |
| Turso and replica setup | 2 hours | Working database with replicas |
| Drizzle integration | 4 hours | Typed access, first queries |
| Embedded replica for Workers | 3 hours | Zero-latency reads |
| CI/CD migrations | 2 hours | Automatic migrations on deploy |
What's Included
- Audit of current schema and load.
- Creation of primary and replicas in required regions.
- Integration with Drizzle ORM (or another ORM of choice).
- Configuration of embedded replica for Cloudflare Workers or Node.js.
- CI/CD migration scripts.
- Architecture and access documentation.
- Team training (1 hour online).
- 2-week support guarantee after delivery.
Turso Limitations: When to Choose Another Solution
- Write-heavy workload (>20% writes). All writes go to the primary, creating a bottleneck.
- Complex analytical queries — SQLite does not replace ClickHouse or Timescale.
- PostgreSQL requirements — RLS, advanced types, PostGIS.
- High write concurrency — SQLite ACID locks.
Order Turnkey Turso Setup
We'll assess your project for free: send us a load description and schema — we'll pick the optimal Turso configuration. Turnkey setup in 2 days. Call or write — we'll discuss the details. Get a consultation on your project today.