Verdict: pick Supabase when a team app outgrows its app builder and the data should sit in a database your organisation runs. It is open source and free to self-host with Docker, row-level security enforces who sees which rows, and Lovable is built to work with it. Self-hosting means IT runs backups, updates and monitoring.
Other good fits
Apps where different groups must see different rows of the same table, enforced in the database with row-level security rather than in the screens.
IT teams that already back up and run PostgreSQL and want sign-in, an API and a dashboard on top without writing them.
+ Pros
Read pros
Supabase wraps an ordinary PostgreSQL database with what an app needs around it: sign-in, an API that the app and other programs use to read and write, file storage, and Studio, a web dashboard for tables and rules. The rules live in the database as row-level security: once it is switched on for a table, nobody reads or writes a row unless a policy allows it, such as "rows where the group is my group". The browser gets a publishable key, which is safe to expose because policies still apply; a secret key skips every policy and stays on the server. You can use Supabase's cloud or run the whole stack yourself with Docker.
Pick it when…
An app built with Lovable needs a database your organisation controls, with sign-in and per-row rules already built.
IT wants the data in plain PostgreSQL it already knows how to back up and restore.
Programs and AI assistants each need their own login with narrow access, instead of sharing an administrator key.
− Cons
Read cons
The self-hosted version is the same software without the cloud's operations around it. There are no managed backups or point-in-time recovery, and it runs one project per install. Support comes from the community on GitHub and Discord, not from Supabase. Row-level security decides rows, not fields, so fields a role mustn't see belong in a table of their own. Lovable's one-click connection is made for Supabase's cloud; with a self-hosted install, the app gets the address and key as settings instead.
Pick something else when…
One team, ordinary data, no outside systems: Base44 keeps the data inside the builder with less to run.
You want Supabase without running it: Lovable's own cloud backend manages a Supabase instance for you, but outside your organisation's servers.
You only need a plain PostgreSQL database beside your own API: Dokploy runs and backs up databases on your server.
Avoid if
Nobody in IT will own backups, updates and monitoring: the self-hosted version has no managed backups, so take Supabase's cloud or stay in the builder.
You need several separate projects on one install: self-hosted Studio runs a single project.
Workflow
IT starts Supabase's own Docker setup at a pinned release on the organisation's server and replaces every default password and key → you create the tables in Studio, switch on row-level security for each, and write one policy per role and action → the app's screens get the address and the publishable key, never the secret key → you test each role's allowed and refused requests against the API from that role's own account → IT backs up the database dump, uploaded files and configuration to another machine every night, and a deputy restores it into an empty install before anyone depends on it.
Cost
Read cost
Prices checked 23 September 2026 (Supabase's pricing page, US dollars):
Plan
Price
What you get
Self-hosted
Free (open source)
The full stack on your own server; you pay for the server and IT's time
Free (cloud)
$0
500 MB database, 50,000 monthly active users, 2 active projects, paused after 1 week of inactivity, no backups
Pro (cloud)
$25/month
$10 of compute credit, 8 GB disk per project, 100,000 monthly active users, daily backups kept 7 days
Team (cloud)
$599/month
As Pro, with daily backups kept 14 days
Enterprise (cloud)
Custom
Custom limits and backup retention
Self-hosting needs at least 4 GB of RAM, 2 CPU cores and 40 GB of SSD, with 8 GB, 4 cores and 80 GB recommended. The running effort sits with IT: Supabase publishes a new self-hosted release about once a month, and backups, monitoring, security updates and restores are yours to run and rehearse.
Restrictions
Self-hosted installs lack branching, advanced metrics beyond logs, managed backups and point-in-time recovery, analytics and vector buckets, ETL and the platform management API, and Studio supports only one project. The secret key bypasses every row-level security policy, so it must never reach a browser or a colleague's assistant. Supabase is retiring its older anon and service_role keys by the end of 2026, so older installs need a planned switch to the new keys.
First project
Documentation-based suggestion — not run here.
Read first project
Put one small table behind row-level security and prove that two test users see different rows.
Start a Supabase project, either self-hosted on a test server with Docker or a free cloud project, using test data only.
Create a table requests with a group column and a members table that says which user belongs to which group.
Switch on row-level security for requests and add one policy: signed-in users read rows of their own group.
Create two test users in different groups, add a few rows for each group, and sign in as each through the API.
Ask each user for the other group's row by its number and write down what comes back.
Done when each test user gets their own group's rows, an empty list for the other group's, and nothing at all when not signed in.
Links & evidence
Documentation-based · not hands-on · Sep 23, 2026
Rests on Supabase's own self-hosting, Docker, row-level security, API key, backup and restore, architecture and pricing pages on supabase.com, plus Lovable's own Supabase and self-hosting pages on docs.lovable.dev, all read on 2026-09-23. Nothing was installed, signed into or tested for this review. Not verified: EUR prices, and whether Lovable's editor can manage tables on a self-hosted install.
Self-Hosting · Sep 23, 2026 — Docker is the recommended way to self-host; branching, advanced metrics, managed backups and PITR, analytics and vector buckets, ETL and the management API are unavailable; one project per install; community-supported; you are responsible for backups, updates and monitoring.
Self-Hosting with Docker · Sep 23, 2026 — Minimum 4 GB RAM, 2 cores, 40 GB SSD (8 GB, 4 cores, 80 GB recommended); never start with the default secrets; Studio behind HTTP basic auth; stable snapshots about once a month, updated with update.sh.
Row Level Security · Sep 23, 2026 — With RLS enabled and no policies, no data is reachable with a publishable key; policies per action with USING and WITH CHECK; service_role bypasses RLS and must stay server-side; views bypass RLS unless security_invoker is set.
Understanding API keys · Sep 23, 2026 — Publishable keys are safe to expose; secret keys bypass every RLS policy and must never be in a browser; anon and service_role keys are being deprecated by the end of 2026.
Architecture · Sep 23, 2026 — Component licences: Studio, Realtime, Storage, postgres-meta and Supavisor Apache 2.0; Auth, PostgREST and Deno MIT; Postgres under the PostgreSQL License.
Base44 wins for one team with ordinary data: the database, sign-in and table permissions come with the builder, with nothing to host.
Lovable with its own cloud backend wins when you want Supabase's features without running a server, and the data may live outside your organisation.
Dokploy wins when IT wants a plain PostgreSQL database and a hand-written API on its own server, and is ready to build sign-in and permission checks itself.
Supabase is an open-source platform built on PostgreSQL that gives an app a database, sign-in, an automatic API, file storage and a web dashboard called Studio. Row-level security policies decide which rows each signed-in person may read or change. It runs as a managed cloud service or self-hosted with Docker on your own server, and app builders such as Lovable are built to work with it.
Supabase · free-tier · cloud · self-host
PostgreSQL database with row-level security policies
sign-in with email or external providers such as Microsoft Entra ID
automatic REST API over the database
file storage
Studio web dashboard
self-hosting with Docker Compose
database and sign-in behind an AI-built web app
per-row access rules for team apps
self-hosted app backend on an organisation's own server