Neon проти PlanetScale проти Turso: Postgres, MySQL чи SQLite на Edge?

Вибір між Neon, PlanetScale та Turso зводиться до трьох фундаментально різних ставок: Postgres, MySQL/Vitess та SQLite на edge (периферії мережі). За останній рік ландшафт різко змінився: Databricks придбала Neon приблизно за $1 млрд, PlanetScale запустила підтримку Postgres, а Turso відмовилася від масштабування до нуля (scale-to-zero). Якщо ви обираєте serverless-базу даних у 2026 році, більшість порівнянь, які ви читали раніше, ймовірно, вже застаріли.

Neon проти PlanetScale проти Turso: короткий огляд

Обирайте Neon, якщо вам потрібна повна сумісність із Postgres, щедрий безкоштовний тариф і найкраща інтеграція з Vercel. Обирайте PlanetScale, якщо вам потрібен MySQL корпоративного рівня з горизонтальним шардуванням. Обирайте Turso, якщо для вас найважливішими є затримка на edge та архітектури «одна база даних на користувача» для мультитенантних систем.

Це коротка версія. Далі в статті ми детально розберемо, чому кожен пункт виглядає саме так.

Як працює кожна база даних «під капотом»?

Рушій кожної платформи визначає все: від синтаксису запитів до обмежень масштабування. Розуміння архітектури допоможе передбачити поведінку системи зі зростанням вашого додатку.

Neon: Serverless Postgres із гілкуванням

Neon повністю розділяє обчислення та сховище. Ваші обчислювальні вузли Postgres ефемерні: вони запускаються при надходженні запиту та зупиняються (або масштабуються до нуля) під час простою. Сховище знаходиться на окремому шарі pageserver, який забезпечує довговічність даних та відновлення на певний момент часу.

Ця архітектура дозволяє реалізувати головну фішку Neon: гілкування через copy-on-write. Створення гілки бази даних відбувається майже миттєво незалежно від розміру, оскільки дані не копіюються — гілка спільно використовує сторінки сховища з батьківською базою і записує нові сторінки лише при зміні даних. Уявіть собі git branch для вашої бази даних.

• Повна підтримка протоколу PostgreSQL (pg_dump, psql тощо)
• Автомасштабування обчислень від 0.25 до 56 CU
• Вбудований пул з’єднань через PgBouncer
• Архітектура Neon використовує safekeepers для надійності журналу попереднього запису (WAL)

PlanetScale: MySQL на базі Vitess (і тепер Postgres)

PlanetScale працює на Vitess, рушію кластеризації MySQL, спочатку створеному в YouTube для шардування їхньої бази даних на десятки тисяч вузлів. Якщо вам потрібне горизонтальне масштабування для MySQL, Vitess є найбільш перевіреною рішенням.

Фірмова особливість DX від PlanetScale — це deploy requests, своєрідні pull-реквести для змін схеми. Ви пропонуєте міграцію, переглядаєте різницю (diff) і застосовуєте її без простою. Ніяких блокувань, нічних вікон обслуговування.

З вересня 2025 року PlanetScale також пропонує керований Postgres. Це окремий продукт від їхньої пропозиції на Vitess: односерверні бази даних Postgres починаються від $5/міс. Горизонтальне шардування для Postgres (проєкт «Neki») все ще в розробці.

Щоб глибше зануритися в те, коли Postgres краще за MySQL (і навпаки), ознайомтеся з нашим порівнянням PostgreSQL та MySQL.

• Vitess: горизонтальне шардування, міграції схеми без простою
• Postgres: один вузол, готовий до продакшену, але поки без шардування
• Deploy requests для безпечних змін схеми з можливістю рев'ю
• Без масштабування до нуля, бази даних завжди працюють

Turso: SQLite на Edge з libSQL

Turso обирає зовсім інший підхід. Замість запуску бази даних на сервері, вона використовує libSQL — відкриту форк-версію SQLite з можливостями серверного режиму. Ваші дані можуть жити на edge, буквально будучи вбудованими в середовище виконання вашого додатку.

Ключова концепція — вбудовані репліки: репліки для читання, які працюють всередині процесу вашого додатку (або на edge-локаціях) із нульовою затримкою мережі при читанні. Записи йдуть до первинного екземпляра і асинхронно поширюються на репліки.

• libSQL розширює SQLite HTTP-доступом, реплікацією та мультитенантністю
• Модель «одна база на користувача» підтримує тисячі ізольованих баз
• Записи поширюються від первинної бази до реплік за мілісекунди
• Ідеально для додатків з великим навантаженням на читання та глобальним розподілом

Вердикт: Neon перемагає за широтою архітектури. Повноцінний Postgres із миттєвим гілкуванням покриває найширший спектр випадків використання. PlanetScale виграє, якщо вам конкретно потрібне горизонтальне шардування рівня Vitess. Turso виграє, якщо вам потрібні дані на edge.

Порівняння продуктивності та затримок

Продуктивність — це перше питання, яке ставлять розробники, і відповідь повністю залежить від того, чи «прогріта» ваша база даних, чи «холодна».

Реальність холодного старту

Neon — єдина з трьох, яка досі за замовчуванням підтримує масштабування до нуля. Коли ваш обчислювальний вузол прокидається після простою, очікуйте 400–750 мс на першому запиті. Наступні запити будуть швидкими. Ви можете усунути холодні старти, встановивши мінімальний розмір обчислень (0.25 CU коштує приблизно $7/міс).

PlanetScale завжди була always-on (завжди активною), жодних холодних стартів, крапка. Ваша база даних працює, навіть якщо ніхто не робить запитів.

Turso відмовилася від масштабування до нуля для нових користувачів у січні 2025 року. Нові реєстрації отримують always-on екземпляри, що означає відсутність холодних стартів, але й відсутність економії «плати тільки за використання».

Затримка на Edge: де сяє Turso

Для «гарячих» запитів усі три варіанти швидкі. Але вбудовані репліки Turso дають те, чого не можуть інші два: читання за одиниці мілісекунд на edge. Коли ваша репліка SQLite живе в тому ж Cloudflare Worker або Vercel Edge Function, що й ваш код, для читання взагалі немає мережевого стрибка.

Дані бенчмарків від Pilcrow (липень 2023 — сприймайте як орієнтир, а не актуальні дані) показали: HTTP PlanetScale ~8 мс, HTTP Neon ~5 мс, HTTP Turso ~27 мс для централізованих запитів. Незалежні бенчмарки на Cloudflare Workers підтвердили схожі закономірності. Ці цифри датуються періодом до запуску Postgres у PlanetScale та змін інфраструктури Turso, тому сприймайте їх як опорні точки, а не як істину в останній інстанції.

Вердикт: Turso перемагає за затримкою на edge. Вбудовані репліки з читанням без мережевих стрибків не мають аналогів. Для централізованих навантажень без проблем із холодним стартом постійна готовність PlanetScale важко перебити. Холодні старти Neon — це компроміс заради економії при масштабуванні до нуля.

Скільки реально коштує кожна база даних?

Тут більшість порівнянь схиляють, вказуючи ціни планів без розрахунку вартості для реального додатку. Виправимо це.

Розбір безкоштовних тарифів

PlanetScale скасувала свій безкоштовний тариф Hobby у квітні 2024. Най дешевша точка входу тепер — $5/міс за односерверну базу даних Postgres. Для баз даних Vitess/MySQL ціноутворення базується на кластерах і є значно вищим.

Реальна місячна вартість на чотирьох рівнях масштабу

Ці оцінки використовують актуальні ціни 2026 року з офіційних сторінок кожної платформи. Реальні витрати залежать від патернів використання.

Кілька речей кидаються в очі. Turso надзвичайно дешевий на низьких і середніх рівнях, оскільки модель ціноутворення за читання рядків вигідна для додатків із великим навантаженням на читання. Ціноутворення Neon, що залежить від використання, означає, що ви платите лише за спожите, а простій баз даних на безкоштовному тарифі нічого не коштує. Ціни PlanetScale конкурентні для односерверних Postgres, але зростають із кластерами Vitess.

«Цінова прірва» PlanetScale

Найбільша слабкість PlanetScale для соло-розробників: відсутність безкоштовного тарифу. Ви переходите від $0 (використовуючи конкурента) до мінімуму $5/міс. Для стартапів з інвестиціями це не суттєво, але для side-проєктів та прототипування безкоштовні тарифи Neon і Turso значно кращі.

З іншого боку, пропозиція Vitess від PlanetScale надає горизонтальне шардування, якому не можуть відповідати ні Neon, ні Turso. Якщо ваша пропускна здатність на запис вимагає шардування, премія виправдана.

Вердикт: Neon перемагає для більшості бюджетів. Безкоштовний тариф плюс ціноутворення за використання — найгнучкіша модель. Ціноутворення Turso за читання рядків чудове для додатків із великим навантаженням на читання. PlanetScale коштує дорожче на нижньому рівні, але забезпечує масштабування корпоративного рівня.

Який досвід розробника (DX)?

Повсякденний DX важливіший за цифри бенчмарків. Ось як ці три варіанти порівнюються за функціями, які ви дійсно використовуватимете.

Гілкування бази даних та CI/CD

Гілкування copy-on-write від Neon — це золотий стандарт. Створюйте гілку для кожного PR, запускайте міграції на ній, тестуйте з даними, подібними до продакшену, і мерджте. Інтеграція з Vercel автоматично створює гілку для кожного прев'ю-деплою.

Deploy requests від PlanetScale — це інший погляд на ту саму ідею. Замість гілкування всієї бази даних, ви гілкуєте схему. Пропонуєте міграцію, переглядаєте diff і застосовуєте її без простою. Це більш opinionated підхід, але, можливо, безпечніший для змін схеми на масштабі.

Turso не має гілкування. Ви керуєте міграціями за допомогою стандартних інструментів SQLite.

Матриця сумісності ORM

Neon та пропозиція Postgres від PlanetScale працюють із усією екосистемою ORM для Postgres «з коробки». Turso вимагає специфічних адаптерів libSQL, які добре підтримуються, але мають вужчий охоплення.

CLI та локальна розробка

У всіх трьох є солідні CLI: neonctl для Neon, pscale для PlanetScale та turso для Turso. Кожен підтримує створення баз даних, керування гілками (де застосовно) та підключення з терміналу.

Для локальної розробки гілки Neon сяють: ви можете розробляти на гілці, яка дзеркалить продакшен-дані, не торкаючись продакшену. Гілки розробки PlanetScale виконують схожу роль. Turso запускає SQLite локально, тому локальна розробка надзвичайно проста — просто вкажіть шлях до локального файлу .db.

Вердикт: Neon перемагає за досвідом розробника. Гілкування copy-on-write з інтеграцією Vercel — найкраща історія для CI/CD. Deploy requests від PlanetScale чудові для команд, які хочуть рев'ю на рівні схеми. Простота Turso недооцінена, але їй бракує гілкування.

Підключення з Next.js: код поруч

Ось як виглядає підключення до кожної бази даних з API-роуту або Server Component у Next.js. Цей код готовий до копіювання.

Підключення через сирий драйвер (усі три)

Neon з @neondatabase/serverless:

// lib/neon.ts
import { neon } from "@neondatabase/serverless";

const sql = neon(process.env.DATABASE_URL!);

// Works in Edge Runtime and Node.js
export async function getActiveUsers() {
  const users = await sql`
    SELECT * FROM users WHERE active = true
  `;
  return users;
}

PlanetScale з @planetscale/database:

// lib/planetscale.ts
import { connect } from "@planetscale/database";

const conn = connect({
  host: process.env.DATABASE_HOST,
  username: process.env.DATABASE_USERNAME,
  password: process.env.DATABASE_PASSWORD,
});

// Works in Edge Runtime and Node.js
export async function getActiveUsers() {
  const results = await conn.execute(
    "SELECT * FROM users WHERE active = true"
  );
  return results.rows;
}

Turso з @libsql/client:

// lib/turso.ts
import { createClient } from "@libsql/client";

const turso = createClient({
  url: process.env.TURSO_DATABASE_URL!,
  authToken: process.env.TURSO_AUTH_TOKEN,
});

// Works in Edge Runtime and Node.js
export async function getActiveUsers() {
  const result = await turso.execute(
    "SELECT * FROM users WHERE active = 1"
  );
  return result.rows;
}

Зауважте, що Turso використовує = 1 замість = true, оскільки SQLite не має нативного булевого типу. Невелика різниця, але вона часто застає зненацька.

Налаштування Drizzle ORM (усі три)

Якщо ви використовуєте Drizzle (а вам, мабуть, варто це робити для типобезпечних запитів), ось конфігурація для кожного:

// drizzle.config.ts — Neon
import { neon } from "@neondatabase/serverless";
import { drizzle } from "drizzle-orm/neon-http";

const sql = neon(process.env.DATABASE_URL!);
export const db = drizzle(sql);

// drizzle.config.ts — PlanetScale (MySQL/Vitess)
import { connect } from "@planetscale/database";
import { drizzle } from "drizzle-orm/planetscale-serverless";

const connection = connect({
  host: process.env.DATABASE_HOST,
  username: process.env.DATABASE_USERNAME,
  password: process.env.DATABASE_PASSWORD,
});
export const db = drizzle(connection);

// drizzle.config.ts — Turso
import { createClient } from "@libsql/client";
import { drizzle } from "drizzle-orm/libsql";

const turso = createClient({
  url: process.env.TURSO_DATABASE_URL!,
  authToken: process.env.TURSO_AUTH_TOKEN,
});
export const db = drizzle(turso);

Усі три драйвери працюють у Vercel Edge Functions та Cloudflare Workers. Поверхня API достатньо схожа, щоб перемикання між ними було переважно заміною драйвера; ваша схема Drizzle та запити залишаються тими самими (за винятком відмінностей у SQL-діалектах).

Чи можна використовувати кілька serverless-баз разом?

Ось патерн, який набирає популярності в спільноті, але про який не говорять у статтях-порівняннях: використання Turso для читання на edge та Neon для запису.

Ідея проста. Ваші основні дані живуть у Neon (повноцінний Postgres, сильна узгодженість, багаті можливості запитів). Ви реплікуєте дані з великим навантаженням на читання до edge-реплік Turso, які розташовані близько до ваших користувачів у всьому світі. Читання йдуть у Turso із затримкою менше мілісекунди; записи йдуть у Neon для довговічності та узгодженості.

Коли це має сенс:

• Глобально розподілені додатки, де важлива затримка читання (дашборди, контент-платформи)
• Мультитенантний SaaS, де дані кожного тенанта з великим навантаженням на читання виграють від edge-кешування
• Додатки зі співвідношенням читання/запису 90/10, де ви можете допустити трохи застарілі дані при читанні

Коли цього варто уникати:

• Більшості додатків не потрібне глобальне читання менше 10 мс, одного регіону Neon достатньо
• Складність підтримки двох баз даних, синхронізації даних та обробки збоїв є реальною
• Якщо ваш додаток має велике навантаження на запис, edge-читання мало допоможуть

Будьте чесні з собою: якщо ви не працюєте на глобальному масштабі з суворими вимогами до затримки, це додає складності без відчутної користі. Але для додатків, яким це потрібно, це справді елегантний патерн.

Що змінилося у 2025–2026 роках? (Три великі потрясіння)

Кожне порівняння конкурентів було написано до цих подій. Ось що змінилося і що це означає для вашого вибору сьогодні.

Neon + Databricks: що означає придбання за $1 млрд

У травні 2025 року Databricks придбала Neon приблизно за 1 мільярд доларів. Це була не просто фінансова подія, вона змінила траєкторію Neon.

Негайний вплив: Neon знизила вартість сховища на 80% (з $1.75 до $0.35 за ГБ-місяць). Аналіз Vantage припускає, що це частково сталося завдяки знижкам AWS за обсяги від Databricks, які перейшли до клієнтів Neon.

Стратегічний сигнал: Databricks зазначила, що 80% баз даних Neon тепер створюються AI-агентами, порівняно з 30% на момент GA. Neon позиціонує себе як базу даних за замовчуванням для розробки на основі ШІ, автоматизованого створення схеми, даних, керованих агентами, та програмного забезпечення баз даних.

Для вас як розробника придбання означає: дешевші ціни, підтримку enterprise-рівня (Databricks прибуткова) та дорожню карту, все більше оптимізовану для програмних/ШІ-воркфлоу.

PlanetScale Postgres: MySQL більше не є єдиним варіантом

У вересні 2025 року PlanetScale запустила підтримку Postgres як GA. Це повністю змінює старе формулювання «Neon = Postgres, PlanetScale = MySQL».

PlanetScale Postgres починається від $5/міс для односерверних баз даних із такими функціями, як Query Insights, рекомендації щодо схеми та гілкування. Він готовий до продакшену і вже використовується сотнями компаній. Однак горизонтальне шардування для Postgres (їхній проєкт «Neki») все ще в розробці.

Що це означає: якщо ви обираєте між Neon та PlanetScale виключно через вподобання рушія, PlanetScale тепер покриває обидва варіанти. Але Postgres від Neon більш зрілий (він був нативним Postgres з першого дня), має безкоштовний тариф і пропонує глибше гілкування з семантикою copy-on-write. На Postgres від PlanetScale варто звернути увагу, але Neon все ще лідирує на стороні Postgres.

Turso відмовляється від Scale-to-Zero: Always-On за замовчуванням

У січні 2025 року Turso оголосила про значні зміни платформи: scale-to-zero застаріло для нових користувачів, консолідація інфраструктури на AWS та припинення підтримки edge-реплік для нових реєстрацій.

Компроміс очевидний: більше немає холодних стартів (добре), але більше немає економії «безкоштовно під час простою» (менш добре). Існуючі користувачі на застарілих планах зберігають scale-to-zero, але всі інші отримують always-on екземпляри.

Це робить Turso більш передбачуваним: вас не здивує затримка холодного старту, але це також звужує розрив між Turso та PlanetScale у вимірі «serverless». Обидва тепер є always-on керованими базами даних; edge-історія Turso є тим, що її вирізняє.

Neon проти PlanetScale проти Turso: що обрати?

Досить аналізу. Ось фреймворк для прийняття рішень.

Для більшості розробників, які починають новий проєкт у 2026 році, Neon є вибором за замовчуванням. Безкоштовний тариф, повноцінний Postgres, миттєве гілкування та інтеграція з Vercel покривають 80% випадків використання. Ви завжди можете масштабуватися до платних планів або переключитися пізніше; екосистема Postgres означає, що ви ніколи не будете заблоковані.

PlanetScale займає своє місце, коли вам потрібен MySQL корпоративного масштабу або ви хочете воркфлоу deploy requests для змін схеми без простою в великих командах.

Turso — правильний вибір, коли ваша архітектура вимагає доступу до даних спершу на edge або ізоляції баз даних для мультитенантності на масштабі. Це спеціалізований інструмент, і він чудово виконує свою спеціалізацію.

Як Techsy підходить до вибору serverless-бази даних

Ми оцінюємо serverless-бази даних за чотирма вимірами для кожного клієнтського проєкту: складність моделі даних, розмір команди та вподобання SQL-діалекту, траєкторія масштабування на наступні 12–18 місяців та платформа деплою (Vercel, Cloudflare, AWS тощо).

Наш стек за замовчуванням для більшості проєктів — Neon + Drizzle + Next.js. Ось чому:

1. Postgres дає нам найбагатшу екосистему: JSON-стовпці, повнотекстовий пошук, PostGIS, розширення
2. Гілкування Neon ідеально відповідає прев'ю-деплоям та CI-пайплайнам
3. Безкоштовний тариф дозволяє нам прототипувати без накладних витрат на білінг для клієнтів на ранніх стадіях
4. Типобезпека Drizzle виявляє дрейф схеми до того, як він потрапить у продакшен

Коли ми рекомендуємо альтернативи:

• PlanetScale для команд, які мігрують з існуючої інфраструктури MySQL, де переписування запитів не є практичним
• Turso для клієнтів, які будують глобально розподілені продукти з великим навантаженням на читання, де затримка на edge є вимірюваним бізнес-показником
• Іноді чесною відповіддю є «просто використовуйте Supabase», коли вам потрібні auth + база даних + сховище в одному керованому пакеті

Потрібна допомога у виборі правильної бази даних для вашого наступного проєкту? Отримайте безкоштовну консультацію щодо бекенду.

FAQ

Чи краще Neon за PlanetScale?

Залежить від ваших потреб. Neon краще для команд, орієнтованих на Postgres, пропонує безкоштовний тариф і має глибше гілкування бази даних із семантикою copy-on-write. PlanetScale краще для навантажень MySQL корпоративного масштабу з шардуванням Vitess та deploy requests без простою. Оскільки PlanetScale тепер також пропонує Postgres, розрив звужується, але Postgres від Neon більш зрілий.

У чому різниця між Neon та Turso?

Neon — це serverless PostgreSQL із розділенням обчислень і сховища та миттєвим гілкуванням. Turso — це база на основі SQLite (libSQL) із вбудованими репліками для читання на edge. Обирайте Neon для повної екосистеми Postgres та воркфлоу гілкування. Обирайте Turso для глобального читання з низькою затримкою та архітектур «одна база даних на користувача» для мультитенантності.

Чи варто PlanetScale без безкоштовного тарифу?

Для хобі-проєктів, мабуть, ні: Neon і Turso обидва пропонують щедрі безкоштовні тарифи. Для стартапів з інвестиціями та підприємств, яким потрібне горизонтальне шардування на базі Vitess або deploy requests без простою, ціноутворення PlanetScale виправдане. Точка входу за $5/міс для Postgres конкурентна, хоча й не безкоштовна.

Яка найкраща serverless-база даних для Next.js?

Neon, для більшості розробників. Вона має найглибшу інтеграцію з Vercel (гілка на кожний прев'ю-деплой), працює з усіма ORM для Postgres і починається безкоштовно. Turso — це вибір, якщо вам конкретно потрібне глобальне читання на edge. Усі три мають драйвери, які працюють у Vercel Edge Functions.

Наскільки погані холодні старти Neon у продакшені?

Очікуйте 400–750 мс на першому запиті, коли обчислення прокидаються з нуля. Наступні запити швидкі (одиниці мс). Для додатків, які мають завжди реагувати швидко, встановіть мінімальні обчислення на 0.25 CU (приблизно $7/міс на плані Launch), щоб тримати екземпляр «теплим» і повністю усунути холодні старти.

Чи може PlanetScale тепер використовувати PostgreSQL?

Так, з вересня 2025 року. PlanetScale запустила підтримку PostgreSQL як GA, з односерверними базами даних, що починаються від $5/міс. Він готовий до продакшену, і на ньому працюють сотні компаній. Однак горизонтальне шардування для Postgres все ще в розробці; для цього вам знадобиться їхня пропозиція Vitess/MySQL.

Чи підходить Turso для продакшен-додатків?

Так, із застереженнями. Turso чудово підходить для навантажень з великим читанням та мультитенантних архітектур. Конкурентність запису значно покращилася. Він найкраще підходить для додатків із високим співвідношенням читання до запису та вимогами до глобального розподілу. Для транзакційних навантажень із великим записом краще підходять Neon або PlanetScale.

Що сталося з безкоштовним тарифом PlanetScale?

PlanetScale вилучила свій тариф Hobby (безкоштовний) у квітні 2024 року. Нові бази даних Hobby були заблоковані 6 березня 2024 року, а всі існуючі виведені з експлуатації 8 квітня 2024 року. Най дешевша точка входу тепер — $5/міс за односерверну базу даних Postgres. Це спонукало багатьох соло-розробників мігрувати на Neon або Turso.

Як придбання Databricks впливає на Neon?

Databricks придбала Neon приблизно за $1 млрд у травні 2025 року. Відтоді Neon знизила вартість сховища на 80%, інвестувала у воркфлоу AI-агентів і отримала довіру enterprise-рівня. Ціни стали дешевшими, а не дорожчими. Придбання сигналізує про довгострокову стабільність: Databricks прибуткова і віддана Neon як своєму шару Postgres.

Чи підтримує Turso все ще scale-to-zero?

Turso відмовилася від scale-to-zero для нових користувачів на початку 2025 року. Існуючі користувачі на застарілих планах зберігають цю функцію, але нові реєстрації отримують always-on екземпляри. Це усуває холодні старти, але прибирає перевагу «плати нічого, коли простоює». Edge-репліки також були припинені для нових користувачів у рамках консолідації платформи.

Яка serverless-база даних найдешевша для side project?

Neon і Turso обидва пропонують безкоштовні тарифи, які обслуговують більшість side-проєктів. Neon дає вам 0.5 ГБ сховища та 100 обчислювальних годин. Turso дає вам 5 ГБ сховища та 500 млн читань рядків. PlanetScale не має безкоштовного тарифу, мінімум — $5/міс. Для типового side-проєкту з легким трафіком будь-якого безкоштовного тарифу більш ніж достатньо.

Фінальний вердикт

Для більшості розробників у 2026 році Neon є найкращою serverless-базою даних для старту. Вона дає вам повну екосистему Postgres, безкоштовний тариф, який дійсно працює для реальних проєктів, миттєве гілкування для CI/CD та ціноутворення, яке масштабується з використанням. Підтримка Databricks додає стабільності enterprise-рівня без блокування на рівні enterprise.

PlanetScale займає своє місце, коли вам потрібне горизонтальне шардування MySQL або ваша команда вже інвестована в екосистему MySQL. Turso — правильний вибір, коли затримка на edge є вимірюваною вимогою, а не просто приємним доповненням.

Оцініть свою модель даних, траєкторію масштабування та місцезнаходження ваших користувачів. Потім оберіть один варіант і починайте будувати: усі три готові до продакшену, а екосистеми Postgres/MySQL/SQLite означають, що ви ніколи не будете справді заблоковані.

Джерела

• Огляд архітектури Neon
• Ціни Neon
• Ціни PlanetScale
• PlanetScale for Postgres тепер GA
• Ціни Turso
• Документація Turso libSQL
• Databricks погоджується придбати Neon
• Майбутні зміни платформи Turso
• PlanetScale відмовляється від плану Hobby
• Бенчмарки затримки serverless-баз даних, Pilcrow (2023)
• Drizzle ORM, підключення Turso