What is Supabase and how to have your own managed database on ArduMaker
Published on 2026-09-12 by frfrand
Postgres con API automática, autenticación y almacenamiento encima. Qué resuelve de verdad, qué significa que sea open source, y cuándo conviene armarlo vos mismo.
Supabase presents itself as "the open source alternative to Firebase". The description is useful for positioning it and hides what's most interesting: underneath, it's plain PostgreSQL.
It's not a proprietary engine with a strange dialect. It's Postgres, with a set of components around it that solve what you normally have to write manually.
What's really inside
PostgREST. Reads your database schema and automatically generates a REST API. You create a table and you already have endpoints to query it, filter it, sort it, and paginate it. Without writing a controller.
GoTrue. Authentication: registration, login, password recovery, external providers, tokens.
Realtime. Listens to database changes and transmits them via WebSocket. Your interface updates when someone modifies a row, without you having to program anything for that.
Storage. Files, with permissions backed by the same rules as the database.
Edge functions. Server-side code for what doesn't fit in a query.
The piece that makes it work: row-level security
This is what surprises the most and what's most important to understand.
If you expose your database directly as an API, the obvious question is: what prevents a user from querying another user's data?
The answer is not in the API. It's in Postgres, with a function that has existed for years and almost nobody used: row level security. You write policies that say which rows each user can see or modify, and the database engine applies them.
create policy "each one sees their own" on pedidos for select using (auth.uid() = usuario_id);
The consequence: no matter where the query comes from, the rule is satisfied. Security no longer depends on each endpoint remembering to filter.
This is also where mistakes are made. A table without active policies, exposed via the API, is public. It’s worth reviewing table by table before publishing.
What it means to be open source
All the pieces are open-source projects and can be run on your own server. This changes two things:
No vendor lock-in. Your data is in a standard Postgres. If tomorrow you want to move, it’s a dump and a restore. Compared to platforms where exporting means rewriting the application, the difference is enormous.
You can self-host it. With Docker Compose, on your VPS. You gain control and fixed cost; you lose the managed part.
When it makes sense, and when it doesn’t
It makes sense for prototypes and products where most of the backend is CRUD with permissions. It saves weeks.
It doesn’t make sense when business logic is complex: if each operation involves multiple validations, external calls, and rules, you end up fighting the generated API. In that case, a custom backend is simpler.
A middle path that works well: Supabase (or just Postgres) for the data, and your own backend for operations with rules, without exposing those tables via the automatic API.
The version without layers
It's worth saying: for many projects, Postgres alone is enough. If you already have a backend, what Supabase adds is largely what your backend already does.
In ArduMaker you can deploy Postgres on your VPS from the panel, with its user, backups, and tunnel access instead of an open port. And if you want the full package, self-hosted Supabase runs with Docker on the same VPS. In both cases, the database is yours and the data never leaves your infrastructure.