Firebase vagy Supabase: az adatmodell hamarabb dönt, mint a havidíj

Ha az alkalmazás főként önálló rekordokat kér le, és a mobilos offline működés fontos, a Firebase Cloud Firestore lehet kézenfekvő választás. Ha a felhasználók, termékek és rendelések kapcsolataira épülnek a lekérdezések, a Supabase PostgreSQL-adatbázisa ad természetesebb alapot. A havidíjat ezután érdemes vizsgálni: ugyanaz a felhasználói művelet a két rendszerben más számlázási egységeket érint.

Az összevetés a Cloud Firestore Standard kiadására és a Supabase felügyelt Postgres-adatbázisára vonatkozik. Mindkét platform kínál további szolgáltatásokat, így az adatbázis ingyenes kerete önmagában nem egy teljes alkalmazás költsége. Az alábbi három feltételezett terhelés megmutatja, mikor a dokumentumműveletek, mikor a kézbesített üzenetek vagy a kimenő adatforgalom kerül előtérbe.

Előbb a lekérdezés alakját érdemes eldönteni

A Firestore gyűjteményekben tárolt dokumentumokkal dolgozik. Egy termék adatlapja kiszolgálható egyetlen dokumentumból, ha a képernyőhöz szükséges mezők abban vannak; a több rekordot összekapcsoló nézethez viszont külön lekéréseket vagy előre összeállított adatokat kell tervezni. A Supabase Postgres-tábláiban az idegen kulcsok és a kapcsolt lekérdezések alkalmasak arra, hogy ugyanazokból az adatokból különböző nézetek készüljenek.

Ez a szerkezeti különbség a forgalmi számításban is megjelenik. Egy rendelési lista Firestore-ban lehet sok dokumentum olvasása, míg Supabase-ben egy kapcsolt lekérdezés válasza; utóbbinál a visszaküldött sorok és mezők mennyisége számít az adatforgalomban. A választás ezért nem vezethető le abból, hogy egy képernyő hány API-kérést indít: azt kell látni, hány dokumentumot olvas, illetve mennyi adatot küld vissza.

Az ingyenes keretek különböző mértékegységeket használnak

A Firestore számlázási szabályai szerint egy projekten belül egy adatbázishoz napi 50 000 dokumentumolvasás, 20 000 írás és 20 000 törlés jár ingyen; a tárolási keret 1 GiB, a kimenő adatátvitelé havi 10 GiB. A napi keret csendes napokról nem vihető át egy forgalmasabb napra. A lekérdezés dokumentumain kívül bizonyos indexbejegyzések olvasása is számíthat, a valós idejű figyelők pedig a bekerülő vagy módosuló dokumentumok után újabb olvasásokat okozhatnak.

A Supabase számlázási útmutatója Free, Pro, Team és Enterprise csomagot sorol fel. A Free csomag kimenő adatforgalmi kerete havi 5 GB, az adatbázisé projektenként 500 MB; a Realtime szolgáltatás havi 2 millió üzenetet és legfeljebb 200 egyidejű kapcsolatot enged a megadott keretben. A fizetős szinteken az előfizetés mellett a keretet meghaladó használat és a projektek számítási erőforrása is költséget jelenthet. Egy nagy válaszú katalógus és egy sok címzettnek küldő chat így eltérő okból közelítheti meg a korlátot.

Három feltételezett terhelés számokkal

A példák 30 napos hónappal, minden nap azonos forgalommal és gyorsítótár nélküli kiszolgálással számolnak. A megadott válaszméret csak a hasznos adat becslése: a tényleges átvitelhez más mezők, protokollüzenetek és az alkalmazás további szolgáltatásai is hozzájárulhatnak. Az eredmények terhelési modellek, nem mért teljesítményadatok vagy kész számlaösszegek.

Kis CRUD-alkalmazás

Feltételezzük, hogy naponta 500 látogató fejenként 8 rekordot olvas és 2 rekordot módosít, minden tizedik látogató pedig töröl egyet. Ha egy rekord pontosan egy Firestore-dokumentum, ez napi 4000 olvasás, 1000 írás és 50 törlés. Mindhárom érték a napi ingyenes műveleti kereten belül marad. Átlagosan 2 KiB-os olvasási válasszal a 30 nap alatt továbbított hasznos adat körülbelül 246 MB.

A Supabase oldalán ugyanennek a profilnak a kimenő adatforgalma szintén szerény a megadott válaszmérettel, de a táblák és indexek tárolási mérete külön változó. Itt egyik ingyenes keret sem ad erős választ önmagában. Ha a rekordok később rendszeresen együtt jelennek meg szűrésekben és kimutatásokban, a relációs séma előnye már a fejlesztés során jelentkezhet; egyszerű, önálló rekordoknál a dokumentummodell is jól illeszkedhet.

Valós idejű chat

Legyen naponta 1000 új üzenet, és minden üzenetet átlagosan 20 aktív kliens kapjon meg. Ha az üzenet egy Firestore-dokumentum, a figyelők kézbesítése legalább napi 20 000 dokumentumolvasást, az üzenetek létrehozása pedig 1000 írást jelent a modellben. Ez 30 nap alatt 600 000 olvasás és 30 000 írás. A beszélgetéselőzmények első lekérése, az újracsatlakozások és az esetleges jogosultsági szabályokhoz szükséges olvasások növelhetik a tényleges értéket.

A Supabase Realtime üzenetszámlálási szabálya adatbázis-változásnál minden figyelő kliensnek küldött eseményt külön üzenetnek számít. Ha a chat ilyen eseményekkel működik, a feltételezett terhelés havi 600 000 kézbesítés: ez a Free üzenetkerete alatt van, amennyiben más Realtime-forgalom nem tölti ki azt. Az egyidejű kapcsolatok korlátját külön kell figyelembe venni. Kézbesítésenként 1 KiB hasznos adattal az üzenetek hozzávetőleg 614 MB forgalmat adnak, az előzmények és az egyéb válaszok nélkül.

Olvasásintenzív katalógus

Tegyük fel, hogy naponta 5000 látogatáskor 20 termék jelenik meg, és minden visszaküldött dokumentum vagy sor 2 KiB. A Firestore-modellben ez napi 100 000 dokumentumolvasás, vagyis 50 000-rel több a napi ingyenes keretnél. Egyenletes forgalom mellett 30 nap alatt 3 millió olvasás keletkezik; ebből 1,5 millió esik a napi keretek fölé. A válaszok feltételezett hasznos adata körülbelül 6,29 GB havonta.

Ugyanennyi, a Supabase adatbázisából kiküldött hasznos adat már önmagában meghaladja a Free csomag havi 5 GB-os kimenő keretét. A Firestore példájában a dokumentumolvasások lépik át biztosan előbb a saját ingyenes határukat; a becsült válaszadat a külön megadott 10 GiB-os átviteli keret alatt van. A két keret eltérő egységű, ezért ezekből a számokból még nem következik, melyik fizetős megoldás olcsóbb. A terméklista rövidítése vagy a visszaküldött mezők csökkentése mindkét terhelést mérsékelheti, de nem ugyanabban a számlázási sorban.

Az offline kliens külön döntési feltétel

A Firestore offline működésének leírása szerint Androidon és Apple-platformokon a tartós helyi gyorsítótár alapértelmezés szerint aktív, a weben külön kell engedélyezni. A kliens a korábban elért adatokat kapcsolat nélkül is olvashatja és módosíthatja, majd visszakapcsolódáskor szinkronizál. Ha ugyanazt a dokumentumot többször módosítják, az utolsó írás érvényesül; a helyi másolat közben hiányos vagy elavult lehet.

Egy terepen használt mobilalkalmazásnál ez lényeges fejlesztési szempont. Supabase Postgres-adatokkal is készíthető offline kliens, ám a helyi tárolást, a függőben lévő változtatások sorát és az ütközések kezelését az alkalmazásnak kell megterveznie. Egy főként online használt webes katalógusnál a kapcsolt lekérdezések és a kimenő adat mennyisége gyakran közvetlenebb döntési tényező.

A költözésnél az adat mellett a szolgáltatások is számítanak

A Supabase PostgreSQL-sémája kiindulópont lehet egy későbbi adatbázis-költözéshez. A Supabase mentési és visszaállítási útmutatója külön parancsokkal mutatja be a szerepkörök, a séma és az adatok exportját; a Storage-objektumok átvitelét és a kezelt sémák egyedi módosításait külön feladatként kezeli. Más PostgreSQL-környezetbe költözve az adatbázis-séma hordozhatósága tehát segítség, de az Auth, a Realtime, a fájltárolás és a klienskód függőségeit is rendezni kell.

Firestore-ról relációs adatbázisra váltáskor a dokumentumokba ágyazott vagy több helyre másolt kapcsolatokat táblákra és kulcsokra kell leképezni, majd a rájuk épülő lekérdezéseket átírni. Ennek munkamennyisége az adott alkalmazásból következik, általános időbecslés nem adható rá. A sok kapcsolt adatot és többféle lekérdezést igénylő tervnél ezért a későbbi átalakítás költsége is része a választásnak; az offline mobilos használatnál a kész kliensoldali működés kaphat nagyobb súlyt.

Olvassa el ezt is:

• ChatGPT vagy Claude munkához: a feladat fontosabb, mint az összpontszám
• RAG vagy finomhangolás: a változó tudást nem érdemes a modellbe égetni
• Cursor vagy GitHub Copilot: az ügynökhasználat írja át a havidíjat