Supabase vs Firebase for Marketplace Backends: What 25 Shipped Projects Show

How many of our builds actually used Supabase, and how many used Firebase?

Across the 25 projects in our portfolio, ten name one of these two backends in their tags or tech stack fields: seven Firebase, three Supabase. No project in the record uses both. That split is the first honest finding here, and it holds under two different counting rules, which is why we trust it. Two further projects mention a backend only in their written narrative. CEDMAT Roller Shutter App describes a NestJS and Firebase backend without carrying the Firebase tag, and ConstrActive Platform describes Supabase for database management without carrying the Supabase tag. We count those separately throughout, because tag data and prose data are different grades of evidence. Counting prose mentions too, the split becomes eight Firebase to four Supabase, and still no project uses both. Every figure below comes from these same 25 records, and each one states which counting rule produced it.

Which backend did we reach for when the product was a marketplace?

Five of the 25 projects describe themselves as a marketplace or a multi-vendor platform in their own text. Three of those five sit on Firebase: AgroBridge, a mobile agricultural marketplace; Koor Food Delivery, connecting customers to home chefs; and Pastel Marketplace, a luxury antiques platform. One sits on Supabase: Afriva, a multi-vendor e-commerce ecosystem with separate admin, manager, seller and buyer dashboards. The fifth, AI E-Commerce Ecosystem, uses neither, running on Next.js with Docker and Kubernetes. So in our record Firebase carried the marketplace work three times to Supabase's once. With five projects in the group, that ratio describes our history and nothing more. Afriva is the only one of the five whose record enumerates four distinct user roles, each with its own dashboard. Against our own thesis, though: Food Magnet, a Firebase build outside this group, lists the same four roles in the figures stored with it while naming only one dashboard, on the admin side.

Does the relational versus document data model show up in what we shipped?

Not directly, and we will not pretend otherwise. No project record in our dataset names Firestore or Realtime Database. The string postgres appears in exactly one record across all 25, and it belongs to Dooz Inspected Cars, a NestJS build using neither Supabase nor Firebase. So the data model debate that dominates every comparison article is simply absent from our own files. What the records do show is a difference in product shape. All three Supabase builds describe a dashboard: Augment Fit tracks sessions and performance, Waitmate manages reservations, staff and multi-location operations, and Afriva runs role-separated dashboards over inventory, orders and delivery. Only two of seven Firebase builds mention a dashboard. Conversely, five of seven Firebase records use the phrase real-time, against two of three Supabase records. Those are patterns in how we described our own work. They are consistent with two different product shapes, but they measure neither database engine.

Was Firebase the whole backend, or one service inside a larger stack?

In our record, usually the latter. Five of the seven Firebase projects list Firebase in their tech stack field. The other two, Koor Food Delivery and Pathana Platform, carry the Firebase tag while naming a different primary stack, React Native with NestJS and Next.js with Node.js respectively. Where the records say what Firebase was doing, they are specific: real-time delivery on Koor, authentication and data storage on Pathana, real-time sync and push notifications on Food Magnet, and a stats entry reading Realtime: Firebase on AgroBridge. Bondly names Firebase in its tags, tech stack and category but never states its role, and separately credits OneSignal for notifications. Four of the seven Firebase records also name AWS. Supabase appears differently. All three Supabase projects list it in the tech stack field, and each describes it as the data layer rather than one service among several. Not one of the three names AWS anywhere in its record.

Which platforms did each backend actually ship to?

Of the 25 projects, 18 have at least one public link: 15 web, 8 Android, 6 iOS. Inside the two backend groups the pattern diverges. All three Supabase projects are live on the web, and none has an App Store or Play Store listing. The Firebase group is more mixed: five of seven have a public web link and three of seven have a mobile store listing, with Food Magnet on both Android and iOS, Koor on Android and Pastel on iOS. AgroBridge has no public link recorded at all. One caution about the portfolio-wide totals: Three28 Creator Platform stores an Apple App Store URL in its android field while its ios field is empty, so the 8 and the 6 reproduce our fields rather than reality. Three28 names neither backend, so no comparison figure here is affected. The likeliest explanation for the split is simply what these particular clients hired us to build.

What frontend stacks and hosting did each backend pair with?

Across the whole portfolio, counted from tags and tech stack, Next.js appears in 5 projects, React Native in 6, Flutter in 5, Node.js in 9 and NestJS in 4. Inside the backend groups the pairings are distinct. All three Supabase builds pair with the React family on the web: React.js on Augment Fit and Waitmate, Next.js 15 on Afriva. None names React Native or Flutter in tags or tech stack. One qualifier we owe you: Waitmate's narrative text does name React Native for mobile accessibility, the same grade of evidence we flagged for CEDMAT and ConstrActive, though Waitmate has no store listing. The seven Firebase builds spread wider: Next.js on Coffee Shop, Pastel and Pathana; React Native on AgroBridge and Koor; Flutter with a React.js admin dashboard on Food Magnet; a Node.js service on Bondly. Hosting differs too. All three Supabase web links are vercel.app domains, against one of five Firebase web links.

How complete are the outcome numbers on each side?

Every one of the 25 projects carries a set of stored figures, 95 entries in total. Fifty-seven of those contain a numeral, and those 57 come from 19 projects, so six projects contribute no numbers at all. Some numeral-bearing entries are labels rather than measurements: Infra: Docker/K8s, Compliance: GDPR and ISO 27001, Access to Facilities: 24/7. Coverage inside the comparison is uneven in a way that matters. All three Supabase projects carry numeric figures; only four of the seven Firebase projects do. Bondly, AgroBridge and Food Magnet report none, and Food Magnet is the sharpest case, with eleven stored figures and not one numeral among them. Every figure is client-reported or project-reported, and we audited none of them. The table below transcribes all of it. These describe businesses at different stages, in different markets, measuring different things, and arithmetic across the two columns would be meaningless.

What does the way we filed these records tell you?

One more layer, because it shapes everything above: these are catalogue entries we wrote, not instrumented logs. Four of the seven Firebase projects name Firebase in the category string we filed them under, against one of three Supabase projects. Augment Fit is filed as React.js Frontend and Afriva as Next.js and Microservices, though both run on Supabase, so anyone counting by category alone would reach different numbers than we do. Twenty-two of the 25 records are flagged as featured, including all three Supabase builds and five of the seven Firebase ones, which makes this a showcase rather than a census of everything we shipped. The only date field is the record's own created_at timestamp. It takes four distinct values across 25 projects and puts all three Supabase records on a single day, so it marks when we wrote the entry, not when we delivered the work. No chronology is available here.

What should a team take from a portfolio of this size?

Take the shape, not the verdict. With 25 projects overall and a three-versus-seven split inside the comparison, nothing here establishes that either backend is faster, cheaper, more reliable or better suited to marketplaces in general. What it does establish is a real pattern in one agency's decisions across shipped products. When the brief was a role-separated web dashboard with transactional workflows, we reached for Supabase, and it was the whole data layer. When the brief was a mobile-first product needing real-time sync, push notifications or drop-in authentication next to an existing AWS backend, we reached for Firebase, and it was one component among several. Both patterns produced live products with client-reported traction. If your brief resembles Afriva, the Supabase precedent in our record is the relevant one. If it resembles Koor or Food Magnet, the Firebase precedent is. Neither replaces a load test, a cost model, or a spike built against your own data.

Limitations

• n=25 projects from a single agency, with only 3 Supabase and 7 Firebase builds in the comparison; group sizes this small cannot support a general recommendation.
• Backend selection was driven by client briefs, budgets and pre-existing systems we did not control, so the two groups are not comparable populations and were never randomly assigned.
• All outcome figures are client-reported or project-reported from a free-form list of figures we keep with each project. We did not audit, instrument or independently verify any of them, and the projects launched at different times in different markets.
• Outcome reporting is uneven across the groups. Three of the seven Firebase builds record no numeral at all, so the metrics table under-represents that group by construction and cannot be read as a scoreboard.
• Backend attribution relies on tags and tech stack fields, which are self-maintained. CEDMAT and ConstrActive name a backend only in prose and are reported separately rather than merged into the headline counts.
• Waitmate's narrative names React Native for mobile accessibility although its tags and tech stack do not, so the Supabase group's zero for native mobile frameworks holds only under the tags-and-tech-stack rule, and we state both readings.
• Three28 Creator Platform stores an Apple App Store URL in its android field with an empty ios field, so the portfolio-wide 8 Android and 6 iOS reproduce our fields rather than reality. Three28 is in neither backend group.
• The source facts file gives conflicting counts for AWS (9 vs 8) and React.js (8 vs 7) under two different counting rules, so we published neither figure. Supabase, Firebase, Next.js, Node.js and NestJS counts agreed under both rules.
• 22 of the 25 records are flagged as featured, so this is a curated showcase, not a complete census of what the agency has shipped.
• The only date field is the record's created_at timestamp, which marks when the catalogue entry was written, not when the work was delivered. No project ordering or timeline analysis is possible.
• The angle we set out to test assumed ConstrActive was a Supabase marketplace build. The records show it names Supabase only in narrative text and is a CRM and subscription platform, not a marketplace, so it is excluded from the marketplace counts.
• Records describe finished state, not process. Nothing captures what was tried and abandoned, what was migrated, or what a build cost to maintain after handover.

What this data cannot answer

• Which backend is faster. No load tests, latency measurements or throughput benchmarks were run on any project in this dataset.
• Which backend is cheaper to run. No hosting invoices, pricing tiers or cost-per-user figures exist in these records, at any scale.
• How development time or effort compared. No developer-hours, sprint counts, timelines or team sizes are recorded for any project.
• How the two behave under scale or contention. Nothing here measures concurrent writes, hot partitions, query performance on large tables, or read amplification.
• Whether row-level security or Firestore security rules proved easier to get right. No security review findings or incident records are in the dataset.
• How migration between the two goes. No project in our record moved from one backend to the other, so we have no migration experience to report.
• Whether either choice caused the client-reported outcomes. With no control group and no baseline, the revenue, rating and volume figures cannot be attributed to a backend decision.
• Whether Supabase can back a native mobile app in practice. Waitmate's prose names React Native but the record shows no store listing, and no other Supabase build names a mobile framework, so we have no shipped example either way.
• What Firebase was actually doing on Bondly. The record names it in tags, tech stack and category but never states its role, and credits OneSignal for notifications.
• How either compares to the alternatives we did not use here, such as raw Postgres, PlanetScale, AWS Amplify or Appwrite.
• What happens to marketplace builds beyond our size range. Our largest client-reported marketplace figures are 1,245 vendors and 12k+ listings; we cannot speak to behaviour above that.
• Bundle size, cold-start behaviour or offline sync quality on mobile. These were never captured in any project record.