Stacks vs Supabase

Supabase gives you a backend. Stacks gives you somewhere to put your logic.

This is the least like-for-like comparison on the page, and worth making because teams genuinely choose between them. Supabase is a hosted Postgres with auth, storage, realtime, and edge functions in front of it. Stacks is a framework you run. Plenty of applications use both.

What Supabase is.

In its own terms, not ours.

Supabase is an excellent product: real Postgres you can take with you, row level security, generated APIs, auth with many providers, storage, realtime subscriptions, vector search, and a good dashboard. For a client-heavy application it removes an entire tier of work, and the open-source core means the exit path is a database dump rather than a rewrite.

Where each one wins.

Same amount of room on both sides, on purpose.

Pick Supabase for

  • No backend to run at all

    For a mobile or single-page application, talking straight to Supabase from the client is genuinely less work than any framework.

  • Postgres, properly

    Extensions, row level security, and full SQL, hosted competently, with a real migration path off it.

  • Auth breadth

    Social providers, magic links, and multi-factor configured in a dashboard rather than written.

  • Speed to first version

    A working prototype in an afternoon is a real advantage when validating an idea.

Pick Stacks for

  • Business logic has a home

    Anything beyond CRUD ends up in database functions, triggers, or edge functions in a BaaS. Here it is actions, jobs, and events in one typed codebase.

  • Auth and authorisation you can read

    Social login, magic links, and two-factor come from the same auth package as password login, just as code rather than a dashboard toggle. Row level security policies are powerful and easy to get subtly wrong; gates and policies are ordinary reviewable TypeScript instead.

  • Background work and mail

    Queues, schedules, retries, transactional mail, and notifications, rather than cron extensions and a mail provider.

  • You own the deployment

    Your AWS account, your database, your bill, and no platform between you and it.

Side by side.

The dimensions teams actually decide on.

Dimension Stacks Supabase
What it is A framework you run A hosted platform you consume
Database SQLite, MySQL, or Postgres, yours Hosted Postgres
Logic layer Actions, jobs, events, middleware Edge functions and database functions
Authorisation Gates and policies in TypeScript Row level security in SQL
Background work First-class queues and schedules pg_cron and queue extensions
Front end Included Bring your own
Admin Generated from your models Platform dashboard over tables
Operating model You deploy and run it Managed, with self-hosting possible

If you did move.

What ports cleanly, what does not, and where to start.

They work well together

Point a Stacks application at a Supabase Postgres instance and keep the storage and auth you already use while logic moves into the framework.

Tables become models

Generate models from the existing schema, then let migrations be diffed from them going forward.

Policies become gates

Each row level security policy becomes a gate or a query scope, which is usually where the subtle bugs get found.

The verdict.

Both answers are real. Most teams already know which paragraph is theirs.

Choose Supabase when

The application is mostly a client talking to a database, you want no servers to operate, and the logic fits in the database and a few functions.

Choose Stacks when

The interesting part is the logic between the request and the row, and you want it in one typed, testable, reviewable codebase.

The frameworks that usually come up in the same conversation.