Supabase en Firebase kunnen allebei een backend voor een app of bedrijfsplatform vormen. Supabase is het onderzoeken waard wanneer PostgreSQL, gegevensrelaties en SQL belangrijk zijn. Binnen Firebase kan Firestore passen bij een documentmodel met mobiele clients en offline gegevens. Maar Firebase biedt ook SQL Connect op PostgreSQL. “Supabase is SQL, Firebase is NoSQL” is daardoor geen volledige vergelijking.
De verstandigste keuze volgt uit een klein, representatief onderdeel van jouw toepassing: de gegevens, toegangsregels, lastige gebruikersactie en herstelprocedure. Hieronder gebruiken we een fictieve werkbonapp om dat concreet te maken. Het voorbeeld is een ontwerpvoorstel, geen gemeten klantcase of geteste referentie-implementatie.
Vergelijk producten, niet alleen merknamen
| Route | Gegevens en toegang | Vraag voor de selectieproef |
|---|---|---|
| Supabase | Een volledige PostgreSQL-database, met diensten zoals authenticatie en opslag eromheen. | Kunnen we onze relaties, transacties en rapportages helder modelleren én de benodigde toegang begrenzen? |
| Firebase Firestore | Een documentdatabase met collections en documents. | Passen onze lees- en schrijfacties bij het documentmodel, inclusief de gegevens die meerdere schermen nodig hebben? |
| Firebase SQL Connect | Cloud SQL for PostgreSQL, met vooraf gedefinieerde GraphQL-operaties en gegenereerde, getypeerde client-SDK’s. | Past deze beheerste query- en mutatielaag bij ons team en onze toepassing? |
De officiële documentatie noemt de relationele Firebase-route op het moment van deze broncontrole SQL Connect; de oude Data Connect-documentatieroute verwijst ernaar door. Het zijn geen andere namen voor Firestore. Vergelijk daarom ook niet de offlinewerking of beveiligingsregels van het ene product alsof die automatisch voor het andere gelden.
Voorbeeld: een werkbonapp voor meerdere organisaties
Stel dat organisatie A en organisatie B dezelfde applicatie gebruiken. Iedere organisatie heeft klanten, locaties, werkbonnen en medewerkers. Een planner ziet alle werkbonnen van de eigen organisatie. Een monteur ziet alleen toegewezen werkbonnen en mag daarop uren en een voortgangsnotitie vastleggen. Alleen een bevoegde beheerder kan lidmaatschappen wijzigen; alleen een afgesproken rol kan werk voor facturatie vrijgeven.
De relatie tussen klant, locatie, werkbon, urenregel en facturatie is hier een wezenlijk ontwerpgegeven. Met een relationeel model kun je die relaties expliciet vastleggen. Bij een documentmodel moet je bepalen welke gegevens in welk document thuishoren, welke je herhaalt voor een specifieke leesactie en hoe je die kopieën consistent houdt. Geen van beide modellen kiest die afspraken voor je.
Maak de selectieproef daarom niet alleen “toon een lijst werkbonnen”. Neem ook het toewijzen van een monteur, het corrigeren van uren, een managementoverzicht en het intrekken van toegang mee. Noteer bij elke actie welke informatie wordt gelezen en welke gegevens samen moeten veranderen. Zo beoordeel je het model op echt werk in plaats van op de kortste demo.
Tarieven
Wat kost het?
Het begint bij . Wat jij betaalt hangt af van je situatie.
Ingelogd zijn en iets mogen zijn twee aparte controles
Een door de browser meegestuurd organisatie-ID bewijst geen lidmaatschap. Ook een gedecodeerde JWT is nog geen geverifieerde identiteit. Een eigen serverendpoint moet het token via de passende verificatiebibliotheek controleren, inclusief handtekening, geldigheid en de verwachte uitgever en ontvanger. Pas daarna volgt autorisatie voor de organisatie, het object en de handeling.
Supabase beschrijft daarvoor onder meer getClaims en JWT-verificatie. Firebase beschrijft verifyIdToken voor ID-tokens; de standaardcontrole controleert niet automatisch of een token is ingetrokken. Leg daarom apart vast hoe snel een verwijderd lid of gewijzigde rol zijn toegang moet verliezen en hoe de gekozen route dat afdwingt.
Voor de werkbonapp is de controle concreet: deze geverifieerde gebruiker is nu lid van organisatie A, heeft de vereiste rol en mag deze specifieke werkbon wijzigen. Neem die bevoegdheid niet over uit een door de gebruiker bewerkbaar profielveld.
Supabase: RLS moet aanstaan én juist zijn ingericht
Row Level Security, afgekort RLS, bepaalt welke databaserijen een rol mag benaderen. RLS moet op de relevante blootgestelde tabellen ingeschakeld zijn; daarnaast bepalen SQL-grants of de rol überhaupt een bepaalde tabelbewerking mag uitvoeren. Alleen een policy opschrijven is dus niet genoeg. De Supabase-handleiding voor RLS beschrijft beide lagen.
PostgreSQL past voor gewone rollen een standaardweigering toe wanneer RLS aanstaat en geen passende policy bestaat. Dat geldt niet zonder meer voor iedere databaseverbinding: onder meer rollen met BYPASSRLS en normaal gesproken tabeleigenaren vormen uitzonderingen. Zie de PostgreSQL-documentatie over row security.
De Supabase-sleuteltypen maken dat onderscheid belangrijk. Een publishable key identificeert een applicatieonderdeel, niet een individuele gebruiker. Secret keys en de oudere service-rolekey kunnen verhoogde toegang geven. RLS wordt omzeild wanneer de aanvraag effectief onder service_role of een andere bypassrol draait. Deze geheime sleutels horen niet in browsercode, mobiele builds of openbare voorbeelden. Een bevoorrechte serverroute moet zelf de benodigde gebruikers-, organisatie- en objectrechten afdwingen.
Alleen kijken naar de sleutel waarmee een SDK-client is aangemaakt is niet genoeg. Volgens de Supabase-uitleg over RLS-bypass volgt een aanvraag met een geldig gebruikers-access-token juist de policies van die gebruiker, ook als de client met een secret key is geïnitialiseerd. Controleer daarom het daadwerkelijk gebruikte token, de effectieve rol en de API-route. Een verkeerd doorgegeven gebruikerscontext kan ook een bedoelde beheeractie beperken; een onbedoelde bypasscontext kan de gebruikersgrens wegnemen.
Voor de werkbonapp moeten policies niet alleen lezen beperken. Een monteur mag ook geen werkbon aan organisatie B toewijzen door bij een update het organisatieveld te veranderen. Controleer bestaande én voorgestelde waarden, invoegen, wijzigen en verwijderen. Beoordeel daarnaast exportfuncties, databasefuncties en andere routes met verhoogde rechten. Een nette lijstweergave bewijst niet dat die achterdeuren dezelfde grenzen respecteren.
Firebase: de gekozen toegangsroute bepaalt de beveiliging
Bij Firestore worden verzoeken van mobiele en webclients beoordeeld met Security Rules. Serverbibliotheken omzeilen die regels en gebruiken andere toegangscontrole, waaronder IAM. Een backend met de Admin SDK erft dus niet automatisch de rechten van de ingelogde monteur. De Firestore-documentatie benoemt dit verschil expliciet.
SQL Connect heeft weer een eigen autorisatielaag voor queries en mutaties. De SQL Connect-securitydocumentatie beschrijft onder meer @auth, gegevensfilters en aanvullende controles. Een instelling die alleen vereist dat iemand is ingelogd, controleert niet vanzelf het eigenaarschap van een werkbon. Ook hier moet de operatie alleen de juiste organisatie en toegestane velden kunnen raken.
Laat de ontwikkelaar voor iedere route opschrijven waar de rechtencontrole werkelijk plaatsvindt: in Firestore Rules, een SQL Connect-operatie, PostgreSQL of eigen serverlogica. Test de serverroute afzonderlijk. Het scherm dat een knop verbergt is geen beveiligingsgrens.
Liever even bellen?
Laat je terugbellen
Eén telefoontje is vaak sneller dan drie mailtjes. Je hoort binnen een werkdag van ons.
Offline werken vraagt meer dan realtime updates
Firestore ondersteunt lokale gegevens en synchronisatie voor bepaalde clientplatforms. De offlinehandleiding beschrijft ondersteuning voor Android, Apple en web, met beperkingen per gebruikte operatie. Bij meerdere wijzigingen aan hetzelfde document geldt volgens deze documentatie last-write-wins. Dat is technische synchronisatie, geen inhoudelijke afspraak over welke urenregistratie terecht is.
In de werkbonapp kan een monteur zonder bereik een notitie maken terwijl de planner de opdracht annuleert. Leg vast wat de app bij terugkeer doet: toont hij een conflict, bewaart hij de notitie als afzonderlijke gebeurtenis of vraagt hij beoordeling? Het accepteren van uren voor facturatie kan een andere regel vereisen dan het opslaan van een conceptnotitie.
Een realtime-updatekanaal alleen beantwoordt die vragen niet. Beoordeel bij elke kandidaat lokale opslag, een herkenbare status voor nog niet gesynchroniseerde wijzigingen, herhalen zonder dubbele urenregels en het gedrag na intrekking van toegang. Controleer ook wat na uitloggen op een gedeeld toestel achterblijft. Neem niet aan dat de Firestore-cache bestaat in Supabase of SQL Connect omdat alle drie mobiele apps kunnen bedienen.
Een selectieproef die ook weigeringen controleert
Onderstaande testgevallen vormen een voorgesteld acceptatiecontract voor het voorbeeld. Ze zijn hier niet uitgevoerd tegen een Supabase- of Firebase-project. Gebruik afgeschermde testgegevens, gescheiden accounts en de juiste lokale testvoorzieningen: Supabase beschrijft lokaal testen en Firebase beschrijft tests voor Security Rules. Controleer dat de gekozen testopzet geen productiediensten aanspreekt.
| Proef | Verwachte uitkomst |
|---|---|
| Planner A vraagt een eigen werkbon op | De toegestane gegevens zijn beschikbaar. Een testset met alleen weigeringen is onvoldoende. |
| Planner A vraagt een bekend werkbon-ID van B op | Geen inhoud uit B, ook niet via export, zoekresultaten, bijlagen of een apart serverendpoint. |
| Monteur A benadert een niet-toegewezen werkbon | Geen toegang, ook als de werkbon tot dezelfde organisatie behoort. |
| Monteur wijzigt organisatie, beheerrol of facturatievrijgave | De ongeoorloofde wijziging wordt afgewezen en de opgeslagen waarden blijven intact. |
| Token is gewijzigd, verlopen of voor een ander project uitgegeven | Geen geauthenticeerde toegang. Decoderen alleen leidt nergens tot vrijgave. |
| Lidmaatschap wordt ingetrokken terwijl de app openstaat | Nieuwe serveracties voldoen aan de afgesproken intrekkingsregel; de app behandelt resterende lokale gegevens bewust. |
| Een offline urenregel wordt na een onderbreking opnieuw verstuurd | Eén zakelijke urenregel of een herkenbaar conflict, geen stille dubbele boeking. |
| Dezelfde actie loopt via een bevoorrechte serververbinding | De bedoelde gebruikersrechten blijven afgedwongen; het gebruik van een Admin- of secret-client maakt de actie niet automatisch toegestaan. |
AI-zoekfuncties beslissen de vergelijking niet alleen
Supabase ondersteunt PostgreSQL-extensies zoals pgvector, zoals beschreven in het databaseoverzicht. Firebase biedt eveneens vectorzoekopdrachten in Firestore en noemt vector search bij SQL Connect. Alleen de aanwezigheid van vector search is daarom geen voldoende onderscheid.
Voor de werkbonapp is de belangrijke eis dat een zoekfunctie nooit een document van organisatie B aan gebruiker A of aan diens AI-context doorgeeft. Neem de organisatie- en documentrechten mee in de zoekroute vóór resultaten worden teruggegeven. Toets daarnaast de kwaliteit met eigen voorbeeldvragen; een korte vectordemo bewijst noch bruikbaarheid, noch gegevensisolatie.
Vergelijk gebruik en beheer, niet alleen het gratis instappunt
Maak een gebruiksprofiel van de selectieproef: hoeveel gegevens leest een werkbonlijst, hoeveel wijzigingen veroorzaakt één handeling, welke processen blijven luisteren en hoeveel bijlagen worden gedownload? Voeg achtergrondtaken, authenticatie, rapportages en een piekmoment toe. Vul daarna de actuele kosten voor de gekozen producten en configuratie in. Een gebruikersaantal op zichzelf voorspelt dat verbruik niet.
Leg ook vast wie updates, toegangsbeheer, monitoring, back-ups en herstel controleert. Supabase benoemt bij self-hosting expliciet eigen verantwoordelijkheid voor onder meer infrastructuur, beveiligingsupdates, databasebeheer, back-ups en beschikbaarheid. Zelf hosten is dus een andere beheertaak, geen automatische besparing of privacygarantie.
Test een herstel met de gegevens én de bestanden die de toepassing nodig heeft. Een exportbestand is pas bruikbaar als je kunt aantonen hoe relaties, accounts, toegangsregels en bijlagen terugkomen. Bij een migratie hoort ook een mapping voor gebruikers-ID’s, een aanpak voor opnieuw aanmelden en een gecontroleerde overgang van lopende wijzigingen. PostgreSQL-gegevens kunnen verplaatsen betekent niet dat iedere authenticatie- of opslagintegratie zonder aanpassing meeverhuist.
Wanneer is welke route het onderzoeken waard?
- Onderzoek Supabase als je team met SQL werkt en relaties, databasebeperkingen en rapportages belangrijk zijn. Laat juist ook de RLS- en serverroutes bewijzen dat ze het juiste datamodel veilig ontsluiten.
- Onderzoek Firestore als documentgerichte interacties en de beschikbare mobiele offlinefunctionaliteit goed passen. Maak conflicten, herhaalde schrijfacties en ingetrokken toegang onderdeel van de proef.
- Onderzoek SQL Connect als je binnen het Firebase-ecosysteem een relationele route zoekt met gedefinieerde clientoperaties. Beoordeel die route op haar eigen SDK’s, rechtenmodel en beheer.
Kies pas wanneer één kandidaat de belangrijkste werkstroom en de afgesproken weigeringen overtuigend laat zien. Voor de werkbonapp betekent dat: de planner kan plannen, de monteur kan het juiste werk vastleggen en niemand kan via een andere route de grenzen tussen organisaties omzeilen.
Wil je eerst de gegevens en verantwoordelijkheden scherp krijgen? Bekijk maatwerk systemen, planning en uitvoering en doorontwikkeling en beheer. Heeft het platform ook betaalde toegang, lees dan de vergelijking van Stripe en Mollie voor de volledige betaalstroom.
