Firebase vs. Supabase 2026: co zvolit pro backend aplikace
Backend-as-a-Service (BaaS) platformy slibují jednoduchou věc: nemusíte stavět vlastní backend. Databáze, přihlašování, ukládání souborů i realtime synchronizace jsou hotové — stačí je napojit z aplikace. Dvě jména dnes dominují: Firebase od Googlu a open-source vyzyvatel Supabase.
Obě platformy používáme na reálných projektech, takže tohle nebude souboj marketingových webů. Podíváme se, v čem se liší architektonicky, co to znamená v praxi a — což je stejně důležité — kdy nedává smysl ani jedno.
Zásadní rozdíl: NoSQL vs. Postgres
Největší rozdíl není v logu ani v ceně, ale v datovém modelu.
Firebase staví na dokumentové NoSQL databázi Firestore (případně starší Realtime Database). Data ukládáte jako dokumenty v kolekcích, bez schématu a bez relací. Pro jednoduché struktury je to pohodlné — dokud nepotřebujete data spojovat. Firestore neumí JOIN, agregace jsou omezené a složitější dotazy řešíte denormalizací: stejná data duplikujete na víc míst a při zápisu je synchronizujete. To je práce navíc a zdroj chyb, který roste s komplexitou aplikace.
Supabase je v jádru plnohodnotný PostgreSQL. Relace, JOINy, transakce, pohledy, fulltextové vyhledávání, SQL funkce — všechno, co od relační databáze čekáte. Pokud vaše data mají strukturu (a data většiny byznys aplikací ji mají: zákazníci, objednávky, rezervace, faktury), je relační model přirozenější a dlouhodobě levnější na údržbu.
Prakticky: e-shop, rezervační systém nebo CRM s Firestore znamená bojovat s datovým modelem od prvního dne. Ty samé aplikace nad Postgres jsou rutina.
Srovnání po oblastech
| Oblast | Firebase | Supabase |
|---|---|---|
| Databáze | Firestore (NoSQL, dokumenty) | PostgreSQL (relační, SQL) |
| Dotazy | Omezené, bez JOINů | Plné SQL, pohledy, funkce |
| Auth | Firebase Auth (velmi vyzrálé) | GoTrue (e-mail, OAuth, magic links) |
| Realtime | Nativní, výborné | Postgres replikace, dobré |
| Storage | Cloud Storage (GCS) | Storage nad S3 kompatibilním úložištěm |
| Serverové funkce | Cloud Functions (Node, Python…) | Edge Functions (Deno/TypeScript) |
| Vendor lock-in | Vysoký | Nízký (open source, standardní Postgres) |
| Self-hosting | Ne | Ano (Docker, vlastní infrastruktura) |
| Lokální vývoj | Emulator Suite | Supabase CLI (plný lokální stack) |
| Cenový model | Pay-per-use (operace, přenosy) | Fixní tarify + usage |
Autentizace
Firebase Auth je nejvyzrálejší část celé platformy — telefonní ověření, anonymní účty, desítky poskytovatelů, bezpečnostní pravidla propojená s Firestore. Pokud je auth to hlavní, co od BaaS chcete, Firebase je jistota.
Supabase Auth (GoTrue) pokrývá standardní scénáře: e-mail a heslo, magic links, OAuth přes Google, Apple, GitHub a další. Velká výhoda: uživatelé jsou normální řádky v Postgres tabulce, takže je můžete joinovat s vlastními daty a řídit přístup přes Row Level Security přímo v SQL. Je to konzistentnější model než kombinace Firebase Auth + security rules v samostatném jazyce.
Realtime
Firebase byl na realtime synchronizaci postavený a je to znát — offline podpora v mobilních SDK, automatická synchronizace po připojení, konfliktní scénáře vyřešené za vás. Pro aplikace typu chat, kolaborativní nástroje nebo live dashboardy je to nejsilnější argument pro Firebase.
Supabase realtime funguje nad logickou replikací Postgresu: posloucháte změny v tabulkách (INSERT/UPDATE/DELETE) přes websockety. Pro většinu use-caseů (aktualizace seznamu rezervací, notifikace o nové objednávce) bohatě stačí. Offline-first synchronizaci ale za vás neřeší — tu si dopisujete sami.
Ceny: pozor na pay-per-use
Firebase účtuje za operace: každé čtení, zápis a smazání dokumentu se počítá. Free tier je štědrý a malé aplikace jedou zadarmo. Problém nastává s růstem — neefektivní datový model (a k tomu Firestore denormalizací svádí) znamená násobně víc čtení, a účet umí nepříjemně překvapit. Odhadnout náklady dopředu je obtížné.
Supabase má předvídatelnější model: fixní měsíční tarif (free, ~25 USD Pro) plus poplatky za nadlimitní usage (úložiště, přenosy). Pro byznys plánování je fixní částka výhoda. A pokud náklady přerostou rozumnou mez, existuje úniková cesta: self-hosting.
Vendor lock-in a úniková strategie
Tady je rozdíl nejostřejší.
Firebase je jednosměrka. Firestore nemá standardní protokol, security rules jsou proprietární, Cloud Functions jsou svázané s Google Cloud. Migrace pryč znamená přepsat datovou vrstvu, auth i serverovou logiku — u větší aplikace klidně měsíce práce.
Supabase je standardní Postgres. pg_dump a máte kompletní data i schéma. Celá platforma je open source a dá se provozovat na vlastním serveru přes Docker. I kdyby Supabase zítra zmizel, vaše aplikace poběží dál — jen si Postgres a auth hostujete jinde. Pro firmy, které přemýšlejí v horizontu let, je tohle zásadní pojistka.
Kdy zvolit co
Firebase dává smysl, když:
- stavíte mobilní aplikaci s důrazem na offline-first a realtime synchronizaci,
- auth scénáře jsou složité (telefonní ověření, anonymní účty s pozdějším upgradem),
- data jsou jednoduchá a dokumentový model jim sedí,
- jste v Google ekosystému (Analytics, Crashlytics, Cloud Messaging v jednom).
Supabase dává smysl, když:
- data mají relační strukturu — objednávky, rezervace, sklady, fakturace,
- chcete SQL, reporting a analytické dotazy bez exportů,
- vendor lock-in je pro vás riziko (nebo compliance vyžaduje data ve vlastní infrastruktuře),
- tým umí SQL — křivka učení je pak minimální.
Kdy ani jedno: custom backend
BaaS platformy mají strop. Narazíte na něj, když aplikace potřebuje:
- složitější byznys logiku na serveru — výpočty cen, schvalovací workflow, integrace na účetnictví, platební brány nebo ERP; serverless funkce to zvládnou, ale při desítkách funkcí se z nich stává hůř udržovatelný backend rozsekaný na kusy,
- výkonové garance — BaaS neladíte, jen používáte; když je pomalý dotaz, máte omezené možnosti,
- specifické požadavky na data — audit trail, verzování záznamů, složité reporty napříč moduly.
V takové situaci je API-first custom backend dlouhodobě levnější než ohýbání BaaS. Vlastní backend vám postavíme tak, aby rostl s aplikací — a klidně hybridně: Postgres jako základ, BaaS prvky (auth, storage) tam, kde šetří čas.
Náš pohled z praxe
Ve studiu dnes pro většinu nových projektů saháme po Supabase nebo rovnou po vlastním Postgres backendu. Důvod je prozaický: byznys aplikace, které stavíme — rezervační systémy, CRM, interní firemní nástroje — jsou z podstaty relační. Firebase volíme cíleně tam, kde vyhraje jeho realtime a offline synchronizace, typicky u mobilních aplikací s nestabilním připojením.
A důležitá poznámka na závěr: volba BaaS není architektura navždy. Rozumně postavená aplikace má datovou vrstvu oddělenou tak, aby se dala vyměnit. Přesně tak k tomu přistupujeme — začít rychle a levně, ale nezabetonovat se.
Nevíte, co je správně pro váš projekt?
Výběr backendu je rozhodnutí na roky — a špatná volba se draho přepisuje. Souvisí s tím i výběr technologie pro celou aplikaci a otázka serverless architektury.
Pokud si nejste jistí, zarezervujte si konzultaci — projdeme váš projekt a doporučíme stack bez ohledu na módní vlny. A pokud chcete rovnou vědět, kolik by aplikace stála, konfigurátor vám dá odhad za dvě minuty.
