Neon vs PlanetScale vs Turso: Postgres, MySQL nebo SQLite na okraji sítě?

Rozhodnutí mezi Neon vs PlanetScale vs Turso se v podstatě scvrkává na tři zásadně odlišné sázky: Postgres, MySQL/Vitess a SQLite na okraji sítě (edge). Během posledního roku se situace dramaticky změnila – Databricks akvizicí získaly Neon za ~1 miliardu dolarů, PlanetScale spustil podporu Postgresu a Turso ukončil funkci scale-to-zero. Pokud vybíráte serverless databázi pro rok 2026, pravděpodobně jsou všechny doposud přečtené srovnání zastaralé.

Neon vs PlanetScale vs Turso v rychlém přehledu

Zvolte Neon, pokud chcete plnou kompatibilitu s Postgresem, štědrý bezplatný tarif a nejlepší integraci s Vercel. Zvolte PlanetScale, pokud potřebujete MySQL v enterprise měřítku s horizontálním shardingem. Zvolte Turso, pokud je pro vás klíčová latence na okraji sítě a architektury s oddělenou databází pro každého uživatele (multi-tenant).

To byla rychlá verze. Zbytek tohoto článku podrobně rozebírá, proč každá buňka vypadá právě takto.

Jak jednotlivé databáze fungují pod kapotou?

Engine každé platformy ovlivňuje vše od syntaxe dotazů až po limity škálování. Pochopení architektury vám pomůže předpovědět chování každé z nich při růstu vaší aplikace.

Neon: Serverless Postgres s větvením

Neon zcela odděluje výpočetní výkon od úložiště. Vaše výpočetní uzly Postgresu jsou efemérní – spustí se, když dorazí dotaz, a při nečinnosti se škálují dolů (nebo až na nulu). Úložiště běží na samostatné vrstvě pageserver, která zajišťuje trvanlivost dat a obnovení do konkrétního bodu v čase.

Tato architektura umožňuje klíčovou funkci Neonu: větvení typu copy-on-write. Vytvoření větve databáze je téměř okamžité bez ohledu na velikost, protože se data nekopírují, ale sdílejí stránky úložiště s rodičovskou databází a nové stránky se zapisují pouze při změně dat. Představte si to jako git branch pro vaši databázi.

• Plný protokol PostgreSQL wire (pg_dump, psql, vše funguje)
• Automatické škálování výpočetního výkonu od 0,25 do 56 CU
• Vestavěné poolování připojení přes PgBouncer
• Architektura Neonu využívá safekeepery pro trvanlivost write-ahead logu

PlanetScale: MySQL poháněné Vitess (a nyní i Postgres)

PlanetScale běží na Vitess, clusteringovém enginu pro MySQL, který původně vyvinulo YouTube pro shardování své databáze napříč desítkami tisíc uzlů. Pokud potřebujete horizontální škálování pro MySQL, Vitess je nejvíce prověřeným řešením, jaké existuje.

Signature funkcí DX u PlanetScale jsou deploy requesty, což jsou v podstatě pull requesty pro změny schématu. Navrhnete migraci, zkontrolujete diff a aplikujete ji bez výpadku. Žádné zamykání, žádná okna údržby.

Od září 2025 nabízí PlanetScale také spravovaný Postgres. Jde o odlišný produkt od jejich nabídky Vitess, přičemž single-node databáze Postgres začínají na 5 USD/měsíc. Horizontální shardování pro Postgres (nazývané „Neki“) je stále ve vývoji.

Pro hlubší ponor do toho, kdy má Postgres větší smysl než MySQL (a naopak), se podívejte na naše srovnání PostgreSQL vs MySQL.

• Vitess: horizontální shardování, migrace schémat bez výpadků
• Postgres: single-node, připraveno pro produkci, ale zatím bez shardování
• Deploy requesty pro bezpečné a kontrolovatelné změny schématu
• Žádné scale-to-zero, databáze běží neustále

Turso: SQLite na okraji sítě s libSQL

Turso zvolilo zcela odlišný přístup. Místo provozování databáze založené na serveru používá libSQL, open-source fork SQLite s možnostmi serverového režimu. Vaše data mohou žít na okraji sítě, doslova vložená do runtime prostředí vaší aplikace.

Klíčovým konceptem jsou embedded repliky: čtecí repliky, které běží uvnitř procesu vaší aplikace (nebo na edge lokacích) s nulovou síťovou latencí při čtení. Zápisy směřují na primární instanci a asynchronně se propagují do replik.

• libSQL rozšiřuje SQLite o HTTP přístup, replikaci a multi-tenancy
• Model databáze pro každého uživatele podporuje tisíce izolovaných databází
• Zápisy se z primární instance do replik propagují v řádu milisekund
• Ideální pro aplikace náročné na čtení a globálně distribuované

Verdikt: Neon vítězí v šíři architektury. Plnohodnotný Postgres s okamžitým větvením pokrývá nejširší spektrum use caseů. PlanetScale vítězí, pokud specificky potřebujete horizontální shardování na úrovni Vitess. Turso vítězí, pokud potřebujete data na okraji sítě.

Jak si stojí v porovnání výkonu a latence?

Výkon je první otázka, kterou si vývojáři kladou, a odpověď závisí zcela na tom, zda je vaše databáze „teplá“ nebo „studená“.

Realita studených startů

Neon je jediný ze tří, který stále standardně provádí scale-to-zero. Když se váš výpočetní uzel probudí z nečinnosti, očekávejte u prvního dotazu 400–750 ms. Následující dotazy jsou rychlé. Studené starty můžete eliminovat nastavením minimální velikosti výpočetního výkonu (0,25 CU stojí zhruba 7 USD/měsíc).

PlanetScale byl vždy always-on, žádné studené starty, tečka. Vaše databáze běží, ať ji někdo dotazuje, nebo ne.

Turso ukončil podporu scale-to-zero pro nové uživatele v lednu 2025. Noví uživatelé dostávají always-on instance, což znamená žádné studené starty, ale také žádné úspory typu „plaťte nic, když je nečinnost“.

Edge latence: Kde Turso vyniká

U „horkých“ dotazů jsou všechny tři rychlé. Ale embedded repliky Turso poskytují něco, co ostatní dva nemohou: čtení v řádu jednotek milisekund na okraji sítě. Když vaše SQLite replika žije ve stejném Cloudflare Workeru nebo Vercel Edge Function jako váš kód, při čtení nedochází k žádnému síťovému skoku.

Benchmark data od Pilcrow (červenec 2023 – berte jako orientační, nikoliv aktuální) ukázala u centralizovaných dotazů PlanetScale HTTP na ~8 ms, Neon HTTP na ~5 ms a Turso HTTP na ~27 ms. Nezávislé benchmarky na Cloudflare Workers potvrdily podobné vzorce. Tato čísla předcházejí spuštění Postgresu na PlanetScale a změnám infrastruktury Turso, takže je berte spíše jako referenční body než jako dogma.

Verdikt: Turso vítězí v edge latenci. Embedded repliky s čtením bez síťových skoků jsou nepřekonatelné. Pro centralizované workloady bez obav ze studených startů je těžké porazit konzistenci always-on řešení PlanetScale. Studené starty Neonu jsou kompromisem za úspory díky scale-to-zero.

Kolik každá databáze skutečně stojí?

Zde většina srovnání selhává – uvádějí ceny plánů, aniž by vypočítali, kolik by zaplatila reálná aplikace. Pojďme to napravit.

Rozbor bezplatných tarifů

PlanetScale zrušil svůj bezplatný Hobby tarif v dubnu 2024. Nejlevnější vstupní bod je nyní 5 USD/měsíc za single-node databázi Postgres. Pro databáze Vitess/MySQL je cenotvorba založena na clustrech a výrazně vyšší.

Reálné měsíční náklady ve čtyřech úrovních škálování

Tyto odhady využívají aktuální ceny pro rok 2026 z oficiálních ceníků každé platformy. Skutečné náklady se liší podle vzorců využití.

Několik věcí hned bije do očí. Turso je pozoruhodně levný v nižších a středních úrovních, protože jeho model cenování založený na čtení řádků zvýhodňuje aplikace náročné na čtení. Cenotvorba Neonu založená na využití znamená, že platíte pouze za to, co spotřebujete – nečinné databáze na bezplatném tarifu nic nestojí. Ceny PlanetScale jsou konkurenceschopné pro single-node Postgres, ale s clustery Vitess rostou.

Cenový zlom PlanetScale

Největší slabina PlanetScale pro solo vývojáře: neexistuje žádný bezplatný tarif. Přecházíte z 0 USD (používáním konkurence) na minimum 5 USD/měsíc. Pro financované startupy je to irelevantní, ale pro vedlejší projekty a prototypování jsou bezplatné tarify Neon a Turso významně lepší.

Na druhou stranu nabídka Vitess od PlanetScale poskytuje horizontální shardování, kterému se Neon ani Turso nemohou rovnat. Pokud vaše propustnost zápisů vyžaduje shardování, je prémiová cena oprávněná.

Verdikt: Neon vítězí pro většinu rozpočtů. Bezplatný tarif plus cenotvorba založená na využití je nejflexibilnější model. Cenotvorba Turso založená na čtení řádků je vynikající pro aplikace náročné na čtení. PlanetScale stojí na nižších úrovních více, ale dodává enterprise-grade škálování.

Jaká je zkušenost vývojáře (DX)?

Denní DX je důležitější než čísla z benchmarků. Zde je srovnání tří platforem podle funkcí, které budete skutečně používat.

Větvení databáze a CI/CD

Větvení typu copy-on-write od Neonu je zlatým standardem. Vytvořte větev pro každý PR, spusťte proti ní migrace, testujte s daty podobnými produkčním a sloučte. Integrace s Vercel automaticky vytváří větev pro každé preview nasazení.

Deploy requesty od PlanetScale jsou jinou chuťovkou stejného nápadu. Místo větvení celé databáze větvíte schéma. Navrhnete migraci, zkontrolujete diff a aplikujete ji bez výpadku. Je to více opinionated, ale arguably bezpečnější pro změny schématu ve velkém měřítku.

Turso nemá větvení. Migrace spravujete pomocí standardních nástrojů pro SQLite.

Matice kompatibility ORM

Neon a nabídka Postgresu od PlanetScale fungují out-of-the-box s celým ekosystémem Postgres ORM. Turso vyžaduje adaptéry specifické pro libSQL, které jsou dobře udržované, ale mají užší záběr.

CLI a lokální vývoj

Všechny tři mají solidní CLI: neonctl pro Neon, pscale pro PlanetScale a turso pro Turso. Každé podporuje vytváření databází, správu větví (kde je to applicable) a připojení z terminálu.

Pro lokální vývoj vynikají větve Neonu – můžete vyvíjet proti větvi, která zrcadlí produkční data, aniž byste sahali na produkci. Vývojové větve PlanetScale slouží podobnému účelu. Turso běží lokálně na SQLite, takže lokální vývoj je mrtvě jednoduchý – stačí mířit na lokální soubor .db.

Verdikt: Neon vítězí ve zkušenosti vývojáře. Větvení typu copy-on-write s integrací Vercel je nejlepší příběh pro CI/CD. Deploy requesty PlanetScale jsou vynikající pro týmy, které chtějí revizi na úrovni schématu. Jednoduchost Turso je nedoceněná, ale postrádá větvení.

Připojení z Next.js, kód vedle sebe

Zde je ukázka, jak vypadá připojení ke každé databázi z API route nebo Server Component v Next.js. Tyto úryvky jsou ready-to-use.

Připojení přes raw driver (všechny tři)

Neon s @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 s @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 s @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;
}

Všimněte si, že Turso používá = 1 místo = true, protože SQLite nemá nativní boolean typ. Malý rozdíl, ale často lidi zaskočí.

Nastavení Drizzle ORM (všechny tři)

Pokud používáte Drizzle (a pravděpodobně byste měli pro type-safe dotazy), zde je konfigurace pro každou z nich:

// 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);

Všechny tři drivery fungují ve Vercel Edge Functions a Cloudflare Workers. Povrch API je dostatečně podobný na to, aby přepínání mezi nimi bylo mostly swap driveru – vaše schéma a dotazy Drizzle zůstávají stejné (minus rozdíly v SQL dialektech).

Můžete používat více serverless databází dohromady?

Zde je vzor, který v komunitě získává na popularitě, ale o kterém žádné srovnávací články nemluví: použití Turso pro čtení na edge a Neon pro zápisy.

Myšlenka je přímočará. Vaše primární data žijí v Neonu (plný Postgres, silná konzistence, bohatá podpora dotazů). Data náročná na čtení replikujete do edge replik Turso, které sedí blízko vašich uživatelů globálně. Čtení míří do Turso s latencí pod milisekundu; zápisy jdou do Neonu pro trvanlivost a konzistenci.

Kdy to dává smysl:

• Globálně distribuované aplikace, kde záleží na latenci čtení (dashboardy, content platformy)
• Multi-tenant SaaS, kde data každého tenantu náročná na čtení benefitují z edge cachování
• Aplikace s poměrem čtení/zápis 90/10, kde můžete tolerovat mírně zastaralá čtení

Kdy to přeskočit:

• Většina aplikací nepotřebuje globální čtení pod 10 ms, single-region instance Neonu stačí
• Složitost udržování dvou databází, synchronizace dat a řešení selhání je reálná
• Pokud je vaše aplikace náročná na zápisy, edge čtení příliš nepomohou

Buďte k sobě upřímní: pokud neprovozujete globální měřítko s přísnými požadavky na latenci, přidáváte složitost bez smysluplného benefitu. Ale pro aplikace, které to potřebují, je to genuinely elegantní vzor.

Co se změnilo v letech 2025–2026? (Tři velké otřesy)

Každé srovnání konkurentů bylo napsáno před těmito událostmi. Zde je přehled toho, co se změnilo a co to znamená pro vaše dnešní rozhodování.

Neon + Databricks: Co znamená akvizice za 1 miliardu dolarů

V květnu 2025 Databricks akvizicí získaly Neon za přibližně 1 miliardu dolarů. Nebyla to jen finanční událost, změnila trajektorii Neonu.

Okamžitý dopad: Neon snížil náklady na úložiště o 80 % (z 1,75 na 0,35 USD za GB-měsíc). Analýza Vantage naznačuje, že to částečně plyne z objemových slev AWS pro Databricks, které se přelily k zákazníkům Neonu.

Strategický signál: Databricks uvedly, že 80 % databází Neon je nyní vytvářeno AI agenty, nárůst z 30 % při GA. Neon se positioninguje jako defaultní databáze pro vývoj řízený AI, automatizované vytváření schémat, data spravovaná agenty a programatické provisionování databází.

Pro vás jako vývojáře znamená akvizice: levnější ceny, enterprise backing (Databricks jsou ziskové) a roadmapu stále více optimalizovanou pro programatické/AI workflow.

PlanetScale Postgres: MySQL již není jedinou možností

V září 2025 PlanetScale spustil podporu Postgresu jako GA. To zcela mění staré rámování „Neon = Postgres, PlanetScale = MySQL“.

PlanetScale Postgres začíná na 5 USD/měsíc pro single-node databáze s funkcemi jako Query Insights, doporučení schémat a větvení. Je připraveno pro produkci a již ho provozují stovky společností. Horizontální shardování pro Postgres (jejich projekt „Neki“) je však stále ve vývoji.

Co to znamená: pokud vybíráte mezi Neon vs PlanetScale čistě na základě preference engine, PlanetScale nyní pokrývá obojí. Ale Postgres od Neonu je zralější (byl Postgres-native od prvního dne), má bezplatný tarif a nabízí hlubší větvení s semantikou copy-on-write. PlanetScale Postgres stojí za sledování, ale Neon stále vede na straně Postgresu.

Turso ruší Scale-to-Zero: Ve výchozím nastavení Always-On

V lednu 2025 Turso oznámilo významné změny platformy: scale-to-zero ukončeno pro nové uživatele, konsolidace infrastruktury na AWS a edge repliky ukončeny pro nové registrace.

Kompromis je jasný: žádné další studené starty (dobré), ale žádné další úspory typu „zdarma při nečinnosti“ (méně dobré). Stávající uživatelé na legacy plánech si zachovávají scale-to-zero, ale všichni ostatní dostávají always-on instance.

To činí Turso předvídatelnějším – nebudete překvapeni latencí studeného startu, ale také to zužuje mezera mezi Turso a PlanetScale v dimenzi „serverless“. Obě jsou nyní always-on spravované databáze; to, co odlišuje Turso, je jeho edge příběh.

Neon vs PlanetScale vs Turso: Kterou si vybrat?

Dost analýzy. Zde je rozhodovací rámec.

Pro většinu vývojářů začínajících nový projekt v roce 2026 je Neon defaultní volbou. Bezplatný tarif, plný Postgres, okamžité větvení a integrace s Vercel pokrývají 80 % use caseů. Vždy můžete přejít na placené plány nebo později switchovat – ekosystém Postgres znamená, že nikdy nejste truly locked in.

PlanetScale si zaslouží své místo, když potřebujete MySQL v enterprise měřítku nebo chcete workflow deploy requestů pro změny schémat bez výpadků napříč velkými týmy.

Turso je správná volba, když vaše architektura vyžaduje edge-first přístup k datům nebo izolaci multi-tenant databází ve velkém měřítku. Je to specializovaný nástroj a je vynikající v tom, v čem se specializuje.

Jak Techsy přistupuje k výběru serverless databáze

Hodnotíme serverless databáze ve čtyřech dimenzích pro každý klientský projekt: složitost datového modelu, velikost týmu a preference SQL dialektu, trajektorie škálování v příštích 12–18 měsících a deployment platforma (Vercel, Cloudflare, AWS atd.).

Naším defaultním stackem pro většinu projektů je Neon + Drizzle + Next.js. Zde je proč:

1. Postgres nám dává nejbohatší ekosystém: JSON sloupce, full-text search, PostGIS, extensions
2. Větvení Neonu perfektně mapuje na preview nasazení a CI pipeline
3. Bezplatný tarif nám umožňuje prototypovat bez billing overheadu pro early-stage klienty
4. Type safety Drizzle zachytí schema drift dříve, než se dostane do produkce

Kdy doporučujeme alternativy:

• PlanetScale pro týmy migrující z existující MySQL infrastruktury, kde není praktické přepisovat dotazy
• Turso pro klienty budující globálně distribuované produkty náročné na čtení, kde je edge latence měřitelnou business metrikou
• Někdy je upřímná odpověď „prostě použijte Supabase“, když potřebujete auth + databázi + storage v jednom spravovaném balíčku

Potřebujete pomoct vybrat správnou databázi pro váš další projekt? Získejte bezplatnou konzultaci backendu.

FAQ

Je Neon lepší než PlanetScale?

Záleží na vašich potřebách. Neon je lepší pro týmy native na Postgres, nabízí bezplatný tarif a má hlubší větvení databáze s semantikou copy-on-write. PlanetScale je lepší pro MySQL workloady v enterprise měřítku s Vitess shardingem a deploy requesty bez výpadků. Protože PlanetScale nyní nabízí i Postgres, mezera se zužuje, ale Postgres od Neonu je zralější.

Jaký je rozdíl mezi Neon a Turso?

Neon je serverless PostgreSQL s oddělením výpočtu a úložiště a okamžitým větvením. Turso je založen na SQLite (libSQL) s embedded replikami pro čtení na edge. Zvolte Neon pro plný ekosystém Postgres a workflow s větvením. Zvolte Turso pro globální čtení s nízkou latencí a architektury multi-tenant databáze pro každého uživatele.

Stojí PlanetScale za to i bez bezplatného tarifu?

Pro hobby projekty pravděpodobně ne, Neon i Turso nabízejí štědré bezplatné tarify. Pro financované startupy a enterprise, které potřebují horizontální shardování poháněné Vitess nebo deploy requesty bez výpadků, je cena PlanetScale oprávněná. Vstupní bod Postgres za 5 USD/měsíc je konkurenceschopný, although not free.

Jaká je nejlepší serverless databáze pro Next.js?

Neon, pro většinu vývojářů. Má nejhlubší integraci s Vercel (větev pro každé preview nasazení), funguje se všemi Postgres ORM a začíná zdarma. Turso je volbou, pokud specificky potřebujete globální čtení na edge. Všechny tři mají drivery, které fungují ve Vercel Edge Functions.

Jak špatné jsou studené starty Neonu v produkci?

Očekávejte 400–750 ms u prvního dotazu, když se výpočet probudí z nuly. Následující dotazy jsou rychlé (jednotky ms). Pro aplikace, které musí vždy reagovat, nastavte minimální výpočet na 0,25 CU (zhruba 7 USD/měsíc na plánu Launch), abyste instanci udrželi teplou a zcela eliminovali studené starty.

Může PlanetScale nyní používat PostgreSQL?

Ano, od září 2025. PlanetScale spustil podporu PostgreSQL jako GA, se single-node databázemi začínajícími na 5 USD/měsíc. Je připraveno pro produkci a běží na něm stovky společností. Horizontální shardování pro Postgres je však stále ve vývoji, pro to budete potřebovat jejich nabídku Vitess/MySQL.

Je Turso dobré pro produkční aplikace?

Ano, s caveatami. Turso vyniká u workloadů náročných na čtení a multi-tenant architektur. Konkurenčnost zápisů se výrazně zlepšila. Nejlépe vyhovuje aplikacím s vysokým poměrem čtení/zápis a požadavky na globální distribuci. Pro transakční workloady náročné na zápisy jsou lepší volbou Neon nebo PlanetScale.

Co se stalo s bezplatným tarifem PlanetScale?

PlanetScale odstranil svůj Hobby (bezplatný) tarif v dubnu 2024. Nové Hobby databáze byly blokovány 6. března 2024 a všechny stávající byly vyřazeny 8. dubna 2024. Nejlevnější vstupní bod je nyní 5 USD/měsíc za single-node databázi Postgres. To přimělo mnoho solo vývojářů k migraci na Neon nebo Turso.

Jak ovlivnila akvizice Databricks Neon?

Databricks akvizicí získaly Neon za ~1 miliardu USD v květnu 2025. Od té doby Neon snížil náklady na úložiště o 80 %, investoval do workflow AI agentů a získal enterprise kredibilitu. Ceny se staly levnějšími, ne dražšími. Akvizice signalizuje dlouhodobou stabilitu – Databricks jsou ziskové a committed k Neonu jako jejich Postgres vrstvě.

Podporuje Turso stále scale-to-zero?

Turso ukončil scale-to-zero pro nové uživatele na začátku roku 2025. Stávající uživatelé na legacy plánech si jej zachovávají, ale noví uživatelé dostávají always-on instance. To eliminuje studené starty, ale odstraňuje výhodu „plaťte nic při nečinnosti“. Edge repliky byly také ukončeny pro nové uživatele jako součást konsolidace platformy.

Která serverless databáze je nejlevnější pro vedlejší projekt?

Neon a Turso obě nabízejí bezplatné tarify, které pokryjí většinu vedlejších projektů. Neon vám dá 0,5 GB úložiště a 100 výpočetních hodin. Turso vám dá 5 GB úložiště a 500 milionů čtení řádků. PlanetScale nemá žádný bezplatný tarif, minimum je 5 USD/měsíc. Pro typický vedlejší projekt s lehkým provozem je kterýkoli z bezplatných tarifů více než dostatečný.

Finální verdikt

Pro většinu vývojářů v roce 2026 je Neon nejlepší serverless databází, se kterou začít. Dává vám plný ekosystém Postgres, bezplatný tarif, který skutečně funguje pro reálné projekty, okamžité větvení pro CI/CD a ceny, které škálují s využitím. Podpora Databricks přidává enterprise stabilitu bez enterprise lock-in.

PlanetScale si zaslouží své místo, když potřebujete horizontální MySQL sharding nebo je váš tým již investován do ekosystému MySQL. Turso je správná volba, když je edge latence měřitelným požadavkem, nejen nice-to-have.

Zhodnoťte svůj datový model, trajektorii škálování a kde jsou vaši uživatelé. Pak si jednu vyberte a začněte stavět – všechny tři jsou production-ready a ekosystémy Postgres/MySQL/SQLite znamenají, že nikdy nejste truly locked in.

Zdroje

• Přehled architektury Neon
• Ceník Neon
• Ceník PlanetScale
• PlanetScale for Postgres Is Now GA
• Ceník Turso
• Dokumentace Turso libSQL
• Databricks Agrees to Acquire Neon
• Upcoming Changes to the Turso Platform
• PlanetScale Deprecating the Hobby Plan
• Serverless Database Latency Benchmarks, Pilcrow (2023)
• Drizzle ORM, Connect Turso