Nhost is one of the more coherent backend-as-a-service offerings out there: PostgreSQL as the source of truth, Hasura for instant GraphQL, plus auth, file storage, and serverless functions bundled into one project. If your team is GraphQL-first, it removes a lot of glue code you'd otherwise write yourself.
But "coherent" also means "opinionated." People go looking for alternatives to Nhost for a few recurring reasons: they don't actually want GraphQL as the primary API layer, they want plain Postgres they fully control, they're worried about coupling their entire backend to the Hasura permission model, or they've outgrown the BaaS pattern and want to run their own backend service next to a managed database.
Which of those describes you matters a lot, because the right alternative is completely different in each case. Here's an honest rundown.
What Nhost gets right
Before the list — credit where it's due. Nhost's stack is open source, which means you can inspect what's actually running and, if you ever need to, self-host the whole thing with Docker Compose. The Postgres-at-the-center design is the correct call (your data outlives every framework decision), and the Hasura permission system is genuinely powerful once you've internalized it. It has a free tier for hobby projects and usage-based paid plans; check [nhost.io/pricing](https://nhost.io/pricing) for current numbers, since these change.
If you're happy with GraphQL, permissions-as-metadata, and the Nhost SDK, there may be no reason to move. The rest of this post is for everyone else.
1. Supabase — the default Postgres BaaS
[Supabase](https://supabase.com/docs) is the most direct substitute. Same core idea — Postgres in the middle — but the API layer is REST (via PostgREST) rather than GraphQL, and authorization lives in Postgres row-level security policies instead of Hasura metadata.
Good: the ecosystem is enormous. Client libraries for everything, a polished dashboard, realtime subscriptions, storage, edge functions, and more community answers to any given error message than any competitor. RLS-based auth means your rules live in the database itself, which survives a platform migration better than external metadata does.
Watch out for: it's just as opinionated as Nhost, only in a different direction. If you fight the RLS model, you'll have a bad time. Free-tier projects pause after inactivity, and costs on paid plans are compute-based, so you'll want to understand their instance sizing before you commit a production workload.
2. Firebase — the incumbent, still the best at realtime mobile
[Firebase](https://firebase.google.com/docs) is the product Nhost positions itself against, and it's still the strongest option for one specific job: mobile apps that need offline sync and realtime updates with minimal backend code.
Good: the client SDKs and offline behavior are years ahead of everyone. Auth is battle-tested. The integration with Google Cloud is deep.
Watch out for: Firestore is a NoSQL document store. If you left Nhost because you wanted *more* SQL control, Firebase is a step in the wrong direction — no joins, no migrations, query patterns you have to design around up front, and the deepest vendor lock-in on this list.
3. Appwrite — open-source BaaS with first-class self-hosting
[Appwrite](https://appwrite.io/docs) is the open-source BaaS that treats self-hosting as a primary path rather than an escape hatch. One Docker Compose file gets you databases, auth, storage, functions, and messaging on your own hardware, and there's a hosted cloud if you'd rather not operate it.
Good: genuinely pleasant SDKs across a lot of platforms, and the self-hosted story is real — plenty of teams run it on a single VPS.
Watch out for: the database layer is Appwrite's own document-style abstraction, not raw Postgres. You interact with collections through Appwrite's API, which is fine until you want to run arbitrary SQL, plug in an ORM, or point a BI tool at your data.
4. Neon — just the Postgres, seriously
If your real complaint about Nhost is "I only wanted the database," [Neon](https://neon.tech/docs/introduction) is serverless Postgres and nothing else. No auth, no storage, no functions — you bring your own backend.
Good: database branching is the standout feature — spin up a copy-on-write branch of production for every preview environment. Compute scales to zero when idle, and the free tier is workable for side projects.
Watch out for: you're assembling the rest of the stack yourself. Auth, file uploads, background jobs, and hosting for the actual application all become your problem. That's freedom or overhead depending on your team.
5. PandaStack — when you're leaving BaaS entirely
This is our lane, so let me be precise about when it fits and when it doesn't.
PandaStack isn't a backend-as-a-service — there's no auto-generated API over your tables. It's an application platform: you push a Git repo (any Dockerfile, or auto-detected buildpacks for Node.js, Python, Go, and more), it builds and deploys it, and you attach a managed database — PostgreSQL, MySQL, MongoDB, or Redis, orchestrated by KubeBlocks on Kubernetes. The connection string is injected into your app as DATABASE_URL automatically, so there's no copying credentials between dashboards. Builds run in rootless BuildKit inside ephemeral Kubernetes jobs, and you watch the logs stream live.
Good: if you've outgrown the BaaS pattern — you want your own Express/FastAPI/Go backend with real Postgres behind it — this is that, without running Kubernetes yourself. The free tier includes 5 web services, 5 static sites, one database with 7-day backup retention, 100 GB bandwidth, and 300 build minutes per month. Paid plans are flat: Pro at $15/mo, Premium at $25/mo, with usage-based compute tiers on top for bigger workloads.
Watch out for: you write the API layer yourself — that's the whole point, but it's more code than Nhost. Free-tier apps scale to zero when idle, so the first request after a quiet period eats a cold start, and the free database volume is sized for dev and hobby work, not heavy production.
6. Self-hosting the Nhost stack
Worth stating plainly: Nhost's components are open source. If your issue is the hosted pricing rather than the architecture, you can run Postgres, Hasura, and the auth/storage services yourself on a VPS with Docker Compose.
Good: you keep the exact stack your app already speaks, and a mid-size VPS is cheap.
Watch out for: you now own backups, upgrades, TLS, monitoring, and 3 a.m. pages. Hasura upgrades in particular deserve a staging pass — metadata compatibility issues are much better found there than in production. Be honest about whether the money saved covers the hours spent.
How to choose
| You want... | Pick |
|---|---|
| The closest drop-in, REST instead of GraphQL | Supabase |
| Mobile-first realtime with offline sync | Firebase |
| Open-source BaaS you can run on your own box | Appwrite |
| Only a serverless Postgres, nothing else | Neon |
| Your own backend + managed DB, deployed via git push | PandaStack |
| The exact Nhost stack, self-operated | Self-hosting |
The biggest fork in the road is BaaS versus platform. If auto-generated APIs are saving you real time, stay in the BaaS column — Supabase or Appwrite. If you keep writing custom functions to work around the generated API, that's the signal you've outgrown it, and a platform that runs your code next to a managed database is the saner shape.
If that second camp is you, connecting a repo on [pandastack.io](https://pandastack.io) and attaching a Postgres to it is a quick way to find out.