Originally published at devtoolpicks.com
Convex is a good product. That needs saying up front, because most "alternatives" posts start by implying the incumbent is broken. It isn't. Reactive queries that update your UI automatically, a genuinely pleasant TypeScript developer experience, and a real free tier that doesn't feel like a trap. Plenty of solo developers ship real products on Convex for months without hitting a wall.
The switch trigger isn't a flaw. It's a pricing model and a data model that fit some teams and not others, and knowing which camp you're in before you commit six months of schema decisions is worth the ten minutes this post takes to read.
Quick verdict
| Tool | Best for | Price | Rating |
|---|---|---|---|
| Supabase | Postgres, biggest ecosystem, flat team pricing | Free, then $25/mo flat | 4.5/5 |
| Firebase | Already on Google Cloud, mobile SDKs | Free (Spark), then pay-as-you-go (Blaze) | 3.5/5 |
| Nhost | Supabase alternative with GraphQL default | Free, then $25/mo | 4/5 |
| PocketBase | Full ownership, single binary, self-hosted | Free forever, VPS cost only | 4/5 |
Why does the switch trigger matter more than the feature list?
Every backend-as-a-service platform looks similar on a features page: auth, database, storage, real-time, functions. The decision that actually matters happens on the pricing page and in the data model, not the marketing page.
Convex's core tension is this: the developer experience is genuinely excellent for a solo builder on the free tier, and then Professional charges $25 per developer per month. One developer, $25. Three developers, $75. That's a real number that grows with your team, unlike a database bill that grows with usage.
The second tension is the data model. Convex is document-oriented with TypeScript functions instead of SQL. No ALTER TABLE, no existing ORM compatibility, no dropping into psql to debug a query at 2am. For teams that want that control, or that already have SQL migrations and tooling built up, this is the actual switch trigger, not price.
What does the per-seat model actually cost at real team sizes?
Convex Professional's $25 per developer per month sounds reasonable until you run the math past one person. At one developer it's $25, tying Supabase and Nhost exactly. At three developers it's $75. At five, $125. Supabase and Nhost's Pro plans stay flat at $25 regardless of headcount, since they bill the project's compute and storage, not the people touching it.
That means a three-person team choosing Supabase over Convex saves $50 a month, and a five-person team saves $100 a month, purely from the pricing model, before comparing a single feature. It's not a reason to avoid Convex outright. Small solo teams pay the same either way, and Convex's Business tier at $2,500/month minimum only kicks in at 50-plus developers, well past where most indie products live. But it's the first number to check before assuming any of these four alternatives are automatically cheaper.
Is Supabase the safe default?
Supabase is the most direct answer to both Convex tensions. It's Postgres, so SQL, migrations, and every ORM you already know works. And pricing is per project, not per developer.
Free costs $0: 500MB database, 50,000 monthly active users, 1GB file storage, and the project pauses after 7 days of inactivity. Pro is $25/month flat, including a $10 monthly compute credit that covers a Micro instance, plus 8GB database, 100,000 MAUs, and 100GB storage. Team jumps to $599/month with SOC 2 and ISO 27001 compliance, SSO, and 14-day backups. Enterprise is custom.
The bundle is the same shape as Convex: Postgres with Row Level Security, Auth, Storage, Edge Functions, and Realtime, all under one subscription. The difference that matters for a growing team is that Pro stays at $25/month whether it's one developer or five, since compute is billed by instance size, not headcount.
Pros: Postgres means zero lock-in risk on the data layer, the largest ecosystem of any tool here, and flat pricing that doesn't punish adding teammates. Row Level Security policies are enforced at the database level, so the same rules apply whether a request comes from your app, a script, or someone poking around with psql directly.
Cons: compute is provisioned, not serverless, so you pay for the instance around the clock even during idle periods, unlike Convex's pure usage billing. Free tier projects pause after a week of no traffic, which has caught people off guard mid-demo. Realtime subscriptions require deliberate setup on each table rather than working automatically the way every Convex query does.
Who should skip it: teams that specifically want Convex's reactive query model without writing their own subscription logic. Supabase's Realtime is good but it's an add-on to Postgres, not baked into every query the way Convex's reactivity is.
Does Firebase still make sense?
Firebase is the oldest name in this comparison and the one most likely to already be part of your stack if you build mobile apps.
Spark is the free plan: no credit card required, with genuinely useful daily quotas across Firestore, 50,000 reads, 20,000 writes, and 20,000 deletes per day, plus 1GB stored. Blaze is pay-as-you-go on top of those same free quotas: $0.06 per 100,000 reads, $0.18 per 100,000 writes, $0.02 per 100,000 deletes past the daily free amount.
Here's the honest 2026 wrinkle worth knowing before you build on Spark: since February 3, 2026, Cloud Storage for Firebase requires a linked Blaze billing account to create a bucket at all, even if your actual usage stays inside Google Cloud Storage's free tier of 5GB and 100GB of egress. It's a policy change, not a stealth price increase, but it means "free tier" no longer means "no credit card," the moment file storage is involved.
Pros: the deepest mobile SDK support of anything here, tight integration with the rest of Google Cloud, and a free tier that stays genuinely free if usage stays modest.
Cons: no hard spending cap on Blaze. A runaway Cloud Function or an unbounded query can turn a $12 bill into something much larger overnight, and the billing model is the least predictable of the four alternatives here.
Who should skip it: teams outside the Google ecosystem who don't need Firebase-specific tooling like Crashlytics or Remote Config. The NoSQL document model and per-operation billing are both harder to reason about than Supabase or Nhost's flat-rate Postgres.
Is Nhost just Supabase with GraphQL?
Close, and that's the honest pitch for Nhost. Managed Postgres, Auth, Storage, and serverless functions, with Hasura's GraphQL engine wired in by default instead of Supabase's REST-first approach.
Pricing tracks Supabase closely enough that it's worth comparing side by side. Starter is $0: 1GB database, 1GB storage, 5GB egress, one project that pauses after a week idle, same pattern as Supabase Free. Pro is $25/month with a $15 compute credit included, 10GB database, 50GB storage, and 50GB bandwidth. Team is $599/month with SOC 2 Type II, email support with an SLA, and a dedicated Discord channel.
Pros: if your frontend is already GraphQL-first, Nhost skips the step of bolting Hasura or a GraphQL layer onto Postgres yourself. Git-based deploys and infrastructure-as-code via the Nhost CLI are solid for teams that want their backend config in version control. Because it's Postgres underneath, the same zero-lock-in argument that applies to Supabase applies here too.
Cons: smaller ecosystem and community than Supabase, so fewer third-party integrations, tutorials, and Stack Overflow answers when something breaks. HIPAA compliance is listed as coming soon rather than available now, worth checking before committing if that matters to your product. The Hasura layer is powerful but adds a concept to learn on top of Postgres itself, which is one more thing for a solo developer to hold in their head.
Who should skip it: teams with no particular GraphQL preference. If REST is fine, Supabase's larger community tips the decision in its favor for close to identical pricing.
What does it actually cost to run PocketBase?
PocketBase is the outlier here, and deliberately so. It's a single Go binary, MIT licensed, with an embedded SQLite database, auth, file storage, real-time subscriptions, and an admin dashboard, all in one executable with zero external dependencies.
There's no managed cloud from the maintainer. You self-host, typically on a $4 to $10 a month VPS from Hetzner, DigitalOcean, or similar. Third-party managed hosts exist, PocketHost runs around $9.99/month for a hosted instance, but that's a separate company, not an official product.
Pros: the lowest real cost of anything on this list if you're comfortable with a VPS, full data ownership with zero vendor lock-in, and a genuinely tiny footprint that starts in under a minute.
Cons: SQLite is single-writer, so it won't scale to thousands of concurrent write-heavy users the way a managed Postgres cluster will. There are no managed backups unless you set them up yourself, no uptime SLA, and support is community Discord and GitHub issues rather than a vendor with a contract. You are the ops team now.
Who should skip it: anyone who wants to outsource infrastructure decisions entirely, or who's building something that will need to scale write throughput past what a single SQLite file can handle.
How do you actually choose?
Worth being honest about before any of this becomes a weekend project. Convex's document model and TypeScript function syntax don't map one-to-one onto SQL, so moving to Supabase or Nhost means designing an actual relational schema, not just exporting JSON and importing it. Auth, storage, and any scheduled functions or cron jobs get rewritten against a different API too, not just moved.
Moving to PocketBase carries the same schema-redesign cost plus you take on hosting yourself. Moving to Firebase is arguably the easiest of the four if your data is already fairly document-shaped, since Firestore's model is closer to Convex's than Postgres is, but you inherit Firebase's usage-based billing unpredictability in exchange.
None of this is a reason to stay on Convex if the pricing or data model genuinely doesn't fit. It's a reason to prototype the new schema on a side branch before committing to the switch, rather than migrating production data on the first attempt. Budget a real weekend for it, not an afternoon, even for a small app.
The recommendation
Default to Supabase unless something specific points elsewhere. Postgres, the biggest ecosystem, and pricing that doesn't punish a growing team. This is the safe migration path for most people leaving Convex.
Already building on Google Cloud or shipping mobile apps? Firebase still earns its place. Just budget-cap it, since there's no hard spending ceiling on Blaze.
GraphQL-first frontend? Nhost saves you from bolting Hasura onto Supabase yourself. Nearly identical pricing to Supabase, so the decision comes down to API preference, not cost.
Want to own everything and don't mind running a server? PocketBase is free and it's not close. The tradeoff is becoming your own ops team, which is a fair trade for a side project and a real cost for anything customer-facing at scale.
If you're still deciding whether Convex is even the problem, the full Convex vs Supabase vs Firebase comparison covers the head-to-head in more depth. For Postgres options beyond Supabase specifically, the Supabase alternatives post and the Turso vs Neon vs Supabase comparison are worth a read, and if Firebase is the one you're actually trying to leave, the dedicated Firebase alternatives post goes deeper on that specific move.
Found a better fit for your stack? Let me know on Twitter @hafizdev.
Top comments (0)