TL;DR verdict
This guide recommends Supabase when a startup needs Postgres, SQL migrations, auth, storage, realtime, and a documented local stack. Choose Firebase when Firestore's document model, client SDKs, and Emulator Suite fit the product. Choose AWS Amplify Gen 2 when TypeScript-defined AWS resources and a per-developer cloud sandbox fit the team's operating model. These are conditional fits, not a universal ranking.
This page keeps the three-platform decision as its center of gravity and answers the implementation questions that change that decision: local development, Amplify sandbox behavior, Lambda functions, and group-based authorization rules.
Prices and plan names change, and quotas and product capabilities can change too. The official sources in this guide were checked on 2026-08-20; verify current vendor documentation and pricing before committing a launch architecture or promising a customer-specific backend capability.
At that check, Supabase listed Free at $0 per month and Pro from $25 per month; Firebase listed Spark as a no-cost plan and Blaze as pay as you go. Those labels and entry prices are snapshots, not a substitute for modeling reads, writes, storage, bandwidth, functions, and auth usage.
Key Takeaways
- Supabase is this guide's default for a relational web SaaS when SQL migrations, tenant tables, billing records, and Postgres reporting match the product.
- Firebase fits mobile and event-driven products when Firestore documents, client SDKs, Auth, Functions, and the Emulator Suite match the data and deployment model.
- Amplify Gen 2 defines backend resources in TypeScript and provisions AWS resources through sandbox and deployment workflows, making AWS operations part of the implementation surface.
- Local development is the biggest practical split: Supabase runs a local Docker stack, Firebase has a broad local Emulator Suite, and Amplify Gen 2 leans on cloud sandboxes rather than a full local clone of Cognito, AppSync, DynamoDB, S3, and Lambda.
- Subscriptions and billing still belong in your app. None of these platforms replaces Stripe, Polar, Paddle, or Lemon Squeezy entitlement modeling, webhook idempotency, plan downgrades, or seat reconciliation.
- Switching cost is broader than vendor ownership. Firestore documents, generated AWS resources, auth identities, storage, functions, and Postgres schemas or RLS policies can all require migration work.
At-a-glance startup backend matrix
| Startup decision | Supabase | Firebase | Amplify Gen 2 | StarterPick recommendation |
|---|---|---|---|---|
| Web SaaS MVP fit | Postgres, Auth, Storage, Realtime, Edge Functions, and SQL migrations. | Fits when data is document-shaped and the team already uses Firebase. | Fits when the team accepts AWS services and cloud sandbox workflow. | Start with the data model and operating constraints, then compare implementation time. |
| Auth and teams | Supabase Auth plus Postgres RLS; app still owns tenant and billing policy. | Firebase Auth plus Security Rules; Firestore structure and application authorization still need review. | Cognito-backed auth plus Gen 2 authorization rules in TypeScript. | Test tenant, role, and billing authorization in application code for every option. |
| Realtime | Postgres-backed channels for database changes and broadcasts. | Firestore listeners and Realtime Database patterns. | AppSync GraphQL subscriptions for AWS-native realtime. | Choose the mechanism that matches the product's data model and access rules. |
| Subscriptions and billing | App-owned billing tables alongside Postgres domain data are straightforward. | Billing state must be modeled around documents and Cloud Functions. | Billing state usually lands in DynamoDB/RDS plus Lambda/EventBridge-style workflows. | Keep Stripe/Polar/Paddle entitlement truth in your app regardless of provider. |
| Local development | Local Supabase CLI stack with Postgres, Auth, Storage, Realtime, Studio, and functions. | Emulator Suite for Auth, Firestore, Functions, Storage, Hosting, and UI inspection. | Personal cloud sandbox with real AWS resources; not a full local emulator suite. | Use Supabase/Firebase when offline/local repeatability matters; use Amplify when AWS fidelity matters more. |
| Lock-in and exit path | Postgres can simplify data export, while Auth, Storage, Realtime, functions, and RLS still require migration planning. | Firestore documents, Security Rules, and Firebase SDK usage shape the migration. | Generated AWS resources, IAM, Cognito, AppSync, and service configuration shape the migration. | Score the concrete data, identity, storage, function, and operational seams. |
| Launch work | Often direct for SQL-first Next.js products. | Direct for products that fit Firebase's client SDK and rules model. | Direct for AWS-aligned teams; more setup for teams new to Cognito, AppSync, and IAM. | Validate with the same representative vertical slice. |
Evidence cards
Supabase evidence card
Supabase's official documentation and pricing position the platform as a Postgres-centered backend with local development tooling, Auth, Row Level Security, Realtime, Storage, Edge Functions, and plan-based hosted infrastructure. That combination maps cleanly to SaaS starter-kit work: tenants, teams, invoices, subscription rows, admin reporting, and SQL-based migrations all belong naturally in the same relational model.
Implementation read: Supabase is not automatically secure because it has RLS. A production starter must define and test policies for owner/admin/member roles, billing admins, service-role access, webhook writes, and background jobs. But the interface is deep for SaaS: one Postgres-backed seam can handle app data, policies, reporting, and migration history.
Firebase evidence card
Firebase's official Firestore and Emulator Suite documentation supports a different operating model: client SDKs, document collections, local emulators, Functions, and Auth. It fits products whose access patterns and offline behavior map cleanly to Firestore documents; that fit must be tested rather than inferred from a mobile label alone.
Implementation read: Firebase becomes expensive or awkward when a B2B SaaS product needs relational joins, ad hoc reporting, tenant-level billing queries, and migration discipline. The decision should be based on product shape, not age. Firebase remains strong where its document/offline/event model is the product fit.
Amplify Gen 2 evidence card
AWS Amplify Gen 2's official docs describe a code-first backend where data, auth, storage, and functions are defined in TypeScript and provisioned as AWS resources. The sandbox workflow creates a personal cloud backend for each developer, and authorization examples use TypeScript rules such as allow.group to express group-based access.
Implementation read: Amplify Gen 2 is a credible startup backend when AWS is the long-term home, but it is not a drop-in local Firebase emulator replacement. Founders should evaluate Cognito, AppSync, DynamoDB, S3, Lambda, IAM, and sandbox/deployment workflows as the actual implementation surface.
Launch stack table
| Launch layer | Supabase-first stack | Firebase-first stack | Amplify Gen 2-first stack | Required startup check |
|---|---|---|---|---|
| App database | Postgres tables, migrations, RLS policies, SQL reporting. | Firestore collections/documents, security rules, denormalized reads. | DynamoDB/AppSync model definitions, or AWS data services behind Amplify. | Write the first tenant/team/billing schema before picking the provider. |
| Auth | Supabase Auth with JWT claims and RLS policy integration. | Firebase Auth with rules and server-side verification where needed. | Cognito-backed Amplify Auth. | Test signed-out, member, admin, billing admin, suspended, and deleted-user states. |
| Realtime | Supabase Realtime channels over Postgres changes or broadcasts. | Firestore listeners or Realtime Database. | AppSync GraphQL subscriptions. | Simulate multi-tab/team updates and permission changes, not just happy-path messages. |
| Functions | Supabase Edge Functions for lightweight backend endpoints. | Cloud Functions for Firebase. | Lambda functions defined through Amplify. | Verify secrets, retries, logs, cold-start tolerance, and webhook idempotency. |
| File storage | Supabase Storage with policies. | Cloud Storage for Firebase. | S3 via Amplify Storage. | Test private files, signed URLs, tenant boundaries, and deletion on account closure. |
| Local/dev workflow | supabase start, migrations, local Studio, local functions. | firebase emulators:start, emulator UI, import/export where needed. | npx ampx sandbox with personal AWS cloud resources. | Decide whether local repeatability or cloud fidelity matters more to the team. |
| Deployment | Hosted Supabase project plus app hosting on Vercel/other. | Firebase projects plus app hosting/Cloud Functions as needed. | Amplify sandbox/promote/deploy workflows and AWS resource ownership. | Separate local, preview, staging, and production credentials. |
| Exit path | Standard Postgres dump/migration path is comparatively clear. | Export and transform document data; SDK/rules rewrite likely. | AWS resources are durable, but app code is coupled to AWS service interfaces. | Keep provider IDs as adapters; keep product domain IDs in your app. |
Billing and subscription ownership matrix
| Subscription/billing event | What the backend platform helps with | What your SaaS code must still own | Failure mode to test |
|---|---|---|---|
| Customer signs up | Auth identity, session, profile primitives. | Trial creation, default plan, subscription owner, workspace creation. | A user gets app access without a billing workspace or tenant record. |
| Team member invited | User identity and sometimes membership primitives. | Seat counting, invite expiry, role limits, paid-seat timing. | Charged seats do not match active members. |
| Plan upgraded | Database and function hooks can store/update state. | Entitlement truth, webhook idempotency, upgrade timing, invoice reconciliation. | Paid features unlock before payment succeeds or stay locked after upgrade. |
| Plan downgraded | Provider can host data but does not decide product policy. | Feature removal, data retention, usage limits, grace periods. | Enterprise features stay active after downgrade. |
| Usage-based billing | Events can be stored or processed. | Meter definition, event dedupe, reporting, customer-visible totals. | Duplicate events overcharge or missing events undercharge. |
| Account deleted | Auth provider can remove/disable user identity. | Data retention, subscription cancellation, audit history, workspace ownership. | Deleting auth breaks billing or leaves orphaned paid resources. |
The backend platform is infrastructure, not a subscription engine. A serious starter keeps billing and entitlement logic in app-owned code whether the user table lives next to Postgres RLS policies, Firestore documents, or AWS-backed data models.
Local development and emulator reality
Search demand around "Amplify Gen 2 local emulator" is easy to misread. Amplify Gen 2's core workflow is a cloud sandbox, not a complete local emulator suite. That is a valid engineering choice: you test against real AWS services in a developer-specific environment. It also means the team needs AWS credentials, cloud-resource hygiene, and a strategy for offline work.
# Supabase: local stack, Docker, migrations, local functions
supabase start
supabase db reset
supabase functions serve
# Firebase: local emulators and Emulator UI, commonly including localhost:4000
firebase emulators:start
# Amplify Gen 2: personal cloud sandbox using real AWS resources
npx ampx sandbox
For an early SaaS team, local development should be scored as an operational requirement:
| Requirement | Best fit | Why |
|---|---|---|
| Reproducible SQL schema in every PR | Supabase | Migration files and local Postgres make reviewable schema changes natural. |
| Broad local service emulation | Firebase | The Emulator Suite covers Auth, Firestore, Functions, Storage, Hosting, and more. |
| Highest fidelity to production AWS services | Amplify Gen 2 | Sandbox resources are real AWS resources rather than local mocks. |
| Offline-first development | Firebase or Supabase | Amplify sandbox needs cloud access for the normal workflow. |
| Debugging IAM/Cognito/AppSync/Lambda integration | Amplify Gen 2 | The cloud sandbox exposes the real seams you will deploy. |
Practical Amplify Gen 2 authorization notes
Do not rewrite this page around code snippets, but the query cluster does deserve one practical answer. Amplify Gen 2 authorization rules are defined in TypeScript near the data model. A typical group-based rule looks like this:
import { a, defineData, type ClientSchema } from '@aws-amplify/backend'
const schema = a.schema({
Project: a.model({
name: a.string().required(),
tenantId: a.string().required(),
}).authorization((allow) => [
allow.authenticated().to(['read']),
allow.group('Admins').to(['create', 'update', 'delete']),
]),
})
export type Schema = ClientSchema<typeof schema>
export const data = defineData({ schema })
That pattern is useful for SaaS starters because it keeps backend authorization in versioned TypeScript instead of scattered dashboard configuration. It is not enough by itself. You still need app-owned tenant checks, billing entitlement checks, audit logs, tests for role changes, and a safe migration path when the product moves beyond simple groups.
Use Amplify Gen 2 when the team wants TypeScript-defined AWS infrastructure and accepts Cognito, AppSync, DynamoDB or S3, Lambda, IAM, and cloud sandbox operations as ongoing responsibilities.
Cost to customize
| Customization area | Supabase likely effort | Firebase likely effort | Amplify Gen 2 likely effort | Why it matters |
|---|---|---|---|---|
| Tenant/team data model | Low/medium | Medium/high | Medium/high | Relational tenant tables are simpler than retrofitting joins into documents or access-pattern tables. |
| Auth UI and sessions | Medium | Low/medium | Medium | Each platform supplies identity primitives; SaaS roles still need application policy and tests. |
| RLS/security rules | Medium | Medium | Medium | Every platform requires policy tests; the syntax differs, but the risk is the same. |
| Subscription/billing integration | Medium | Medium/high | Medium/high | Billing truth must stay app-owned and tied to your provider's data model carefully. |
| Local/preview environments | Low/medium | Low/medium | Medium/high | Supabase/Firebase have strong local workflows; Amplify requires cloud sandbox discipline. |
| Reporting/admin dashboards | Low | Medium/high | Medium/high | SQL makes ad hoc reporting and admin joins easier for most SaaS teams. |
| Migration away later | Low/medium | High | Medium/high | Postgres is easier to move; document and AWS-service models need more transformation. |
There is no source-backed cheapest option without an application workload and a labor model. A relational B2B SaaS may require less custom data work on Supabase; a Firestore-shaped or AWS-first product may require less integration work on Firebase or Amplify. Measure both platform usage and engineering ownership for the intended workload.
Startup decision scorecard
This is a requirements matrix, not a performance benchmark. Mark a row only after the team verifies it in a representative prototype.
| Dimension | Supabase evidence | Firebase evidence | Amplify Gen 2 evidence |
|---|---|---|---|
| Relational web SaaS | Postgres and SQL migrations are first-class. | Firestore uses a document model. | The generated data layer maps to AWS resources and access patterns. |
| Mobile and offline workflows | Test the client and caching behavior your app needs. | Firestore and the Firebase client SDKs are designed for web and mobile application workflows. | Test the selected client libraries and offline requirements against the generated API. |
| AWS governance | Requires a separate AWS integration strategy if AWS services are central. | Requires a separate AWS integration strategy if AWS services are central. | Cognito, AppSync, IAM, Lambda, and other AWS resources are part of the normal surface. |
| Local development | Supabase documents a local stack. | Firebase documents the Local Emulator Suite and UI. | Amplify documents a per-developer cloud sandbox using AWS resources. |
| Reporting and SQL | Postgres supports SQL reporting directly. | Reporting depends on Firestore exports, application projections, or connected analytics services. | Reporting depends on the generated data model and selected AWS analytics path. |
| Migration planning | Include Auth, Storage, Realtime, functions, and RLS policies as well as Postgres data. | Include documents, indexes, Security Rules, identities, storage, functions, and SDK usage. | Include generated resources, identities, IAM, APIs, storage, functions, and deployment configuration. |
| Operations | Measure database, auth, storage, realtime, and function ownership. | Measure rules, indexes, functions, quotas, and emulator-to-production differences. | Measure credentials, sandboxes, IAM, service configuration, cost controls, and observability. |
Use the scorecard to design a proof of concept, not to replace one. Build the same vertical slice in each finalist: sign-up, create a workspace, invite a member, create a billable record, update it in realtime, upload a file, run one background function, and downgrade the subscription. Record implementation time, service usage, failure modes, and migration surfaces.
Methodology
This refresh used current primary sources retrieved on 2026-08-20: Supabase pricing, local-development, RLS, and Realtime documentation; Firebase pricing, Firestore, and Emulator Suite documentation; AWS Amplify Gen 2 quickstart, authorization, functions, and sandbox documentation; plus the Wave 5 GSC and route-health artifacts for page intent and route-contract context. The GSC evidence showed startup comparison intent and practical Amplify Gen 2 local/emulator and group-rule queries, so the page was refreshed as a decision guide with one focused practical section rather than converted into a narrow code-snippet page.
The scoring is implementation-oriented. A high score means the platform's documented product surface maps cleanly to the work a SaaS starter must ship: auth, tenant authorization, realtime updates, file storage, subscription ownership, preview/prod separation, local development, and migration discipline. It does not mean a provider is universally better for every startup.
Source-backed FAQ
Is Supabase better than Firebase and Amplify for SaaS startups?
This guide recommends Supabase when Postgres, SQL migrations, RLS, Auth, Storage, Realtime, and a local stack match the application. Firebase may fit document-shaped or offline-oriented products; Amplify Gen 2 may fit AWS-first teams. The recommendation changes when those requirements change.
Does Amplify Gen 2 have a local emulator like Firebase?
Not in the same sense. Firebase's Emulator Suite is a broad local emulator workflow. Amplify Gen 2's normal development workflow is a personal cloud sandbox created with npx ampx sandbox, so you test against real AWS resources in an isolated dev environment. That improves AWS fidelity but requires cloud access and AWS operational awareness.
How should I think about Amplify allow.group rules?
Treat them as backend authorization rules, not as your complete SaaS policy. They are useful because they live in versioned TypeScript alongside the data model. You still need app-owned tenant IDs, subscription checks, billing entitlements, role-change tests, and logs for privileged actions.
Which option has the lowest lock-in?
None has a single lock-in score. Supabase centers Postgres but still has platform-specific Auth, Storage, Realtime, functions, and RLS policy work. Firebase migrations must account for Firestore documents, Security Rules, identity, and SDK usage. Amplify migrations must account for the generated AWS resources, IAM, Cognito, AppSync, storage, and functions.
Which option is cheapest?
It depends on usage and operations. On August 20, 2026, Supabase listed Free at $0 per month and Pro from $25 per month, while Firebase listed Spark as a no-cost plan and Blaze as pay as you go. Model expected reads, writes, storage, bandwidth, function calls, auth users, underlying AWS services, and engineering ownership from current vendor pricing pages; do not project a bill from plan labels alone.
Can I use these platforms with Stripe or another billing provider?
Yes. But treat Stripe, Polar, Paddle, Lemon Squeezy, or another billing system as a separate app-owned integration. The backend platform stores users and data; your application still owns subscription state, entitlements, usage meters, webhook retries, downgrades, cancellations, and audit history.
Related guides
- Supabase RLS guide for SaaS boilerplates — deeper tenant, teams, and billing-policy review for Supabase-first starters.
- Supabase vs Firebase vs Appwrite starter guide — adjacent BaaS comparison when Appwrite is on the shortlist.
- Convex vs Supabase vs Firebase — realtime/database decision context when Convex is an option.
- Neon vs Convex for SaaS starters — file-backed or serverless database alternatives for teams not choosing a full BaaS.
- Usage-based billing guide — subscription and metering decisions that should remain separate from auth provider records.
- SaaS boilerplate security checklist — policy, webhook, secret, and rate-limit checks before production.
- Best SaaS boilerplates with Supabase — starter-kit inventory when you decide Supabase is the right default.
- Next.js SaaS tech stack guide — wider stack decisions beyond the backend platform.
Source notes
- Supabase pricing page, retrieved 2026-08-20. Used for pricing freshness and hosted-plan caveats; verify current quotas before purchase or launch.
- Supabase local development documentation, retrieved 2026-08-20. Used for local CLI, Docker-stack, migration, and local-function workflow discussion.
- Supabase Row Level Security documentation, retrieved 2026-08-20. Used for auth/RLS implementation caveats.
- Supabase Realtime documentation, retrieved 2026-08-20. Used for realtime capability positioning.
- Firebase pricing page, retrieved 2026-08-20. Used for pricing freshness and pay-as-you-go caveats; verify current rates before launch.
- Firebase Emulator Suite documentation, retrieved 2026-08-20. Used for local emulator and Emulator UI discussion.
- Cloud Firestore documentation, retrieved 2026-08-20. Used for document-database positioning and data-model caveats.
- AWS Amplify Gen 2 quickstart documentation, retrieved 2026-08-20. Used for TypeScript-first backend and AWS-resource workflow positioning.
- AWS Amplify authorization documentation, retrieved 2026-08-20. Used for
allow.groupand authorization-rule discussion. - AWS Amplify functions documentation, retrieved 2026-08-20. Used for Lambda/function implementation context.
- AWS Amplify sandbox documentation, retrieved 2026-08-20. Used for cloud sandbox versus local emulator framing.
- Wave 5 route-health artifact, retrieved 2026-08-20. Used for canonical public/raw route contract and the note that
localhost:4000is a Firebase emulator reference, not preview-host leakage.