Supabase recenze: skvělý backend, pokud respektujete databázi

Moje Supabase recenze začala příjemně: za chvíli jsem měl PostgreSQL databázi, API i první dashboard. Pak jeden Free projekt usnul a připomněl mi, že rychlý start není totéž co bezúdržbový provoz. Po zkušenostech s databázemi pro AI Kruh i reporting Váš hosting je můj verdikt jednoduchý: Supabase je výborný backend, pokud rozumíš datům, RLS a tomu, za co na produkci platíš.

Nejvíc z něj vytěžíš, když hledáš backend pro relační SaaS nebo reporting, ne kouzelné tlačítko místo databázového návrhu. Proto hodnotím nejen funkce, ale i Supabase cenu, bezpečnost, provozní limity a alternativy. Na konci budeš vědět, zda se rychlejší vývoj vyplatí právě pro tvůj typ aplikace a očekávaný provoz.

1. Co je Supabase a pro koho podle mě skutečně je

Nejkratší užitečná definice zní: Supabase je spravovaný backend postavený kolem dedikované PostgreSQL databáze. Ke každému projektu přidává Auth, Storage, Realtime, Edge Functions a automaticky generované API. Nemusíš tedy zvlášť skládat databázi, přihlášení uživatelů, úložiště souborů a serverovou logiku.

Tohle je důležitější než oblíbená nálepka „open-source alternativa Firebase“. Firebase staví hlavně na dokumentovém modelu, zatímco Supabase začíná relační databází a SQL. Pokud máš zákazníky, objednávky, členství, události nebo metriky, které se mezi sebou přirozeně propojují, PostgreSQL bývá čitelnější základ pro aplikaci i reporting.

Supabase mi dává největší smysl pro:

• MVP a menší SaaS, kde chceš rychle dodat login, data a soubory,
• klientské portály s oddělenými účty nebo tenanty,
• dashboardy nad několika datovými zdroji,
• interní nástroje, které mohou časem vyrůst nad jednoduchý CRUD.

Pro běžný prezentační WordPress web je naopak často zbytečně široký. Pokud řešíš tvorbu webu a webové aplikace, rozhoduje hlavně povaha dat: web s několika formuláři Supabase nepotřebuje, datová aplikace s uživatelskými účty už z něj může těžit výrazně.

Nevolil bych ho jen proto, že nechceš spravovat server. Pro čistě serverovou aplikaci bez uživatelského přihlášení, souborů a realtime funkcí může být obyčejný managed Postgres jednodušší na pochopení i provoz. Supabase vyhrává tehdy, když opravdu využiješ několik částí jeho balíku.

Tahle Supabase recenze proto není doporučení pro každého. Je pro člověka, který chce hotové backendové služby, ale zároveň přijímá, že databázový návrh, migrace a bezpečnost za něj platforma nevymyslí.

2. PostgreSQL jako hlavní důvod, proč Supabase dává smysl

Největší předností Supabase není pěkný dashboard, ale standardní relační databáze PostgreSQL pod ním. Díky tomu nejsi zavřený v exotickém datovém modelu a můžeš používat tabulky, vztahy, constraints, indexy, views, SQL funkce i RPC.

To začne být cenné ve chvíli, kdy projekt přeroste první obrazovku s formulářem. U AI Kruhu lze například ingestovat data z Circle a Benta, spojit člena s jeho aktivitou a nad výsledkem vytvořit pohled pro dashboard. U reportingu Váš hosting se podobně potkávají data z Google Search Console a Usermavenu. Místo volání několika externích API pak každý dashboard čte jednu normalizovanou datovou vrstvu.

Supabase nad databází automaticky vystaví API. Jednoduché čtení a zápis tedy zvládneš bez ruční tvorby každého endpointu. Složitější výpočty lze přesunout do view nebo PostgreSQL funkce a volat je přes RPC. Logika zůstane blízko dat a stejný výsledek mohou používat dashboard, interní nástroj i automatizace.

Constraints hlídají kvalitu už při zápisu. Cizí klíč nepustí osiřelý záznam, unikátní index zabrání duplicitě a transakce udrží několik souvisejících změn pohromadě. Tyto nenápadné databázové vlastnosti mají pro dlouhodobý provoz větší cenu než efektní demo realtime tabulky.

PostgreSQL zároveň neodpustí špatný návrh. Pokud nacpeš vše do jedné tabulky, vynecháš omezení nebo upravuješ schéma ručně bez migrací, Supabase ti jen umožní udělat chybu rychleji. Pro produkci proto vytvářím změny schématu opakovatelnými migracemi a zásadní transformace držím v SQL, ne v náhodné logice několika klientů.

Právě tady jsou moje Supabase zkušenosti nejlepší. Platforma zrychlí rutinu, ale data zůstávají v technologii s obrovským ekosystémem nástrojů a znalostí. Proti proprietárnímu backendu je to podstatná pojistka.

3. Auth a RLS: největší výhoda i největší zdroj chyb

Nejnebezpečnější chyba v Supabase nemusí jako chyba vypadat. Dotaz může vrátit prázdný výsledek, protože ho zastavila policy, nebo zpřístupnit cizí řádky, protože Row Level Security nebylo správně zapnuté. Auth a RLS proto hodnotím zároveň jako nejsilnější vlastnost i největší učicí křivku platformy.

Supabase Auth identifikuje uživatele. RLS pak v PostgreSQL rozhodne, které řádky smí daná identita číst, vložit, změnit nebo smazat. U klientského portálu tak můžeš vynutit podmínku, že uživatel vidí pouze záznamy svého účtu, přímo u datového zdroje. Ochrana nezávisí jen na tom, zda frontend správně skryje tlačítko.

Samotné zapnutí RLS nestačí. PostgreSQL nejdřív vyhodnotí oprávnění GRANT a potom příslušné policies. Zvláštní pozornost potřebují také views, protože podle způsobu vytvoření mohou běžet s právy vlastníka a RLS obejít. Při práci s AI nástroji pracujícími s citlivými daty je takové opomenutí přesně ten typ zkratky, který nechceš objevit až v produkci.

Stejně podstatné jsou API klíče. Publishable klíč je určený do browseru, pokud data chrání správné GRANTy a RLS. Secret klíč používá oprávnění service_role, RLS obchází a patří výhradně na server. Hodí se pro ETL, cron nebo důvěryhodnou synchronizaci, nikdy pro frontend ani veřejný repozitář. Starší anon a service_role klíče mají být do konce roku 2026 nahrazené publishable a secret klíči.

Při debugování proto nejdřív zjisti, pod jakou rolí dotaz skutečně běží. Teprve potom kontroluj GRANT, použitou policy a hodnotu identity. Jinak můžeš hodinu opravovat frontend, přestože databáze přesně plní pravidlo, které jsi jí zadal.

Můj minimální bezpečnostní checklist pro každou exponovanou tabulku má pět kroků:

1. Vytvořit tabulku řízenou migrací.
2. Zapnout RLS.
3. Udělit jen nezbytné GRANTy.
4. Napsat samostatné policies pro potřebné CRUD operace.
5. Otestovat povolené i zakázané scénáře jako anonymní uživatel, přihlášený uživatel a serverový klient.

Supabase recenze, která Auth jen zaškrtne v seznamu funkcí, míjí podstatu. Auth dodá identitu. Bezpečný systém vznikne teprve propojením identity, databázových oprávnění, RLS policies a správně oddělených klíčů.

4. Praktická zkušenost: ingestion, dashboardy a automatizace

Nejrychlejší cestou k užitečnému Supabase projektu podle mě není další todo aplikace. Je jí centrální datová vrstva mezi službami, které už používáš, a reportem, který nad nimi potřebuješ. Přesně tak Supabase používám pro členská, engagement, SEO a produktová data.

Tok je přímočarý. Skript nebo Cloudflare Worker stáhne data z Circle, Benta, Google Search Console či Usermavenu. Záznamy normalizuje a uloží do PostgreSQL. Dashboard pak neřeší autentizaci čtyř dodavatelů ani jejich odlišné formáty, ale čte připravené views nebo volá RPC funkce.

Při napojování automatizací mezi více systémy hlídej tři věci. První je idempotence: opakované spuštění nesmí vytvářet duplicity. Druhou jsou logy, ze kterých poznáš poslední úspěšný běh, počet zpracovaných záznamů a konkrétní chybu. Třetí jsou oddělení klienti. Uživatelský klient respektuje session a RLS, zatímco ingestion běží přes serverový secret klient.

Každou změnu schématu ukládám jako migraci. Ruční klikání v dashboardu je pohodlné při průzkumu, ale špatně se přenáší mezi vývojem a produkcí a mizerně se dohledává. U reportingu se navíc vyplatí držet složitější agregace ve views, aby různé obrazovky nepočítaly tutéž metriku pokaždé trochu jinak.

Ingestion tabulky odděluju od výstupních pohledů. Surová vrstva zachová původní identifikátory a čas stažení, transformační vrstva data čistí a výsledná view nabízí stabilní názvy sloupců dashboardu. Když dodavatel změní API, opravuju jednu část pipeline místo všech grafů.

Moje nejhorší Supabase zkušenost nebyla ztráta dat, ale uspaný Free projekt. Řídce spouštěná automatizace nevytvořila dost databázové aktivity, projekt se pozastavil a navázaný dashboardový chat přestal fungovat. Obnova byla ruční a následovala migrace na spolehlivější provoz.

U plánovaných synchronizací ukládám vlastní cursor nebo čas posledního zpracovaného záznamu. Retry pak naváže tam, kde předchozí běh skončil, místo opakovaného stahování celé historie.

Monitoruj nejen zdrojová API, ale i čerstvost posledního záznamu a dostupnost databáze. Supabase usnadní infrastrukturu, neodpovídá však za provozní disciplínu kolem ní.

5. Supabase cena: Free je na testování, Pro začíná na 25 USD

Částka 25 USD není „cena Supabase“. Je to začátek placené organizace, ke kterému se mohou přidat další projekty, compute, překročené kvóty a add-ons. Pokud tenhle rozdíl ignoruješ, rozpočet bude vypadat jednoduše jen do prvního většího účtu.

Free tarif stojí 0 USD a podle aktuálního oficiálního ceníku zahrnuje nejvýše 2 aktivní projekty, 50 000 měsíčně aktivních uživatelů, 500 MB databáze, 1 GB file storage a 5 GB egress. Pro prototyp, vývoj nebo ověření nápadu je štědrý. Pro službu, na kterou se spoléhá zákazník, má ale zásadní háček: projekt s nízkou databázovou aktivitou během sedmi dnů může být automaticky pozastaven. Samotná práce v administračním dashboardu se nemusí počítat jako dostatečná aktivita.

Pro začíná na 25 USD měsíčně za organizaci. Zahrnuje 100 000 MAU, 8 GB databázového disku na projekt, 100 GB Storage, 250 GB egress a sedmidenní denní zálohy. Součástí je také 10 USD compute credit, který pokryje jednu Micro instanci. Každý další projekt však potřebuje vlastní compute.

Nad zahrnuté kvóty se účtuje například 0,00325 USD za MAU, 0,125 USD za GB databázového disku, 0,021 USD za GB Storage a 0,09 USD za GB egress. Spend Cap je standardně zapnutý, takže před produkčním spuštěním rozhodni, zda raději přijmeš omezení služby, nebo povolíš další spotřebu.

Nejrychleji se přitom přehlédne egress. Databáze může zůstat malá, ale časté stahování velkých odpovědí nebo souborů posune účet jinam než počet řádků.

Pro reálný odhad Supabase ceny si sepiš:

• počet projektů a jejich compute,
• MAU a očekávaný růst,
• databázový disk a Storage,
• egress, Functions a Realtime provoz,
• zálohy, vlastní doménu a další add-ons.

Free používám jako testovací prostředí, ne jako slib dostupnosti. Jakmile projekt obsluhuje platící uživatele, klientský dashboard nebo kritickou automatizaci, počítám Pro do nákladů produktu a měsíčně kontroluju usage.

6. Storage, Realtime a Edge Functions: užitečný bonus, ne hlavní argument

All-in-one balík svádí k přesunutí všeho do Supabase. To ale není automaticky nejlepší architektura. Storage, Realtime a Edge Functions beru jako praktické doplňky k databázi, ne jako hlavní důvod pro výběr platformy.

Storage se hodí pro uživatelské uploady, dokumenty nebo obrázky, protože přístup lze navázat na Auth a policies. Realtime umí posílat změny z databáze do aplikace, což využiješ u chatu, živého přehledu stavu nebo spolupráce více uživatelů. U každé realtime funkce si ale ověř, zda ji produkt skutečně potřebuje. Nejdřív ověř přínos. Polling jednou za minutu bývá pro interní dashboard levnější a jednodušší.

Edge Functions dávají smysl pro webhooky, lehkou integrační logiku a I/O operace. Hosted Functions mají 256 MB paměti a 2 sekundy CPU času na request. Wall-clock limit je 150 sekund na Free a 400 sekund na placených plánech. Dlouhé čekání na API tedy ještě může projít, ale CPU-heavy transformace, rendering nebo velká datová pipeline sem nepatří.

Pro náročnější ingestion raději používám samostatný worker nebo plánovaný skript, který se Supabase komunikuje serverovým klientem. Získám lepší kontrolu nad retry, časem běhu, pamětí i logování. V Supabase pak zůstane to, v čem je nejsilnější: relační data, oprávnění a rozhraní pro aplikaci.

V této Supabase recenzi jsou doplňkové služby plus. Nejsou však důvodem ignorovat jejich kvóty ani stavět dlouhé zpracování do prostředí určeného pro krátké funkce.

7. Limity, migrace a alternativy k Supabase

PostgreSQL snižuje lock-in, ale neodstraňuje ho. Databázový dump přenese schéma, data a další databázové objekty. Kompletní odchod však zahrnuje také soubory ve Storage, Edge Functions, OAuth poskytovatele, SMTP, klíče, secrets a DNS. „Je to Postgres, takže migrace bude na jedno kliknutí“ je nebezpečná polopravda.

Self-hosting Supabase je možný, jenže tím přebíráš aktualizace, monitoring, zálohy, obnovu a konfiguraci celého stacku. Oficiální minimum pro Docker je 4 GB RAM, 2 CPU a 40 GB SSD. Doporučená konfigurace začíná na 8 GB RAM, 4 CPU a 80 GB SSD. Cena serveru proto není celková cena provozu. Nejdražší bývá čas člověka, který řeší incident v neděli večer.

Alternativu vybírám podle problému, ne podle seznamu funkcí:

Nástroj	Zvolil bych ho, když	Hlavní kompromis
Supabase	Chci PostgreSQL, Auth, Storage a Realtime v jednom	RLS a billing vyžadují disciplínu
Firebase	Stavím mobilní aplikaci kolem dokumentových realtime dat	Relační reporting je méně přirozený
Neon	Potřebuji hlavně serverless managed Postgres	Auth a Storage skládám zvlášť
Appwrite	Chci širší BaaS s možností self-hostingu	Jiný ekosystém a provozní model
PocketBase	Stavím malý interní nástroj nebo lehký prototyp	Menší ambice pro náročný produkční provoz

Supabase alternativy tedy nejsou přímé kopie. Pokud potřebuješ čistě serverovou relační databázi, Neon nebo jiný managed Postgres může být jednodušší. Pokud chceš login, soubory a klientské API bez skládání dodavatelů, Supabase má přesvědčivější celek.

Závěr

Supabase se podle mě vyplatí pro relační MVP, menší SaaS, klientské portály a reportingové aplikace. Nabízí standardní PostgreSQL, rychle použitelné API a praktický balík Auth, Storage, Realtime a Functions. Moje Supabase zkušenosti potvrzují, že malému týmu může ušetřit týdny práce.

Má to tři podmínky. Navrhni databázi a migrace jako u normálního PostgreSQL projektu. Otestuj GRANTy, RLS policies, views a oddělení publishable a secret klíčů. Pro produkci spočítej skutečný účet včetně compute, kvót a rizika uspání Free projektu.

Tři důvody pro jsou rychlost dodání, standardní relační základ a bezpečnost vynutitelná přímo u dat. Tři varování jsou učicí křivka RLS, vícesložkový billing a fakt, že kompletní migrace zahrnuje víc než databázový dump. Pokud ti tato výměna sedí, Supabase patří mezi nejlepší BaaS možnosti pro malý technický tým.

Začni prototypem na Free, projdi bezpečnostní a nákladový checklist z předchozích částí a před zapojením platících uživatelů přejdi na Pro. Pokud tento postup dává tvému projektu smysl, můžeš si Supabase vyzkoušet na oficiálním webu. Pokud chceš jen jednoduchou databázi bez Auth a Storage, vezmi raději čistý managed Postgres.

Často kladené otázky

Je Supabase zdarma?

Ano. Free tarif nabízí až 2 aktivní projekty, 50 000 MAU, 500 MB databáze, 1 GB Storage a 5 GB egress. Projekt s nízkou databázovou aktivitou během sedmi dnů ale může být pozastaven, takže tento tarif doporučuji pro prototypy a vývoj, ne pro kritický produkční provoz.

Pozastavení se netýká placených projektů kvůli neaktivitě. Přechod na Pro je proto součástí rozhodnutí o dostupnosti, ne jen nákup větších kvót.

Kolik stojí Supabase Pro?

Supabase Pro začíná na 25 USD měsíčně za organizaci. Cena zahrnuje kvóty a 10 USD compute credit pro jednu Micro instanci. Další projekty, vyšší compute, add-ons a spotřeba nad limity účet zvyšují, proto 25 USD ber jako minimum, ne pevnou konečnou cenu.

Je publishable klíč bezpečný ve frontendu?

Ano, publishable klíč je určený pro veřejné klienty, pokud máš správně nastavené GRANTy a RLS policies. Secret klíč používá oprávnění service_role, obchází RLS a do browseru nikdy nepatří. Uchovávej ho pouze v serverových secrets.

Je Supabase vhodný pro produkci?

Ano, pokud tým zvládá PostgreSQL, migrace, testování RLS, monitoring a kontrolu kvót. Pro produkční aplikaci bych nepoužíval Free tarif kvůli možnému uspání. Před spuštěním otestuj povolené i zakázané scénáře každé operace a nastav upozornění na čerstvost dat.

Do provozního checklistu přidej také obnovu ze zálohy. Záloha, kterou nikdo nezkusil obnovit, je pouze naděje.

Lze Supabase self-hostovat?

Ano. Připrav se ale na vlastní patching, monitoring, zálohy, obnovu a konfiguraci navázaných služeb. Oficiální minimum pro celý Docker stack je 4 GB RAM, 2 CPU a 40 GB SSD, doporučení začíná na 8 GB RAM, 4 CPU a 80 GB SSD.