Настройка Turso (SQLite Edge) для веб-приложения

Наша компания занимается разработкой, поддержкой и обслуживанием сайтов любой сложности. От простых одностраничных сайтов до масштабных кластерных систем построенных на микро сервисах. Опыт разработчиков подтвержден сертификатами от вендоров.

Разработка и обслуживание любых видов сайтов:

Информационные сайты или веб-приложения
Сайты визитки, landing page, корпоративные сайты, онлайн каталоги, квиз, промо-сайты, блоги, новостные ресурсы, информационные порталы, форумы, агрегаторы
Сайты или веб-приложения электронной коммерции
Интернет-магазины, B2B-порталы, маркетплейсы, онлайн-обменники, кэшбэк-сайты, биржи, дропшиппинг-платформы, парсеры товаров
Веб-приложения для управления бизнес-процессами
CRM-системы, ERP-системы, корпоративные порталы, системы управления производством, парсеры информации
Сайты или веб-приложения электронных услуг
Доски объявлений, онлайн-школы, онлайн-кинотеатры, конструкторы сайтов, порталы предоставления электронных услуг, видеохостинги, тематические порталы

Это лишь некоторые из технических типов сайтов, с которыми мы работаем, и каждый из них может иметь свои специфические особенности и функциональность, а также быть адаптированным под конкретные потребности и цели клиента

Услуги, которые мы предлагаем
Показано 1 из 1Все 2062 услуг
Настройка Turso (SQLite Edge) для веб-приложения
Средний
от 1 дня до 3 дней
Часто задаваемые вопросы

Наши компетенции:

Этапы разработки

Последние работы

  • image_website-b2b-advance_0.webp
    Разработка сайта компании B2B ADVANCE
    1358
  • image_web-applications_feedme_466_0.webp
    Разработка веб-приложения для компании FEEDME
    1250
  • image_websites_belfingroup_462_0.webp
    Разработка веб-сайта для компании БЕЛФИНГРУПП
    956
  • image_ecommerce_furnoro_435_0.webp
    Разработка интернет магазина для компании FURNORO
    1188
  • image_crm_enviok_479_0.webp
    Разработка веб-приложения для компании Enviok
    929
  • image_bitrix-bitrix-24-1c_fixper_448_0.webp
    Разработка веб-сайта для компании ФИКСПЕР
    947

Ваше глобальное веб-приложение тормозит на пользователях из других регионов? База данных в одном дата-центре создаёт лишнюю задержку. Мы решаем это с помощью 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 дня. Вот основные шаги:

  1. Аудит схемы и нагрузки — определяем, подходит ли read-heavy сценарий.
  2. Создание primary и реплик — через CLI выбираем регионы.
  3. Интеграция с Drizzle ORM — типизированные запросы, миграции.
  4. Настройка embedded replica — для Cloudflare Workers или Node.js.
  5. 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 дня. Позвоните или напишите — обсудим детали. Получите консультацию по вашему проекту уже сегодня.

Serverless-разработка: AWS Lambda, Vercel Functions, Cloudflare Workers, Edge

Serverless не означает «без сервера». Серверы есть — вы просто не управляете ими. Правильнее читать это как «без менеджмента серверов»: нет патчинга ОС, нет настройки nginx, нет мониторинга дискового пространства. Функция получает событие, обрабатывает, возвращает ответ. Провайдер сам решает, на чём это запустить.

AWS Lambda: мощь и операционная сложность

Lambda — самая зрелая платформа с наибольшим набором триггеров: API Gateway, SQS, SNS, S3, DynamoDB Streams, EventBridge. Это важно для сложных event-driven архитектур.

Cold start — главная боль Lambda на Node.js: от 200ms до 1.5s в зависимости от размера бандла и VPC. В VPC холодный старт был до 10 секунд до 2019 года, сейчас улучшили, но он всё ещё дольше. Для production-функций с latency-требованиями: Provisioned Concurrency (держит инстансы прогретыми), SnapStart для Java, минимизация бандла через tree-shaking.

Практический кейс: функция обработки загружаемых изображений (ресайз, WebP-конвертация, загрузка в S3). Бандл с sharp весил 40MB из-за нативных бинарников. Решение — Lambda Layer с sharp, основная функция 800KB. Cold start упал с 3.2s до 400ms.

Lambda Layers — общие зависимости между функциями. До 5 слоёв на функцию, каждый до 250MB. Стандартная практика: layer с heavy dependencies (sharp, puppeteer, ffmpeg), layer с общей бизнес-логикой.

Инфраструктура Lambda через AWS CDK или Terraform. SAM — для тех, кто только начинает, CDK — для серьёзных проектов с типобезопасностью.

Vercel Functions и Edge Runtime

Vercel Functions — это Lambda под капотом (us-east-1 по умолчанию), но с минимальным порогом входа для Next.js-проектов. API Routes и Route Handlers деплоятся автоматически. Serverless функции на Node.js runtime с лимитом в 300 секунд на Vercel Pro.

Edge Runtime принципиально другой: функция запускается на V8 isolate в ближайшей к пользователю точке CDN-сети Vercel (120+ регионов). Нет cold start как такового — isolate стартует за ~0ms. Но жёсткие ограничения: нет Node.js API (fs, crypto через Web API), нет доступа к базам данных через TCP (только через HTTP API), размер бандла до 4MB.

Edge Runtime идеален для: middleware (auth check, redirect, A/B test), трансформации ответов, геолокационной логики, Edge Config. Не подходит для: обращения к PostgreSQL, тяжёлых вычислений, работы с файловой системой.

Cloudflare Workers: настоящий Edge

Workers запускаются на V8 isolates в 300+ точках присутствия Cloudflare. Latency для пользователя — буквально ближайший дата-центр. Cold start < 1ms.

Workers Durable Objects решают проблему состояния в Edge: каждый Durable Object — это одна точка координации, выполняется в одном регионе. Идеально для: игровых комнат, документов с реальным временем, rate limiting без гонок.

Workers KV — eventually consistent хранилище. Запись распространяется по всем регионам за ~60 секунд. Не подходит для финансовых транзакций, подходит для конфигов, feature flags, кэша.

D1 — SQLite на Edge. На одной реплике для чтения работает отлично, write latency зависит от расстояния до primary региона. Для глобальных write-heavy приложений — не лучший выбор.

Ecosystem: Hono.js — минималистичный роутер, работающий на Workers, Deno, Bun, Node.js. Если нужен единый код для Edge и сервера — хороший выбор.

Когда serverless не подходит

Длительные вычисления (>15 минут на Lambda, >30 секунд на Vercel) — нужен Fargate или обычный сервер. WebSocket-сервер с состоянием — нет постоянного процесса. Задачи с частым обращением к диску — эфемерный storage, /tmp на Lambda 512MB–10GB. Если функция вызывается тысячи раз в секунду постоянно — EC2 или Fargate дешевле.

Vendor lock-in — реальная проблема. Lambda-специфичный код (handler-сигнатура, Lambda context) сложно портировать. Hono.js, Remix, или адаптеры типа @hono/node-server помогают держать логику portable.

Observability

Без нормального observability serverless — чёрный ящик. Стандарт: AWS X-Ray или Powertools for AWS Lambda (structured logging, tracing, metrics из коробки). Для мультиоблачного стека — OpenTelemetry с экспортом в Grafana Cloud или Honeycomb.

Distributed tracing критичен когда функция А вызывает функцию Б через SQS — без trace ID невозможно связать логи.

Процесс работы

Начинаем с анализа паттерна нагрузки: если трафик непредсказуемый или редкий — serverless даст экономию. Если стабильно высокий — может оказаться дороже. Проектируем границы функций по принципу single responsibility. Разрабатываем локально через SST, Wrangler или LocalStack. CI/CD с preview deployments обязательно.

Сроки

Serverless API для стартапа (10–20 функций): 2–5 недель. Миграция монолитного Laravel/Node API на Lambda: 4–10 недель в зависимости от объёма. Edge Middleware + Workers для глобального продукта: 2–4 недели.