Supabase vs Firebase for Marketplace Backends: What 10 Portfolio Builds Show

How many builds in the portfolio use Supabase, and how many use Firebase?

Across the 26 portfolio entries, ten name one of these two backends in their tags or tech stack: eight Firebase, two Supabase. No entry uses both. That split is the first finding, and the Supabase side is very small. Waitmate, a hospitality admin demo, is not on it: the public demo is a Next.js app on Firebase.

Three further entries name one of the backends only in their written description, not in their tags or tech stack: Outstride and CEDMAT on Firebase, and ConstrActive, a construction CRM built on GoHighLevel, Supabase and Stripe. Of the three, only CEDMAT has a public link, on Google Play. Counting them, the split becomes ten Firebase to three Supabase, still with no overlap. Every other figure below comes from the ten tagged entries.

Which backend did the marketplaces in the portfolio use?

Seven of the 26 products are two-sided marketplaces, where one set of users lists, sells or provides and another buys or books. That grouping is a classification made for this article from what each product is, not a field in the data. Four of the seven name Firebase: Pastel, an antiques marketplace that runs on Sharetribe with Firebase in its tech stack; Koor, food delivery from home chefs; Bondly, pet care; and AgroBridge, an agricultural marketplace. One sits on Supabase: Afriva, a multi-vendor marketplace with separate admin, manager, seller and buyer roles. Two use neither: the AI E-Commerce Ecosystem runs on Next.js with Docker and Kubernetes, and Dooz Inspected Cars on a NestJS backend.

So in this portfolio Firebase appears in the marketplace work four times to Supabase's once, and on Pastel it is not the marketplace engine at all; Sharetribe is. With seven products in the group, that ratio describes this portfolio and nothing more. Afriva is the only one of the seven built around four distinct roles, each with its own dashboard. Of the four marketplaces naming Firebase, Pastel, Koor and Bondly have a public link; AgroBridge has no client and no public link.

Does the relational versus document data model show up in these builds?

Not directly, and this article will not pretend otherwise. No entry names Firestore, Realtime Database or PostgreSQL in its tags or tech stack, so the data-model debate that dominates most comparison articles is absent from the portfolio's own fields. Supabase is managed PostgreSQL underneath, and Afriva's project description names PostgreSQL through Supabase; Firebase's databases are document stores.

What the entries do show is a difference in product shape, with one exception that matters. Both Supabase builds are dashboards: Afriva gives each of its four roles a dashboard over inventory, orders and delivery, and Augment Fit is an admin panel for a fitness platform. But Waitmate, a hospitality admin dashboard for reservations, tables and staff, runs on Next.js and Firebase, so dashboards are not a Supabase-only shape here. The other Firebase builds are mostly consumer-facing: a coffee-shop site, a delivery app, a food-truck finder, a pet-care marketplace, an antiques marketplace. Those are patterns in what the products are. They are consistent with different product shapes, but they measure neither database engine.

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

In this portfolio, usually the latter. Six of the eight Firebase entries list Firebase in their tech stack. The other two, Koor and Pathana, carry the Firebase tag while declaring a different primary stack: React Native with NestJS, and Next.js with Node.js. Where an entry says what Firebase was doing, it is specific: Food Magnet's tech stack reads "Firebase (Realtime & Notifications)", next to AWS Lambda functions for the backend and Stripe for payments; on Koor, Firebase handles the real-time order updates beside a NestJS backend and Elasticsearch search; on Pathana, it handles authentication and data. On Pastel, Firebase sits next to Sharetribe, which runs the marketplace itself. Bondly names Firebase in its tags, tech stack and category, while its backend centres on Node.js and MongoDB, with OneSignal for push notifications.

Four of the eight Firebase entries also name AWS. Supabase appears differently: both Supabase entries list it in their tech stack, it is the data layer in each, and neither names AWS anywhere in its fields.

Which platforms does each backend's group link to?

Of the 26 entries, 16 link to at least one public surface: 12 web, seven Google Play, seven App Store. Inside the two backend groups the pattern diverges. Neither Supabase build has a production link: Afriva is a demo build on vercel.app, and Augment Fit has no public link. Neither has an app store listing.

The Firebase group is more mixed: six of eight link a web address, two of them the Coffee Shop and Waitmate builds on vercel.app, and three of eight link a store listing, with Food Magnet and Pastel on both Google Play and the App Store and Koor on Google Play. AgroBridge has no public link. The likeliest explanation for the split is what these particular products were built to be, not anything about the backends.

What frontend stacks and hosting did each backend pair with?

Across the whole portfolio, counted from tags and tech stack, Next.js appears in six entries, React Native in six, Flutter in six, Node.js in nine and NestJS in five. Inside the backend groups the pairings are distinct. Both Supabase builds pair with the React family on the web: React.js on Augment Fit, and Next.js on Afriva, which runs Next.js 15 with the App Router. Neither names React Native or Flutter.

The eight Firebase builds spread wider: Next.js on Coffee Shop, Waitmate and Pathana; React Native on AgroBridge and Koor; Flutter with a React.js admin dashboard on Food Magnet; a Node.js service on Bondly; and on Pastel, Sharetribe with an iOS app. Hosting, as far as the links show, does not separate the groups: the one Supabase web link is a build on vercel.app, as are two of the six Firebase web links, and no entry names Vercel in its tags or tech stack.

What does the way the entries are filed tell you?

One more layer, because it shapes everything above: these are portfolio entries written by hand, not instrumented logs. Three of the eight Firebase entries name Firebase in their category label, against neither of the two Supabase entries. Augment Fit is filed as React.js Frontend and Afriva as Next.js & Microservices, though both run on Supabase, so anyone counting by category alone would miss the Supabase side entirely.

Twenty-three of the 26 entries are flagged as featured, including both Supabase builds and six of the eight Firebase ones, which makes this a showcase rather than a census of everything Sameem has worked on. The only date on an entry is its creation timestamp. Across the 26 entries it takes five distinct dates, and both Supabase entries were created on the same day, so it marks when the entry was written, not when the work was done. No chronology is available here.

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

Take the shape, not the verdict. With 26 entries overall and a two-versus-eight 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 show is a pattern in the products themselves. Where the product was a role-separated web dashboard with transactional workflows, as on Afriva, Supabase was the whole data layer. Where the product was mobile-first and needed real-time sync, push notifications or drop-in authentication next to AWS services, as on Food Magnet and Koor, Firebase was one component among several. Waitmate shows the pattern is not a rule: a dashboard can sit on Firebase too.

Read those choices as precedents rather than as DevoraX's house view. If your brief resembles Afriva, the Supabase precedent 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=26 entries from one portfolio, with only 2 Supabase and 8 Firebase builds in the comparison; group sizes this small cannot support a general recommendation, and 2 builds cannot characterise Supabase at all.
• Backend selection was driven by briefs, budgets, employers and pre-existing systems, so the two groups are not comparable populations and were never randomly assigned.
• The portfolio holds no outcome, cost or performance data for any build, so nothing here can be read as a scoreboard.
• Backend attribution relies on hand-maintained tags and tech stack lists. Outstride, CEDMAT and ConstrActive name a backend only in their written description, so they are reported separately rather than merged into the headline counts.
• The marketplace group is a classification of what each product is, made for this article, not a field in the data.
• 23 of the 26 entries are flagged as featured, so this is a curated showcase, not a complete census.
• The only date on an entry is its creation timestamp, which marks when the entry was written, not when the work was done. No timeline analysis is possible.
• Entries 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 build in this dataset.
• Which backend is cheaper to run. No hosting invoices, pricing tiers or cost-per-user figures exist in the portfolio, at any scale.
• How development time or effort compared. No developer-hours, sprint counts, timelines or team sizes are recorded for any entry.
• 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 build in the portfolio moved from one backend to the other.
• Whether either backend affected any product's commercial results. The portfolio holds no outcome data, no control group and no baseline.
• Whether Supabase can back a native mobile app in practice. Neither Supabase build names a mobile framework, so the portfolio has no example either way.
• How either compares to alternatives not used here, such as raw Postgres, PlanetScale, AWS Amplify or Appwrite.
• Bundle size, cold-start behaviour or offline sync quality on mobile. These were never captured in any entry.