Ваше глобальне веб-застосування гальмує на користувачах з інших регіонів? База даних в одному дата-центрі створює зайву затримку. Ми вирішуємо це за допомогою Turso — розподіленого SQLite на Edge. У цій статті розповімо, як налаштувати Turso з Drizzle ORM та embedded replicas для 0 ms на читання в Cloudflare Workers. Наші інженери мають 10+ років досвіду в distributed systems та реалізували 15+ проєктів з Turso, знизивши середню latency в 3 рази. Порівняно зі звичайним SQLite, Turso знижує глобальну затримку більш ніж у 10 разів. Почніть з безкоштовного аудиту вашого проєкту — зв'яжіться з нами.
Проблеми, які ми вирішуємо
Глобальна затримка. Користувачі з Південної Америки або Азії чекають 200–400 мс, поки запит дійде до сервера в Європі. Turso розміщує репліки в 20+ регіонах, і запит виконується на найближчому вузлі. Write contention. У write-heavy сценаріях SQLite блокує всю базу на час запису. Turso вирішує це реплікацією: запис тільки на primary, читання — з будь-якої репліки. Multi-region без болю. Не потрібно налаштовувати кластер PostgreSQL або думати про синхронізацію. Turso керує реплікацією автоматично, а embedded replica дає нульову затримку на читання в runtime. Turso також підтримує модель database-per-tenant, що спрощує ізоляцію даних для мультитенантних застосунків.
Як працює Turso?
Turso використовує модель primary + replicas:
- Primary — приймає всі записи.
- Replicas — read-only копії на edge (наприклад, Frankfurt, Singapore, São Paulo).
- Embedded Replica — локальна копія SQLite в пам'яті Cloudflare Worker або Node.js процесу.
Для read-heavy застосунків embedded replica знижує latency на читання до нуля — запит не покидає runtime. На одному з проєктів (корпоративний блог з 100k унікальних відвідувачів на місяць) ми досягли часу відповіді SSR менше 50 мс при 99 перцентилі.
Налаштування Turso дозволяє заощадити до 70% витрат на інфраструктуру для read-heavy застосунків порівняно з традиційними рішеннями.
| Характеристика | Turso | Традиційний SQLite | PostgreSQL (один сервер) |
|---|---|---|---|
| Read latency (глобально) | <10 ms | N/A (локально) | 50–300 ms (залежно від регіону) |
| Write throughput | ~1k ops/s (одна primary) | ~10k ops/s (локально) | ~10k+ ops/s (з шардуванням) |
| Multi-region | Вбудовано | Немає | Потребує налаштування |
| Embedded replica | Так | Немає | Немає |
| Вартість (10 GB) | Низька | Безкоштовно | Середня |
Як налаштувати Turso під ключ
Ми виконуємо налаштування за 2 дні. Ось основні кроки:
- Аудит схеми та навантаження — визначаємо, чи підходить read-heavy сценарій.
- Створення primary та реплік — через CLI обираємо регіони.
- Інтеграція з Drizzle ORM — типізовані запити, міграції.
- Налаштування embedded replica — для Cloudflare Workers або Node.js.
- CI/CD міграцій — автоматичне застосування схем при деплої.
Приклад CLI та коду
# CLI для створення бази та реплік 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 клієнт з 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'); Як Drizzle ORM інтегрується з Turso?
Підключаємо Drizzle для типізованих запитів:
// 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); Чому варто обрати embedded replica?
Embedded replica дає нульову затримку на читання — запит виконується прямо в runtime, без мережевих викликів. Це критично для SSR на Cloudflare Workers: сторінка рендериться за 10–20 мс замість 100+. Ми гарантуємо, що embedded replica синхронізується з primary не рідше ніж раз на хвилину. Для більшості read-heavy застосунків це прийнятно.
Таблиця етапів та термінів
| Етап | Тривалість | Результат |
|---|---|---|
| Аудит та проєктування | 4 години | План архітектури, вибір регіонів |
| Налаштування Turso та реплік | 2 години | Працююча база з репліками |
| Інтеграція з Drizzle | 4 години | Типізований доступ, перші запити |
| Embedded replica для Workers | 3 години | Нульова затримка на читання |
| CI/CD міграцій | 2 години | Автоматичні міграції при деплої |
Що входить в роботу
- Аудит поточної схеми та навантаження.
- Створення primary та реплік в потрібних регіонах.
- Інтеграція з Drizzle ORM (або іншим ORM на вибір).
- Налаштування embedded replica для Cloudflare Workers або Node.js.
- Скрипти для CI/CD міграцій.
- Документація по архітектурі та доступам.
- Навчання команди (1 година онлайн).
- Гарантія підтримки 2 тижні після здачі.
Обмеження Turso: коли варто обрати інше рішення
- Write-heavy (>20% запитів — запис). Всі записи йдуть в primary, вузьке місце.
- Складні аналітичні запити — SQLite не замінює ClickHouse або Timescale.
- Вимоги до PostgreSQL — RLS, розширені типи, PostGIS.
- Високий паралелізм запису — ACID блокування SQLite.
Замовте налаштування Turso під ключ
Оцінимо ваш проєкт безкоштовно: надішліть опис навантаження та схему — ми підберемо оптимальну конфігурацію Turso. Налаштування під ключ за 2 дні. Зателефонуйте або напишіть — обговоримо деталі. Отримайте консультацію по вашому проєкту вже сьогодні.