Turso (SQLite Edge) Setup for Web Apps: Zero-Latency Reads with Embedded Replicas

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.

How We Set Up Turso Turnkey

We complete the setup in 2 days. Here are the main steps:

1. Audit schema and load — determine if the read-heavy scenario fits.
2. Create primary and replicas — choose regions via CLI.
3. Integrate with Drizzle ORM — typed queries, migrations.
4. Configure embedded replica — for Cloudflare Workers or Node.js.
5. CI/CD migrations — automatic schema application on deploy.

# 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

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.

Why Serverless Development? The Real Economics and Technical Trade-offs

Serverless does not mean "without servers". Servers exist—you just don't manage them. It's more accurate to think of it as "without server management": no OS patching, no nginx configuration, no disk space monitoring. The function receives an event, processes it, and returns a response. The provider decides where to run it. Мы занимаемся serverless-архитектурой более 5 лет и реализовали 30+ проектов на AWS Lambda, Vercel Functions и Cloudflare Workers. Гарантируем, что ваша система масштабируется без переплат — при условии правильного выбора платформы и оптимизации холодного старта.

Cold start — Lambda's main pain point on Node.js. In VPC, cold start reached 10 seconds before recent improvements. For production functions with latency requirements: Provisioned Concurrency (keeps instances warm), SnapStart for Java, minimize bundle via tree-shaking. Our typical optimization reduces cold start from 3.2s to 400ms.

Practical case: an image processing function (resize, WebP conversion, upload to S3). Bundle with sharp was 40MB due to native binaries. Solution: Lambda Layer with sharp, main function 800KB. Cold start dropped from 3.2s to 400ms. Lambda Layers — shared dependencies between functions. Up to 5 layers per function, each up to 250MB. Standard practice: layer with heavy dependencies (sharp, puppeteer, ffmpeg), layer with common business logic. Infrastructure for Lambda via AWS CDK or Terraform. SAM — for beginners, CDK — for serious projects with type safety.

Edge Runtime is fundamentally different: the function runs on a V8 isolate in the nearest Vercel CDN point (120+ regions). No cold start as such — the isolate starts in ~0ms. But strict limitations: no Node.js API (fs, crypto via Web API), no database access via TCP (only via HTTP API), bundle size up to 4MB. Edge Runtime is ideal for: middleware (auth check, redirect, A/B test), response transformations, geolocation logic, Edge Config. Not suitable for: accessing PostgreSQL, heavy computations, file system operations.

Cloudflare Workers run on V8 isolates in 300+ points of presence. Latency for the user is literally the nearest data center. Cold start < 1ms. Workers Durable Objects solve the state problem at the edge: each Durable Object is a single coordination point, running in one region. Ideal for: game rooms, real-time documents, rate limiting without races. Workers KV — eventually consistent storage. Writes propagate to all regions in ~60 seconds. Not suitable for financial transactions, suitable for configs, feature flags, cache. D1 — SQLite on the edge. Works great on a single read replica, write latency depends on distance to primary region. Not ideal for global write-heavy applications.

Ecosystem: Hono.js — a minimalist router that works on Workers, Deno, Bun, Node.js. Good choice if you need unified code for edge and server.

Vendor lock-in — a real problem. Lambda-specific code (handler signature, Lambda context) is hard to port. Hono.js, Remix, or adapters like @hono/node-server help keep logic portable. Мы проектируем абстракции, позволяющие сменить провайдера с минимальными изменениями.

How We Optimize Cold Start in AWS Lambda?

Cold start is Lambda's worst enemy. Here’s a step‑by‑step optimisation checklist we apply:

1. Minimise bundle size — tree‑shake dependencies, use Lambda Layers for native binaries (sharp, puppeteer). Target < 1MB.
2. Enable Provisioned Concurrency for latency‑critical functions — costs extra but cuts cold start to near zero.
3. Use SnapStart for Java (Lambda) — reduces init time by 90%+.
4. Avoid VPC unless necessary — if you need VPC, use AWS PrivateLink or Elastic Network Interface optimisation.
5. Warm‑up strategies — scheduler pinging function every 5 minutes (but only for low‑volume functions, otherwise Provisioned Concurrency cheaper).

Result: our clients typically see cold start drop from 2–4s to under 500ms. For a fintech API handling 50k requests/day, that means 3 fewer seconds of latency per request during peak scale.

When Does Serverless Not Fit? Cost Comparison

Serverless saves money when traffic is unpredictable or sparse — up to 70% reduction compared to dedicated servers. But it becomes expensive under constant high load. Example: a function processing 1 million requests/day at 300ms each costs about $100–200/month on Lambda. Equivalent EC2 instance might cost $50/month. For such steady workloads, Fargate or EC2 is cheaper.

Long computations (>15 min on Lambda, >30s on Vercel) require Fargate or a regular server. WebSocket server with state — no persistent process. Tasks with frequent disk access — ephemeral storage, /tmp on Lambda 512MB–10GB.

What’s Included in Serverless Development Service?

Мы предлагаем serverless-разработку под ключ. В каждый проект входит:

• Архитектурная документация (схема event‑driven потоков, выбор платформы, justification).
• Реализация функций с unit‑ и integration‑тестами.
• CI/CD pipeline (GitHub Actions / GitLab CI) с preview‑деплоями.
• Infrastructure as Code (Terraform / AWS CDK / Pulumi).
• Мониторинг и observability (OpenTelemetry, structured logging, distributed tracing).
• 30‑дневная пост‑релизная поддержка и оптимизация производительности.

Typical Mistakes in Serverless Development and How We Avoid Them

• Ignoring cold start — we measure and budget for it from day one.
• Over‑engineering state — many teams try to use Workers Durable Objects for simple caching; KV is often enough.
• No distributed tracing — without trace IDs across SQS › Lambda › DynamoDB streams, debugging is blind. We integrate AWS X‑Ray or OpenTelemetry automatically.
• Underestimating cost at scale — we simulate load patterns and compare serverless vs. container costs before committing.

Закажите serverless архитектуру под ключ — свяжитесь с нами для бесплатной оценки вашего проекта. Сроки: от 2 недель для MVP, до 10 недель для миграции монолита. Стоимость рассчитывается индивидуально, ориентировочно от $2,000 до $15,000 в зависимости от сложности.