Supabase vai Firebase? Lukumääräinen laskutus voi yllättää kasvussa

Supabase on luonteva valinta, kun sovelluksen tiedot liittyvät vahvasti toisiinsa ja kyselyt hyötyvät Postgresista. Firebase-alustan Cloud Firestore sopii dokumenttimalliin ja sovellukseen, joka tarvitsee valmista offline-tukea. Hintaa ei kuitenkaan ratkaise pelkkä aloitustaso: Firestoren Standard-hinnastossa maksuton osuus on 50 000 dokumenttilukua ja 20 000 kirjoitusta päivässä, ja Iowan alueen perushinta niiden jälkeen on 0,03 ja 0,09 dollaria 100 000 operaatiolta.

Supabasessa yksittäisiä SQL-lukuja ei laskuteta Firestoren dokumenttilukujen tapaan. Supabasen laskutusohjeen mukaan jokaisella projektilla on oma Postgres-instanssi, jonka laskentakapasiteetti maksaa erikseen; käyttökiintiöitä ja niiden ylityksiä seurataan organisaation tasolla. Siksi paljon lukevan sovelluksen ja paljon päivityksiä lähettävän sovelluksen laskut voivat kehittyä eri suuntiin, vaikka käyttäjiä olisi yhtä paljon.

Tietomalli määrää, mitä yksi näkymä joutuu hakemaan

Postgresissa esimerkiksi käyttäjä, tilaus, tilausrivi ja tuote voidaan pitää erillisissä, toisiinsa liittyvissä tauluissa. SQL-kysely voi yhdistää ne silloin, kun sovellus tarvitsee yhteisen näkymän. Tämä vähentää tarvetta kopioida tuotetietoa jokaiseen tilaukseen, mutta suhteet, indeksit ja käyttöoikeudet vaativat suunnittelua. Raskaampi kysely voi myös edellyttää suurempaa Supabase-instanssia, vaikka sen suorituskerroille ei ole erillistä dokumenttilukuhintaa.

Firestore tallentaa tiedon kokoelmiin ja dokumentteihin. Yhden näkymän kannalta kätevä dokumentti voi sisältää valmiiksi juuri siinä tarvittavia tietoja. Jos samat tiedot esiintyvät monessa dokumentissa, päivitykset on puolestaan pidettävä yhtenäisinä. Käyttäjän yksi toiminto voi hakea monta dokumenttia, ja laskutus seuraa luettuja dokumentteja eikä käyttäjän kokemaa toimintojen määrää. Tässä vertailussa Firebase tarkoittaa nimenomaan Cloud Firestoreen perustuvaa toteutusta; alustan muut palvelut eivät sisälly laskelmiin.

Laskelmien rajat: päiväkohtainen etu ja aluehinta

Seuraavat kuormat ovat ehdollisia esimerkkejä, eivät mitattuja asiakaslaskuja. Kussakin kuukaudessa on 30 päivää, käyttö jakautuu tasaisesti ja Firestore-tietokanta on maksuttomaan osuuteen oikeutettu Standard-tietokanta. Lasku käyttää Iowan us-central1-alueen dollarimääräisiä perushintoja. Suomessa sijaitsevan tietokannan aluehinta voi olla toinen, joten esimerkkien dollarituloksia ei pidä siirtää sellaisinaan Suomen alueelle.

Mukaan otetaan vain erikseen mainitut dokumenttiluvut, kirjoitukset ja reaaliaikaviestit. Firestoressa myös tietyt kyselyt lukevat laskutettavia indeksimerkintöjä. Lisäksi tietojen tallennus ja verkkoliikenne voivat maksaa kummassakin palvelussa; tässä niiden määriä ei tunneta. Supabasen puolella sama dokumenttilukujen määrä ei kerro tarvittavaa Postgres-kokoa, sillä kyselyn rakenne, indeksit ja yhtäaikainen kuorma vaikuttavat siihen. Näin laskelmat näyttävät kustannusajurit, eivät koko sovelluksen lopullista kuukausihintaa.

Kolme kuormaa näyttävät, missä ero syntyy

Prototyyppi: operaatiot jäävät maksuttomaan osuuteen

Oletetaan, että prototyyppi lukee 30 000 ja kirjoittaa 5 000 Firestore-dokumenttia päivässä. Kuukaudessa kertyy 900 000 lukua ja 150 000 kirjoitusta, mutta tasaisessa käytössä kumpikin päiväkohtainen määrä pysyy maksuttoman rajan sisällä. Näiden operaatioiden hinta on siis nolla dollaria. Myös Supabasen maksuton suunnitelma voi sopia, jos projektin muut käyttö- ja kapasiteettirajat riittävät; pelkkä operaatioiden kuukausisumma ei ratkaise sitä.

Prototyypin tietomalliriski on myöhempi muunnostyö: useaan dokumenttiin kopioitu tieto täytyy ehkä järjestää suhteiksi tai taulut muuttaa dokumenteiksi. Offline-tarve kannattaa määrittää jo tässä vaiheessa, koska paikallisen synkronoinnin lisääminen myöhemmin muuttaa asiakassovelluksen toimintaa. Siirtoriski kasvaa erityisesti silloin, kun haut ja käyttöoikeussäännöt sidotaan valitun palvelun omiin rakenteisiin.

Paljon lukevia käyttäjiä: näytön avaus kertautuu

Oletetaan seuraavaksi 400 miljoonaa dokumenttilukua ja 20 miljoonaa kirjoitusta kuukaudessa tasaisesti jaettuina. Päivittäisen maksuttoman osuuden jälkeen laskutettavia lukuja jää 398,5 miljoonaa ja kirjoituksia 19,4 miljoonaa. Firestoren operaatiohinta on tällöin 119,55 + 17,46 eli 137,01 dollaria. Summa ei sisällä indeksilukuja, tallennusta eikä verkkoliikennettä. Jos yksi sovellusnäkymä lukee useita dokumentteja, juuri näkymän toistuva avaaminen kasvattaa tätä lukua.

Supabaselle ei voi johtaa vastaavaa hintaa näistä operaatiomääristä. Sama taulujen välinen haku voi onnistua nykyisellä instanssilla tai vaatia lisää laskentatehoa kyselyn ja samanaikaisen käytön mukaan. Välimuisti voi vähentää Firestoren verkkolukuja vain silloin, kun sovelluksen todellinen käyttö osuu siihen. Tämän kuorman tietomalliriski on tietojen monistuminen dokumentteihin; offline-etu riippuu asiakkaan käyttötavasta, ja siirtyminen alustalta toiselle edellyttää hakujen sekä tietorakenteen muuttamista.

Paljon reaaliaikapäivityksiä: vastaanottajat ratkaisevat

Oletetaan yksi dokumenttimuutos kymmenen kertaa minuutissa ja sata jatkuvasti kuuntelevaa asiakasta, joista jokainen vastaanottaa kaikki muutokset. Muutoksia syntyy 30 päivässä 432 000 ja toimitettuja päivityksiä 43,2 miljoonaa. Jos jokainen päivitys aiheuttaa yhden laskutettavan Firestore-dokumenttiluvun kuuntelijaa kohti, maksuttoman osuuden jälkeisten lukujen hinta on 12,51 dollaria. Kirjoituksia syntyy tasaisesti 14 400 päivässä, joten ne jäävät tässä esimerkissä päivittäiseen maksuttomaan osuuteen. Kuuntelun aloitus, uudelleenyhdistäminen ja muu tiedonsiirto voivat kasvattaa toteutunutta laskua.

Supabasen Realtime-laskutusohjeessa tietokantamuutos lasketaan viestiksi jokaiselle sitä kuuntelevalle asiakkaalle; Pro-suunnitelmaan sisältyy 5 miljoonaa viestiä, ja ylitys maksaa 2,50 dollaria alkavalta miljoonalta viestiltä. Oletetun 43,2 miljoonan viestin ylitys on 38,2 miljoonaa, joka pyöristyy 39 maksulliseen pakettiin: viestikulu on 97,50 dollaria. Sen lisäksi maksetaan tilauksesta, projektin laskennasta ja mahdollisista muista ylityksistä. Tietomallissa ratkaisee, mitä muutoksia tilaajille julkaistaan; offline-käytössä poissaolon aikaiset muutokset vaativat käsittelyä, ja alustaa vaihdettaessa tilauslogiikka on rakennettava uudelleen.

Offline-tuki ja siirrettävyys voivat painaa hintaa enemmän

Firestore tarjoaa valmiin lähtökohdan mobiilisovelluksen offline-käyttöön. Firestoren offline-ohjeen mukaan sovelluksen käyttämiä tietoja voidaan säilyttää laitteella ja paikalliset muutokset synkronoida yhteyden palatessa. Pysyvä tallennus on Androidissa ja Applen alustoilla oletuksena käytössä, mutta verkkosovelluksessa se otetaan erikseen käyttöön. Saman dokumentin ristiriitasääntö on viimeinen kirjoitus voittaa, joten yhteismuokkauksen vaatimukset on arvioitava erikseen.

Supabasen Postgres-rakenne antaa datalle tutun siirtoreitin. Supabasen palautusohje kuvaa skeeman, datan ja roolien viennin itse ylläpidettyyn ympäristöön, mutta tiedostot ja Edge Functions on siirrettävä erikseen. Koko sovelluksen siirto on siten laajempi työ kuin tietokannan vienti: tunnistautumisen asetukset, käyttöoikeudet, reaaliaikaiset tilaukset ja asiakkaan offline-logiikka voivat vaatia muutoksia. Jos yhteydetön käyttö on tuotteen ydintoiminto, sen toteutustyö voi olla tärkeämpi valintaperuste kuin prototyypin pieni tietokantalasku.

Lue myös:

• Bitwarden vai 1Password? Perhekäyttö paljastaa hinnan todellisen eron
• GitHub Actions vai GitLab CI? Minuutit peittävät todellisen laskun
• Trello vai Asana? Kolmas käyttäjä kääntää ilmaisen suunnitelman