Neon vs Turso vs PlanetScale: выбор бессерверной базы данных в 2026 году
Engineering Team
Краткий ответ
Если вам нужна совместимость с PostgreSQL и современный опыт разработки, выбирайте Neon. Если нужны чтения менее 10 мс на edge с совместимостью SQLite, выбирайте Turso. Если вы работаете с MySQL и нужно горизонтальное шардирование, выбирайте PlanetScale. Все три платформы готовы к продакшену в 2026 году, и выбор зависит в первую очередь от предпочитаемого SQL-диалекта и топологии развёртывания.
Ландшафт бессерверных баз данных в 2026 году
Рынок бессерверных баз данных значительно повзрослел с 2023 года. То, что начиналось как экспериментальные управляемые предложения, стало моделью развёртывания по умолчанию для стартапов и всё более частым выбором для предприятий. Мировой рынок бессерверных баз данных достиг $14,2 млрд в 2025 году, с ростом CAGR 28% по данным Gartner.
Три платформы выделились как явные лидеры, каждая построена на принципиально различных основах:
- Neon — бессерверный PostgreSQL с разделением хранения и вычислений, бранчингом и автоскейлингом до нуля
- Turso — libSQL (форк SQLite) с edge-репликацией, встроенными репликами и маршрутизацией по запросам
- PlanetScale — MySQL-совместимый, построен на Vitess (технология масштабирования YouTube/Google), с безопасным развёртыванием схемы
Эти платформы не взаимозаменяемы. Каждая превосходит в разных архитектурных контекстах, и неправильный выбор создаёт трение, которое накапливается со временем.
Neon: бессерверный PostgreSQL правильно
Neon — это бессерверная PostgreSQL-платформа, которая разделяет хранение и вычисления, обеспечивая возможности, невозможные в традиционных развёртываниях PostgreSQL: мгновенный бранчинг, масштабирование до нуля и восстановление на момент времени на уровне хранилища.
Архитектура
Архитектура Neon разделяет PostgreSQL на три уровня:
- Вычисления: стандартные экземпляры PostgreSQL (в настоящее время PG 16 и 17, поддержка PG 18 анонсирована на Q1 2026), обрабатывающие выполнение запросов
- Pageserver: кастомный бэкенд хранения, заменяющий локальную файловую систему PostgreSQL, хранящий страницы в многоуровневом формате, оптимизированном для облачного объектного хранилища
- Safekeepers: узлы обеспечения долговечности WAL, гарантирующие сохранность зафиксированных транзакций
Это разделение означает, что вычисления масштабируются независимо от хранения. База данных Neon может масштабироваться до нуля при простое (оплачивается только хранение) и запускать вычислительную точку за ~500 мс при поступлении соединения.
Бранчинг: ключевая возможность
Наиболее отличительная возможность Neon — бранчинг баз данных, по аналогии с Git. Создание ветки — это операция copy-on-write, завершающаяся за миллисекунды независимо от размера базы данных.
# Создать ветку от продакшена для тестирования
neonctl branches create --name feature-auth-redesign --parent main
# Получить строку подключения для ветки
neonctl connection-string feature-auth-redesign
# Ветка — это полный экземпляр PostgreSQL с продакшен-данными
psql $(neonctl connection-string feature-auth-redesign)
Сценарии использования бранчинга:
- Preview-окружения: каждый pull request получает собственную ветку базы данных с продакшен-данными. Тестируйте миграции на реальных данных, а не пустых схемах.
- Безопасные миграции: создайте ветку от продакшена, запустите миграцию на ветке, убедитесь, что она работает, затем примените к продакшену.
- Изоляция аналитики: создайте ветку для тяжёлых аналитических запросов, не влияя на производительность продакшен OLTP.
- Разработка: каждый разработчик получает персональную ветку базы данных.
Автоскейлинг
Neon автоматически масштабирует вычисления от 0,25 vCPU до 8 vCPU в зависимости от нагрузки. Масштабирование до нуля — настоящее: если запросов нет 5 минут (настраивается), вычисления полностью отключаются. Вы платите только за хранение в периоды простоя.
Для продакшен-нагрузок Neon предлагает всегда-включённые вычислительные точки с минимальным выделением. Автоскейлер реагирует на нагрузку в течение 2-3 секунд.
Цены (март 2026)
| План | Вычисления | Хранение | Бранчинг | Цена |
|---|---|---|---|---|
| Free | 0,25 vCPU, 100 ч/мес | 512 МБ | 10 веток | $0 |
| Launch | До 4 vCPU | 10 ГБ | Без ограничений | $19/мес |
| Scale | До 8 vCPU | 50 ГБ | Без ограничений | $69/мес |
| Enterprise | Custom | Custom | Без ограничений | Custom |
Ограничения
- Задержка холодного старта. Точки, масштабированные до нуля, возобновляются за 300-700 мс. Для всегда-горячих приложений сохраняйте минимальное выделение вычислений.
- Поддержка расширений. Большинство популярных расширений работают (PostGIS, pgvector, pg_stat_statements), но некоторые, требующие доступа к файловой системе, не поддерживаются.
- Доступность регионов. Доступен в 12 регионах AWS и 5 регионах Azure на март 2026. Поддержки GCP пока нет.
- Лимит соединений. Встроенный пулер соединений обрабатывает до 10 000 параллельных соединений на плане Scale.
Turso: edge-нативный SQLite
Turso построен на libSQL — форке SQLite с открытым исходным кодом, добавляющем серверные возможности: репликацию, контроль доступа и мультитенантность. Уникальное предложение Turso — edge-нативное развёртывание: ваша база данных работает в 30+ локациях по всему миру, чтения обслуживаются ближайшей edge-репликой.
Архитектура
Архитектура Turso принципиально отличается от Neon и PlanetScale:
- Первичный экземпляр: единственная libSQL база данных с единственным писателем в выбранном первичном регионе
- Edge-реплики: реплики только для чтения, развёрнутые в edge-локациях по всему миру, синхронизируемые через кастомный протокол репликации
- Встроенные реплики: libSQL может встроить реплику для чтения непосредственно в процесс вашего приложения, обеспечивая чтения с нулевой задержкой
Модель встроенных реплик — самая инновационная возможность Turso. Ваше приложение встраивает SQLite-совместимый файл базы данных, который синхронизируется с первичным. Чтения обращаются к локальному файлу — без сетевого round-trip. Записи пересылаются к первичному и реплицируются обратно.
import { createClient } from '@libsql/client';
const db = createClient({
url: 'file:local-replica.db',
syncUrl: 'libsql://my-db-username.turso.io',
authToken: process.env.TURSO_AUTH_TOKEN,
syncInterval: 60, // Синхронизация каждые 60 секунд
});
// Это чтение обращается к локальному файлу — субмиллисекундная задержка
const users = await db.execute('SELECT * FROM users WHERE active = 1');
// Эта запись отправляется к первичному, затем реплицируется обратно
await db.execute({
sql: 'INSERT INTO events (user_id, type) VALUES (?, ?)',
args: [userId, 'login'],
});
Мультитенантность
Turso поддерживает создание тысяч баз данных на аккаунт, каждая — отдельный SQLite-файл. Это обеспечивает изоляцию баз данных по клиентам — каждый заказчик получает собственную базу данных, устраняя проблемы «шумных соседей» и упрощая соблюдение требований к месту хранения данных.
Цены (март 2026)
| План | Базы данных | Хранение | Чтений строк/мес | Записей строк/мес | Цена |
|---|---|---|---|---|---|
| Starter | 500 | 9 ГБ | 25 млрд | 50 млн | $0 |
| Scaler | 10 000 | 24 ГБ | 100 млрд | 100 млн | $29/мес |
| Enterprise | Без ограничений | Custom | Custom | Custom | Custom |
Лучше всего подходит для
- Edge-приложения: приложения на Cloudflare Workers, Vercel Edge Functions или Deno Deploy, где важна каждая миллисекунда задержки
- Per-tenant базы данных: SaaS-приложения, требующие изоляции данных без стоимости отдельного PostgreSQL на клиента
- Мобильные/offline-first приложения: встроенные реплики обеспечивают офлайн-чтения с фоновой синхронизацией
- Нагрузки с преобладанием чтений: модель встроенных реплик даёт субмиллисекундную задержку чтения
Ограничения
- Только совместимость с SQLite. Нет функций PostgreSQL или MySQL. Если нужны JSONB-операторы, оконные функции сверх возможностей SQLite или хранимые процедуры — Turso не подходит.
- Единственный писатель. Все записи проходят через первичный. Пропускная способность записи ограничена одним экземпляром libSQL (хотя обычно это 10 000+ записей/сек).
- Нет JOIN между базами данных. Изоляция мультитенантности означает невозможность запросов между клиентами.
- Изменения схемы. Нет онлайн DDL — ALTER TABLE кратковременно блокирует базу данных.
PlanetScale: MySQL масштаба YouTube
PlanetScale привносит Vitess — middleware для шардирования, который работает в YouTube, Slack и GitHub — разработчикам как управляемый сервис. Он предоставляет MySQL-совместимые бессерверные базы данных с горизонтальным шардированием, безопасным развёртыванием схемы и встроенным пулингом соединений.
Архитектура
Архитектура PlanetScale построена на трёх компонентах Vitess:
- VTGate: MySQL-совместимый прокси, маршрутизирующий запросы к нужному шарду
- VTTablet: управляет отдельными экземплярами MySQL (шардами)
- VTOrc: автоматический фейловер и управление топологией
Шардирование прозрачно для приложения. Вы пишете стандартные MySQL-запросы, а Vitess маршрутизирует их к нужному шарду на основе конфигурации ключа шардирования.
Безопасные изменения схемы
Workflow deploy request PlanetScale предотвращает поломку продакшена изменениями схемы:
# Создать ветку (аналогично Neon, но только для схемы)
pscale branch create feature-add-orders
# Применить изменения схемы к ветке
pscale shell feature-add-orders
mysql> ALTER TABLE orders ADD COLUMN status ENUM('pending', 'shipped', 'delivered');
# Создать deploy request (как PR для вашей схемы)
pscale deploy-request create feature-add-orders
# Проверить diff схемы
pscale deploy-request diff feature-add-orders 1
# Развернуть в продакшен (неблокирующий, онлайн DDL)
pscale deploy-request deploy feature-add-orders 1
Изменения схемы применяются через онлайн DDL (gh-ost под капотом) — никаких блокировок таблиц во время ALTER TABLE. Это критично для больших таблиц.
Цены (март 2026)
| План | Хранение | Чтений строк/мес | Записей строк/мес | Соединения | Цена |
|---|---|---|---|---|---|
| Hobby | 5 ГБ | 1 млрд | 10 млн | 1 000 | $0 |
| Scaler | 10 ГБ | 100 млрд | 50 млн | 10 000 | $29/мес |
| Scaler Pro | 128 ГБ | Без ограничений | 200 млн | 20 000 | $99/мес |
| Enterprise | Custom | Custom | Custom | Custom | Custom |
Лучше всего подходит для
- MySQL-нативные команды: если экспертиза вашей команды — MySQL, PlanetScale даёт лучший бессерверный MySQL без изучения новой базы данных.
- Горизонтальное масштабирование: приложения, которым нужно масштабироваться за пределы одного сервера.
- DDL на больших таблицах: система онлайн DDL — наиболее проверенная в индустрии (Vitess работает в YouTube).
- Пулинг соединений: Vitess эффективно обрабатывает десятки тысяч соединений.
Ограничения
- Нет внешних ключей (на уровне БД). PlanetScale исторически требовал контроля FK на уровне приложения из-за ограничений шардирования Vitess. Ограниченная поддержка FK появилась в 2025, но остаётся ограничением для сложных реляционных моделей.
- Только MySQL. Нет совместимости с PostgreSQL.
- Нет варианта self-hosting. В отличие от Neon (локальный эмулятор) и Turso (open-source), PlanetScale только управляемый.
Таблица сравнения возможностей
| Возможность | Neon | Turso | PlanetScale |
|---|---|---|---|
| SQL-диалект | PostgreSQL | SQLite (libSQL) | MySQL |
| Масштабирование до нуля | Да (300-700 мс возобновление) | Да (мгновенно) | Нет (всегда включён) |
| Бранчинг | Полные ветки данных | Схема + данные | Только deploy requests |
| Edge-реплики | Нет (один регион + read replicas) | Да (30+ локаций) | Нет (один регион) |
| Встроенные реплики | Нет | Да (нулевая задержка чтений) | Нет |
| Горизонтальное шардирование | Нет | Нет | Да (Vitess) |
| Онлайн DDL | Стандартный PG (с блокировками) | Кратковременные блокировки | gh-ost (без блокировок) |
| Расширения | PostgreSQL extensions | libSQL extensions | MySQL plugins (ограничено) |
| Векторный поиск | pgvector | Через расширение | Нет нативной поддержки |
| Пулинг соединений | Встроенный (pgbouncer-совместимый) | N/A (HTTP + встроенный) | Встроенный (Vitess) |
| Open source | Neon (Apache 2.0) | libSQL (MIT) | Vitess (Apache 2.0) |
| Бесплатный план | 512 МБ, 100 вычисл.-ч | 9 ГБ, 500 БД | 5 ГБ, 1 млрд чтений |
| Задержка (p50 чтение) | 5-15 мс (тот же регион) | <1 мс (встроенная), 5-15 мс (edge) | 3-10 мс (тот же регион) |
Фреймворк принятия решения
Выбирайте Neon, когда:
- Нужна совместимость с PostgreSQL (расширения, JSONB, PostGIS, pgvector)
- Бранчинг баз данных для preview-окружений важен для вашего workflow
- Нужно масштабирование до нуля для dev/staging-окружений
- Приложение развёрнуто в одном регионе или использует региональные read replicas
- Вы мигрируете с традиционного развёртывания PostgreSQL
Выбирайте Turso, когда:
- Развёртывание на edge-рантаймах (Cloudflare Workers, Deno Deploy, Vercel Edge)
- Субмиллисекундная задержка чтения — требование (встроенные реплики)
- Нужна изоляция per-tenant для мультитенантного SaaS
- Нагрузка с преобладанием чтений (95%+)
- Вы строите мобильное или offline-first приложение
- Совместимости с SQLite достаточно для вашей модели данных
Выбирайте PlanetScale, когда:
- Ваша команда MySQL-нативна и вы не хотите менять SQL-диалект
- Нужно горизонтальное шардирование для таблиц с миллиардами строк
- Миграции схемы без простоя критичны (онлайн DDL)
- Нужно обрабатывать десятки тысяч параллельных соединений
- Вы мигрируете с self-managed MySQL или Aurora
Примеры реальных архитектур
SaaS с Neon
B2B SaaS-приложение с 200 клиентами, каждый генерирует 10-50 ГБ данных. Используйте Neon с одной базой данных, row-level security для изоляции клиентов и бранчингом для staging-окружений. JSONB и pgvector PostgreSQL поддерживают и структурированные данные, и AI-функции без дополнительных баз данных.
Edge-коммерция с Turso
Глобальный каталог товаров для электронной коммерции, обслуживающий 50 стран. Используйте Turso со встроенными репликами в каждой edge-функции. Чтения товаров (99% трафика) обращаются к локальной SQLite-реплике с субмиллисекундной задержкой. Обновления корзины и заказы записываются к первичному в us-east-1 с задержкой 50-150 мс.
Высоконагруженная аналитика с PlanetScale
Аналитическая платформа, принимающая 500 000 событий/секунду от мобильных SDK. Используйте PlanetScale с горизонтальным шардированием по customer_id. Vitess распределяет записи по 16 шардам, каждый обрабатывает ~31 000 записей/сек.
FAQ
Можно ли мигрировать между этими платформами?
Да, но это нетривиально. Neon-в-PlanetScale или наоборот требует миграции SQL-диалекта (PostgreSQL в MySQL). Neon-в-Turso требует миграции с PostgreSQL на SQLite, что может привести к потере функций. Планируйте 2-4 недели усилий для продакшен-приложения.
Какой вариант дешевле для маленького проекта?
У всех трёх щедрые бесплатные планы. Бесплатный план Turso самый щедрый (9 ГБ хранения, 500 баз данных). Бесплатный план Neon наиболее ограничен вычислительными часами (100/месяц). Для хобби-проектов все три фактически бесплатны.
Заменяет ли что-то из этого Redis для кеширования?
Встроенные реплики Turso могут заменить Redis для сценариев кеширования чтений, когда данные всё равно хранятся в базе данных. Вместо паттерна cache-aside (чтение БД, запись Redis, чтение Redis) вы читаете встроенную SQLite-реплику напрямую. Это устраняет сложность инвалидации кеша ценой немного большей задержки, чем Redis для горячих ключей.
Как они сравниваются с Supabase?
Supabase — более широкая платформа (auth, storage, realtime, edge functions) на базе PostgreSQL. Neon — сфокусированное бессерверное PostgreSQL-предложение. Если нужна полная платформа Supabase, используйте Supabase. Если нужен лучший бессерверный PostgreSQL с бранчингом и автоскейлингом, используйте Neon.
Какая платформа выдерживает больше параллельных соединений?
PlanetScale, благодаря мультиплексированию соединений Vitess. Он выдерживает 100 000+ соединений приложений, мультиплексированных к значительно меньшему количеству соединений к базе данных. Neon поддерживает до 10 000 на плане Scale. Turso использует HTTP-соединения, поэтому концепция другая — он обрабатывает миллионы запросов в секунду на edge.