DEV Community: Max S.

Supabase Alternatives in 2026

Max S. — Mon, 15 Jun 2026 09:26:09 +0000

Disclaimer: Supabase is a great platform, with by far the largest ecosystem and community.

However, if you're looking to leave, the reasons usually come down to three things:

The pricing gets non-linear at the exact moment a project starts working
PostgREST doesn't scale gracefully to complex relational frontends
You have requirements (self-hosting mandates, a reactive data model, compliance regimes, or AI agent workflows) that the platform doesn't model well

If none of that is your situation, stop reading.

What follows is Nhost, Neon, Appwrite, Convex, Firebase, PocketBase. Not Railway, not Render. Those are infra platforms and comparing them to Supabase doesn't make sense, like comparing a toolbox to a hammer.

Nhost

Nhost is, structurally, very similar to Supabase: Postgres, auth, storage, serverless functions. The difference is the API layer. GraphQL instead of PostgREST, powered by Constellation, their own open-source GraphQL engine written in Go.

If you have a dashboard that needs data from six related tables, a GraphQL query gives you exactly that in one round trip. PostgREST gives you a series of choices: chain multiple requests, write RPC functions that fake the join, or start questioning your data model. It gets unwieldy fast.

The permission system compounds this: role-based row and column access is defined inside the query engine itself, so you're not maintaining separate RLS policies in SQL that drift from your actual auth logic.

Nhost fits naturally for AI agent workflows. Agents touching shared Postgres state get real-time updates via subscriptions, and the permission model means no separate access control layer bolted around your database calls.

Neon

Neon is not a full Supabase replacement. It's a database. That's it. No auth, no storage, no functions, no realtime. If you pick Neon, you're assembling the rest of the backend yourself.

Why would you do that? Because what Neon actually built is genuinely impressive: they separated compute from storage at the Postgres level, which makes database branching possible. A full copy-on-write snapshot of your database in seconds. One branch per pull request, against real data, gone when the PR closes. Databricks acquired them last year and it's continued to develop. It's become the thing other providers benchmark against.

Neon is a good fit if the database itself is your unsolved problem and the rest of your infrastructure is already handled: platforms provisioning a database per customer, CI pipelines that need isolated environments per test suite, teams with existing auth that just want better Postgres without ripping everything else out.

Appwrite

The thing Appwrite does well, genuinely well in a way the other platforms kind of half-ass, is self-hosting. One docker-compose command and you have a full working stack. Not "full working stack but you need to configure eight more things." Actually full, actually working.

This matters more than people give it credit for. Air-gapped environments, healthcare compliance, regions where AWS and GCP are politically complicated, enterprise contracts with data residency clauses that say the words "within the EU" in boldface. Appwrite handles all of this without treating self-hosting as a community project that the founders are vaguely embarrassed by.

Here's the catch, and it's a real one: Appwrite is not Postgres. The data layer is its own collection and document model. Which means no SQL, no pg_dump, no EXPLAIN ANALYZE when a query gets slow, no connecting a BI tool to it. One of the quiet reasons Postgres-backed platforms feel safe is that the escape hatches are all there if you need them. Appwrite closes most of them.

If your team thinks in SQL, you'll notice this within the first week. There's no workaround for it.

If you're building something mobile-first, especially on Flutter, Appwrite's Flutter SDK is one of the best in this space and the SQL thing might genuinely not matter. Different problem, different tradeoffs.

Convex

Almost every comparison article gets Convex wrong, usually by fitting it into a row in a feature table next to Firebase and calling it a document database alternative. It's not that.

The actual model: your backend is TypeScript functions. The data layer is document-relational. The important part, the part that sounds like a detail but isn't, is that queries are reactive subscriptions by default. When data changes, every subscribed client updates. Automatically. Without you writing cache invalidation logic. Without you managing subscription channels. Without you thinking about whether two parts of the UI are looking at stale data from the same table.

End-to-end TypeScript from the schema to the React component means the types aren't generated artifacts you have to remember to regenerate. They're the same code.

When does this matter? Collaborative editors. Live multiplayer state. AI agent applications where multiple processes are writing to shared state concurrently and the UI has to reflect it immediately. Convex makes a whole class of synchronization bugs structurally impossible. Not hard to write — the runtime doesn't let them exist.

When does it not matter? Analytical stuff. Reporting. Anything that needs direct SQL access. Convex's document model won't bend to accommodate an ad-hoc GROUP BY.

The learning curve is also real: the first two weeks are genuinely disorienting. The mental model is different enough from "database + API" that your existing instincts are wrong in subtle ways. Developers who get through that describe the next few months as feeling like they have superpowers. I believe both descriptions. Whether the trade is worth it depends on whether realtime consistency is your actual hard problem.

Firebase

Hard to imagine cases when people move from Supabase to Firebase, but I can't skip this.

If you outgrow Supabase or Nhost and need to leave, your data is Postgres. You run pg_dump, you load it somewhere else, you update your connection strings. It's a project, not a crisis.

If you outgrow Firestore, you're transforming a data model, not migrating rows. The access patterns you built around Firestore's model (the denormalization, the collection structure, the places where you stuffed data into subcollections to avoid a join) don't translate. It's months of work under pressure, usually when the thing that forced the move isn't waiting for you.

That's not a dealbreaker for the right use cases. Offline-first mobile sync where the app needs to work through genuinely unreliable networks and reconcile cleanly when connectivity returns: Firebase is still the best answer here, and it's not close. Simple read-heavy access patterns at scale without relational complexity. Google ecosystem products where auth, analytics, and ML are already in Cloud.

PocketBase

I'll just say it: PocketBase is one of my favorite pieces of software that exists right now.

It's one Go binary. SQLite, realtime subscriptions, auth, file storage, admin UI. Runs on a $5 VPS. ~60k GitHub stars. One maintainer.

That last part is both the appeal and the risk. The total system fits in one person's head, which means deployment is copying a file, the admin UI is actually good, and there are no abstractions hiding from you. For internal tools, admin panels, side projects, prototypes, hobby things that are more complex than a static site: PocketBase is more elegantly suited to these than anything else on this list by a significant margin.

The ceiling is real too. SQLite means single node. There's no path to horizontal scaling, no managed hosting tier for when self-managing gets annoying. There was a meaningful auth-bypass CVE earlier this year, patched quickly and responsibly disclosed, handled well by the maintainer. But "handled well by a single person" is a different risk profile than "handled by a security team at a funded company," and that's a real input to a production decision depending on what you're building.

The failure mode I've watched happen: someone uses PocketBase as a placeholder while the project proves out, then migrates to something "real" after it does. That migration always happens under deadline, always takes longer than anyone estimated, and is always more painful than if they'd made the decision upfront. Better to either commit to it for what it actually is (a complete backend for things that fit on one node, which is honestly a bigger category than people admit) or pick something else from the start.

So How Do You Actually Pick

Start with the data model. This is the decision that matters most and people skip over it to compare pricing tiers instead.

If you need GraphQL, a strong permission layer, or your backend will serve AI agents: Nhost. If you want the most mature REST-based Postgres BaaS with the largest ecosystem: go back to Supabase. If the database is your only unsolved problem and everything else is handled: Neon.

Document-shaped data with stable, simple access patterns: Firebase or Appwrite.

Then self-hosting. If it's a hard requirement, not a nice-to-have: Appwrite or PocketBase. Self-hosted Supabase exists but the full service stack is a real ops commitment. Not a one-afternoon project.

Then realtime. If live synchronization is the core mechanic of what you're building and not just a feature checkbox, actually evaluate Convex. Don't just put it in the table and move on.

Before you commit to anything: run your actual schema through the top two options. Real tables, real auth flow, real queries from the app. Not a tutorial, not a hello world. The places where something breaks or needs a workaround are the information you need, and you won't get it from any comparison article including this one.

We Built an Open-Source GraphQL Engine to Replace Hasura

Max S. — Thu, 04 Jun 2026 15:13:37 +0000

TL;DR

We built Constellation — an open-source GraphQL engine written in Go that is a near drop-in replacement for Hasura Community Edition. It reads the same metadata, generates the same schema, and serves the same GraphQL API. In production it uses ~90% less memory than Hasura with comparable or better latency, before any dedicated performance work.

If you run Hasura today, this post is for you. If you build GraphQL infrastructure, care about open-source sustainability, or just want to see real production memory numbers from a fresh Go rewrite — keep reading.

The problem with depending on someone else's engine

Hasura v2 has been the backbone of Nhost's GraphQL layer for years. It's a genuinely good piece of engineering, and we built a lot on top of it.

But three things changed:

Hasura v2 is winding down. Development has shifted to Hasura v3, which takes a different approach to open source — the engine core is Apache-licensed, but the CLI, web console, and developer tooling are proprietary. That's a meaningful shift from v2, where the full stack was open. Continuing to depend on an engine that's winding down toward end-of-life, or migrating our GraphQL and permissions layer to one where the tooling is closed, weren't paths we were willing to take.

Memory was consistently our heaviest service per project. A GraphQL engine sits between every client request and your database. It should be fast and lean. Instead, it was the most expensive thing we ran per project — and memory in particular is hard to throttle gracefully under load.

We didn't own a critical piece of our infrastructure. The API and permissions layer sits at the center of every Nhost application. When something goes wrong, or when you want to ship something new, depending on someone else's roadmap is expensive in ways that don't show up in dashboards.

So we built our own — while keeping full compatibility with Hasura on the GraphQL request path.

What Constellation actually is

Constellation is a GraphQL engine that turns a relational database into a role-based GraphQL API. It is designed to be a near drop-in replacement for Hasura Community Edition.

Concretely, that means:

Same metadata format. It reads your existing Hasura metadata — either from a YAML/JSON file on disk, or straight from Hasura's hdb_catalog.hdb_metadata table.
Same generated schema. Same types, same relationships, same permission-aware shape per role. We verify this with byte-level schema diffs (more on that below).
Same request surface. Queries, mutations, and subscriptions over the same /v1/graphql endpoint, plus remote schemas and cross-source remote relationships.

It's a fresh Go codebase — not a fork of Hasura. PostgreSQL and SQLite are first-class backends today. The connector design is built so additional databases can plug in without touching the query planner.

Where Hasura's behavior is surprising or outright wrong, we occasionally diverge — and every such divergence is documented in KNOWN_DIFFERENCES.md. Correctness over surface area is one of our explicit goals.

The numbers that made us ship it

We ran Constellation against real production workloads, side by side with Hasura, on the same database and the same traffic. We didn't tune anything special for these results.

Memory

Constellation's memory usage sits ~90% below Hasura's serving the same traffic. In absolute numbers: Hasura at ~180 MiB, Constellation at ~15 MiB. This is not a benchmark environment — these are production dashboards.

A note on the CPU panel in that chart: Constellation's CPU looks dramatically lower, but we're talking millicpus here. Both engines are cheap on CPU in absolute terms; the gap is real but small. Memory is where the meaningful difference lives.

Latency

Across the same window, Constellation also serves requests a little faster.

Request latency over the same period: Hasura (blue) regularly spikes toward 60–80 ms, while Constellation (purple) mostly stays under 40 ms.

To make the comparison concrete, here's the per-period delta of Constellation minus Hasura for the same traffic. Anything in the green region (below zero) means Constellation was faster; the occasional red spike above the line marks the moments it wasn't.

Latency delta (Constellation minus Hasura). Most of the line sits in the green, below-zero region, meaning Constellation was faster, with a handful of red spikes where it briefly wasn't.

These are raw production dashboards, not a curated benchmark. That's rather the point. We didn't tune anything special to get here.

How it works alongside Hasura (not instead of it — yet)

Constellation doesn't yet implement Hasura's metadata HTTP API (POST /v1/metadata). It consumes metadata but doesn't author it. So the current deployment model is straightforward:

Hasura owns metadata authoring. Constellation owns request serving. Both point at the same database.

In practice, an Nhost project running Constellation gets two endpoints:

https://<subdomain>.hasura.<region>.nhost.run → Hasura (metadata authoring, plus anything Constellation doesn't serve yet)
https://<subdomain>.graphql.<region>.nhost.run → Constellation

The key property: you can flip Constellation on, run real traffic through it, and remove it at any time to fall back to Hasura with zero migration. That's the whole appeal of the side-by-side model.

Once Constellation supports metadata mutations on its own, the Hasura half can be dropped entirely.

What's solid vs. what's missing

Constellation is alpha. That label reflects feature coverage against Hasura — not the stability of what's already there.

Solid and in production:

✅ PostgreSQL and SQLite connectors
✅ Full GraphQL query, mutation, and subscription pipeline
✅ JWT and admin-secret auth
✅ Role-based permissions
✅ Remote schemas
✅ Cross-source remote relationships

Not yet implemented:

❌ Hasura Actions
❌ Event and cron triggers
❌ REST endpoints
❌ Allowlists and query collections
❌ Inherited roles, native queries, computed fields
❌ MSSQL, BigQuery, Snowflake backends

If your app lives mostly in the query/mutation/subscription world, there's a good chance Constellation already does what you need. If you lean heavily on Actions or event triggers, keep those on Hasura for now.

What's next — and how you can shape it

The near-term roadmap is focused on closing the gap: implementing the metadata HTTP API so Constellation can own the full stack without Hasura running alongside it, expanding the feature surface into Actions and triggers, and eventually supporting additional database backends.

But the most valuable thing right now isn't what's on our roadmap. It's real-world usage.

There are four concrete ways you can help:

Run real traffic through it. Enable Constellation next to your existing Hasura instance (see below) and point production traffic at it. That's the fastest way to find real divergences and edge cases.
Report schema diffs. If nhost schema diff turns up a divergence that isn't covered in KNOWN_DIFFERENCES.md, open an issue with the diff hunk and a minimal metadata snippet. That's how new issues get documented — or fixed.
Report runtime bugs. A query that returns different results, a subscription that misbehaves, a permission that doesn't line up — under live traffic these are the most valuable reports we can get.
Read the code and contribute. It's open source and we've worked hard to make it approachable — small interfaces, golden-file tests, and per-package documentation. PRs and questions are welcome.

Try it yourself

The lowest-friction path is enabling Constellation on any Nhost project. Add one block to nhost/nhost.toml:

[experimental.constellation]
version = "0.4.0"

Pick the latest tag from CHANGELOG.md. With that in place, your project runs both engines. Remove the block and you're back to Hasura.

To verify Constellation generates the same schema as Hasura for each role:

nhost schema dump --role user \
  -u "https://<subdomain>.hasura.<region>.nhost.run/v1/graphql" \
  -o schema.hasura.user.graphqls

nhost schema dump --role user \
  -u "https://<subdomain>.graphql.<region>.nhost.run/v1/graphql" \
  -o schema.constellation.user.graphqls

nhost schema diff -a schema.hasura.user.graphqls -b schema.constellation.user.graphqls

An empty diff means Constellation produced a byte-equivalent schema for that role. Any non-empty diff should map to a known difference — and if it doesn't, that's exactly the kind of issue we want to hear about.

Prefer to run it standalone without an Nhost project? The repository README has full build and run instructions.