Neon, nebo Supabase: latence remíza, škálování už ne

Pro SaaS, který potřebuje hlavně spravovaný PostgreSQL a mezi požadavky mívá dlouhé pauzy, je silnou volbou Neon. Jeho výpočetní kapacita se může při nečinnosti uspávat a databázové větve přebírají data. Supabase má smysl posuzovat jako celý backend: vedle databáze nabízí Auth, Storage a Realtime, jejichž hodnota může převážit rozdíl v ceně samotného PostgreSQL.

Rychlost jednoduchého dotazu v dostupném srovnání vítěze neurčila. Rozhodnutí mění chování při probuzení databáze, změně kapacity a vytváření větví. Do účtu pak vstupuje doba běhu výpočetní kapacity, uložená data, počet prostředí a skutečné využití dalších služeb.

Stejná latence dotazu neznamená stejný provoz

Veřejný benchmark DevOps Daily naměřil u obou platforem medián přibližně 32 ms pro nové připojení, TLS, autentizaci a jednoduchý dotaz. Projekty běžely v oblasti AWS eu-central-1, klient ve Frankfurtu; zveřejněné jsou postup i jednotlivé vzorky. Jde tedy o latenci celého tohoto cyklu v konkrétním umístění, nikoli o obecný čas libovolného produkčního SQL dotazu.

První dotaz na uspáný Neon měl v testu medián 593,2 ms. U nepravidelného provozu je to možná cena za úsporu výpočetního času během pauzy, kterou pocítí právě požadavek probouzející databázi. Placený projekt Supabase udržuje výpočetní instanci v běhu, takže v tomto srovnání neměl stejný typ probuzení. Nejde o tvrzení, že všechny jeho požadavky budou rychlejší: měřily se různé provozní situace.

Ještě důležitější rozdíl přinesla testovaná změna kapacity. SQL sondy při přenastavení Supabase selhávaly přibližně 39 sekund; při změnách na Neonu benchmark nezaznamenal neúspěšnou sondu. Výsledek se vztahuje na zkoušené konfigurace a způsob změny výkonu. Pro aplikaci, která musí přijímat zápisy i při růstu zátěže, je toto chování podstatnější než téměř shodný medián připojení a jednoduchého dotazu; samo měření však není příslibem bezvýpadkovosti každého zásahu.

Větve: stejný název, jiný obsah

Neon vytváří zapisovatelnou větev nad existujícím stavem schématu i dat pomocí sdíleného úložiště. V benchmarku byla větev s rodičovskými 100 tisíci řádky připravena přibližně za 1,7 sekundy. To je užitečné při zkoušce migrace nad stavem blízkým hlavní databázi: změny ve větvi zůstávají oddělené, zatímco výchozí data jsou ihned dostupná. Vytvoření větve přitom samo o sobě neznamená uložení další plné kopie všech rodičovských dat.

Testovaná větev Supabase vznikla přibližně za 6,2 sekundy a obsahovala schéma bez řádků. Pokus zahrnout data na novém projektu narazil na chybějící fyzickou zálohu. Tyto časy proto neporovnávají dvě totožné kopie: jedna větev už nesla data, druhá byla připravena pro vlastní testovací naplnění. Schéma bez produkčních řádků může být naopak vhodné tam, kde tým potřebuje izolované prostředí a data do něj vkládá řízeně.

Rozdíl se promítá i do práce s náhledy změn. Větev Neonu umožní rychle prověřit dotazy a migrace nad existujícím datasetem, ale ponechaná větev může dál spotřebovávat kapacitu a ukládat vlastní změny. Supabase poskytuje pro větev širší oddělené prostředí, takže jeho přínos roste, má-li náhled zahrnovat také související backendové služby. Náklady a použitelnost větve tak závisejí na tom, co má test skutečně obsahovat.

PostgreSQL je jen část backendu

Supabase spojuje databázi s přihlašováním uživatelů, ukládáním souborů a živými aktualizacemi. Pro nový produkt může být společné provozování těchto částí cennější než nižší databázová sazba jinde. Jestliže však aplikace používá vlastní autentizaci, soubory ukládá u jiného poskytovatele a Realtime nepotřebuje, je potřeba porovnat především databázový provoz a nikoli započítávat nevyužité služby jako úsporu.

Neon mezitím rozšířil nabídku o Managed Better Auth, Object Storage a Functions. Rozdíl mezi platformami tedy nelze zjednodušit na volbu „databáze, nebo backend“. Liší se konkrétní služby, jejich zapojení do aplikace a způsob účtování. Pro tým, který si vybírá spravovaný PostgreSQL, je užitečné oddělit cenu výpočtu a uložení databázových dat od hodnoty Auth, Storage a Realtime; teprve součet odpovídá skutečnému projektu.

Model českého SaaS: kdy se mění pořadí cen

Ceník Neonu uvádí u tarifu Launch sazbu 0,106 USD za CU-hodinu a 0,35 USD za GB databázových dat za měsíc. Tarif účtuje využití bez pevného měsíčního paušálu. Uspání zastaví spotřebu databázového výpočtu, nikoli účtování uložených dat. Další položky mohou vzniknout za uchovávanou historii změn, větve nad zahrnutý počet, přenosy nebo doplňkové služby; výpočetní čas Functions není totožný s databázovými CU-hodinami.

Ceník Supabase uvádí tarif Pro od 25 USD měsíčně, měsíční kredit 10 USD na výpočetní kapacitu, 8 GB databázového prostoru na projekt a cenu 0,125 USD za každý další GB. Kredit pokryje jednu instanci Micro; další projekt přidává vlastní výpočetní kapacitu. Pro srovnání větší instance Medium stojí 60 USD měsíčně a má 4 GB paměti, zatímco Micro má 1 GB. Vedle databáze mají své zahrnuté objemy a případné příplatky také přenos dat, soubory a uživatelé Auth.

U čistě ilustrativního českého SaaS předpokládejme jednu databázi o 25 GB, měsíc o třiceti dnech a Neon o velikosti 1 CU, který skutečně běží šest hodin denně. Výsledných 180 CU-hodin stojí 19,08 USD a uložení dat 8,75 USD, celkem 27,83 USD před dalšími položkami. Při nepřetržitém běhu by za stejný měsíc samotný výpočet a úložiště Neonu vyšly na 85,07 USD. Jde o aritmetiku z uvedených sazeb, nikoli o změřenou zátěž konkrétní aplikace.

U Supabase by při stejném předpokladu 25 GB účtovaného databázového prostoru, jednom projektu Pro a instanci Micro vyšel základ včetně prostoru nad limit na přibližně 27,13 USD měsíčně. S instancí Medium by po započtení měsíčního kreditu činil přibližně 77,13 USD. Micro ovšem nemá stejnou paměť jako 1 CU Neonu; ani podobná kapacita paměti u Medium nedokazuje shodný výkon procesoru či dotazů. Tyto částky ukazují, proč samotný název tarifu nestačí k výběru.

Kalkulace FluentDB s cenami ověřenými 1. srpna 2026 označila Neon za levnější ve všech svých referenčních bodech a pro nepřetržitý provoz s 25 GB uvádí u Supabase 87,13 USD. Proti uvedenému modelu Pro s Medium je to rozdíl 10 USD, tedy hodnota měsíčního kreditu na výpočet, který oficiální ceník zahrnuje. Při rozhodování proto nelze její pořadí převzít bez kontroly započteného kreditu; model navíc nezahrnuje všechny možné náklady na zálohy, podporu a přenosy.

Účet určují měřiče spotřeby

Neon dovoluje sledovat víc než počet projektů. API pro spotřebu projektu vrací mimo jiné výpočetní sekundy, uložená data hlavní a vedlejších větví, objem dat pro okamžité obnovení, síťový přenos a dodatečné větve. Historie začíná přechodem na způsobilý tarif. Právě tato kombinace ukáže, zda plánovanou úsporu z uspávání nepohlcuje trvalá aktivita, dlouho ponechaná větev nebo rostoucí úložiště.

U Supabase je vedle velikosti produkční instance třeba počítat i s dalšími běžícími projekty a spotřebou služeb nad zahrnuté objemy. Pro nepravidelný čistě databázový provoz a testy nad převzatými daty vychází z popsaných mechanismů lépe Neon. Když aplikace soustavně běží a používá integrované Auth, Storage a Realtime, může rozhodnout celková cena backendu a práce, kterou tým díky těmto službám ušetří.

Přečtěte si také:

• Supabase, nebo Firebase: levný začátek může skrýt drahé čtení dat
• Notion, nebo Confluence: pružnost databází naráží na správu ve velkém
• PostgreSQL, nebo MySQL: jeden benchmark vítěze databáze neurčí