Supabase, nebo Firebase: levný začátek může skrýt drahé čtení dat

|Autor: Redakce QUASA|6 min čtení
Supabase, nebo Firebase: levný začátek může skrýt drahé čtení dat

Pro aplikaci s provázanými daty, SQL dotazy a požadavkem na přenositelnost databáze je obvykle vhodnější Supabase. Firebase s databází Cloud Firestore dává větší smysl tam, kde je důležitá vestavěná synchronizace offline a data přirozeně tvoří dokumenty. Jeho nízké počáteční náklady však mohou zastřít účet za opakované čtení dokumentů: rozhoduje, co aplikace načítá při otevření obrazovky i při dalších aktualizacích.

Volbu proto neurčuje samotný počet uživatelů. Menší služba SaaS může mít ve Firestore nízký poplatek za databázové operace, zatímco hojně navštěvovaný katalog nebo chat mohou vytvořit mnohem více čtení než zápisů. Supabase neúčtuje jednotlivá SQL čtení stejným způsobem, ale vyšší provoz může zvýšit nároky na výkon, přenos dat a u chatu také na službu Realtime.

PostgreSQL a dokumenty mění návrh aplikace

Databází Supabase je PostgreSQL: vztahy mezi zákazníkem, organizací, oprávněním a objednávkou lze vyjádřit tabulkami, cizími klíči a SQL. To je užitečné zvláště u SaaS, kde se stejná data objevují v různých přehledech a pravidla produktu se vyvíjejí. Relační model umožňuje upravit dotaz nad společnými daty, místo aby aplikace pro každý přehled udržovala samostatné kopie hodnot.

Cloud Firestore ukládá dokumenty do kolekcí. Zpráva chatu nebo položka katalogu může být samostatným dokumentem, který klient načte či sleduje. Jestliže však obrazovka potřebuje údaje z několika kolekcí, musí návrh určit, které dokumenty načíst a které údaje případně předem uložit společně. Tento návrh ovlivní složitost změn i počet účtovaných čtení. Dokumentové čtení proto nelze při srovnání cen považovat za ekvivalent SQL dotazu.

Co obě služby skutečně účtují

Ceník Supabase uvádí tarif Pro od 25 dolarů měsíčně pro první projekt, zahrnutých 8 GB databázového prostoru, 250 GB přenosu dat, 100 000 měsíčně aktivních uživatelů autentizace a 5 milionů zpráv Realtime za měsíc. Nad příslušné kvóty se využití účtuje zvlášť; placený tarif zahrnuje kredit na výpočetní výkon, který pokryje instanci Micro. Paušál tedy poskytuje výchozí částku, nikoli záruku stejného účtu při libovolné zátěži.

Podle pravidel účtování Firestore se u standardní edice sledují čtení, zápisy a mazání dokumentů, některá čtení indexů, uložená data a přenos; jedna databáze v projektu má bezplatnou denní kvótu 50 000 čtení, 20 000 zápisů a 20 000 mazání, vedle 1 GiB úložiště a 10 GiB měsíčního odchozího přenosu. Kvóty na operace se obnovují denně. U průběžně sledovaného dotazu se účtuje čtení při přidání nebo změně dokumentu ve výsledku; po odpojení může nové připojení znamenat opětovné načtení výsledku. Placenou položkou mohou být také zálohy.

Pro modelové výpočty níže platí sazby standardní edice pro oblast us-central1: 0,30 dolaru za milion čtení a 0,90 dolaru za milion zápisů nad bezplatnou kvótu. Sazby se mohou lišit podle umístění databáze. Částky v příkladech jsou proto výpočtem pro uvedenou oblast, nikoli cenovou nabídkou pro každou aplikaci určenou českým uživatelům.

Chat, SaaS a katalog při rozdílném poměru čtení a zápisů

Následující příklady jsou podmíněné modely, nikoli naměřené účty. Předpokládají třicet dní rovnoměrného provozu a jednu databázi Firestore oprávněnou k bezplatné kvótě. Za toto období tak model odečítá 1,5 milionu bezplatných čtení a 600 000 bezplatných zápisů. Počítá pouze poplatek za tyto operace; úložiště, přenos, další typy operací a ostatní služby v něm nejsou. U Supabase je srovnávacím bodem základní tarif Pro pouze tehdy, pokud stačí zahrnutý výkon a kvóty.

  • Chat: Předpokládejme 3 miliony nových zpráv a celkem 150 milionů načtení dokumentů s historií či aktualizacemi. Firestore by za čtení účtoval modelově 44,55 dolaru a za zápisy 2,16 dolaru, celkem 46,71 dolaru. V Supabase by samotná SQL čtení nevytvořila stejnou položku za dokumentové operace, ale doručování aktualizací přes Realtime, přenos a výkon databáze mohou účet zvýšit. Počet přečtení zprávy ve Firestore není automaticky totožný s počtem zpráv účtovaných službou Supabase Realtime.
  • SaaS: Při 10 milionech čtení a 1 milionu zápisů by modelový poplatek Firestore za tyto operace činil 2,91 dolaru. Z tohoto úzkého pohledu vychází níže než základ Supabase Pro. Jestliže ale zákaznická obrazovka skládá oprávnění, účty a transakce, vstupuje do volby také práce s datovými vztahy a úpravy schématu při změnách produktu.
  • Katalog: Při 300 milionech čtení a 300 000 zápisech by Firestore účtoval modelově 89,55 dolaru za čtení; zápisy by při rovnoměrném provozu zůstaly v bezplatné kvótě. Omezení počtu položek ve výsledku nebo mezipaměť může počet čtení změnit. Supabase by musel obsloužit stejný uživatelský provoz, takže u něj záleží zejména na velikosti odpovědí, přenosu a potřebném výkonu PostgreSQL.

Modely popisují různé poměry čtení a zápisů při srovnatelném uživatelském účelu, nikoli převod jedné databázové operace na druhou. Stránka katalogu, která při každé návštěvě stáhne mnoho položek, vyvolá jiný počet čtení než stránka s omezeným výsledkem. Stejně může posluchač chatu načítat změny průběžně, zatímco jiné řešení obnovuje historii jen po otevření konverzace. Změna návrhu může proto změnit cenu, i když počet uživatelů zůstane stejný.

Offline synchronizace má vlastní hodnotu

Firestore nabízí pro mobilní aplikace podstatnou část práce offline přímo v klientských knihovnách. Dokumentace režimu offline popisuje místní mezipaměť, čtení a zápisy bez připojení i synchronizaci po návratu sítě; trvalá mezipaměť je ve výchozím stavu zapnutá na Androidu a platformách Apple, zatímco na webu se musí povolit. Při souběžných změnách téhož dokumentu platí poslední zápis. To usnadňuje běžnou synchronizaci, ale aplikace musí počítat s tím, co toto pravidlo udělá například se dvěma úpravami stejného formuláře.

U aplikace postavené na Supabase je potřeba ukládání změn bez připojení, jejich pozdější odeslání a řešení konfliktů navrhnout podle konkrétního klienta. Pokud uživatelé pravidelně pracují mimo signál, má tato vývojová práce při výběru backendu větší váhu než samotný modelový poplatek za čtení. U služby používané převážně online může naopak převážit výhoda SQL a práce s provázanými údaji.

Autentizace a zálohy patří do stejného rozpočtu

Obě platformy nabízejí přihlašování, jehož náklady je třeba posuzovat odděleně od databáze. Supabase účtuje přesah podle měsíčně aktivních uživatelů, ne podle počtu všech registrovaných účtů. U Firebase záleží na zvoleném způsobu přihlášení a zapojených službách; například ověřování telefonního čísla může znamenat další placenou položku. Aplikace se stejným počtem databázových operací tak mohou mít rozdílný celkový účet kvůli odlišnému způsobu ověřování uživatelů.

Pravidla záloh Supabase uvádějí u projektu Pro denní zálohy dostupné za posledních sedm dní a možnost vytvořit vlastní logický export databáze; databázová záloha obsahuje metadata objektů ve Storage, nikoli uložené soubory samotné. Při obnově nebo stěhování proto záleží na tom, kde jsou kromě tabulek také přílohy. Zálohovací politika je samostatná otázka od ceny běžného provozu i od toho, jak snadno lze změnit poskytovatele.

Co obnáší odchod z platformy

PostgreSQL dává datům Supabase srozumitelnou cestu do jiného prostředí se stejnou databází. Přesun tabulek a SQL schématu je však jen část práce: zvlášť se řeší uložené soubory, autentizace, pravidla přístupu a kód používající služby platformy. Přenositelnost tedy znamená menší překážku u databázového jádra, nikoli bezpracné přestěhování celé aplikace.

Firestore také umožňuje data vyvést, ale dokumenty a kolekce je při přechodu na relační databázi nutné převést na tabulky a nově navrhnout vztahy i dotazy. U chatu nebo katalogu s jednoduchými dokumenty může být tato práce menší než u SaaS, který si do dokumentů uložil více vzájemně propojených údajů. Pro novou aplikaci je proto rozumné dát při volbě přednost tomu modelu, který odpovídá jejím datům a způsobu používání: Supabase pro provázaná data a SQL, Firebase s Cloud Firestore pro dokumenty a vestavěnou práci offline. Provozní cenu pak určí konkrétní dotazy, synchronizace a nároky na výkon.

Přečtěte si také:

Sdílet:

Přihlaste se k odběru newsletteru

Nejnovější zprávy ze světa Web3, AI a kryptoměn přímo do vaší schránky.

0