Qué es Supabase y cómo tener tu propia base gestionada en ArduMaker
Publicado el 2026-09-12 por 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 se presenta como "la alternativa open source a Firebase". La descripción es útil para ubicarlo y esconde lo más interesante: por debajo es PostgreSQL a secas.
No es un motor propio con un dialecto raro. Es Postgres, con una serie de piezas alrededor que resuelven lo que normalmente se escribe a mano.
Qué hay realmente adentro
PostgREST. Lee el esquema de tu base y genera una API REST automáticamente. Creás una tabla y ya tenés endpoints para consultarla, filtrarla, ordenarla y paginarla. Sin escribir un controlador.
GoTrue. Autenticación: registro, inicio de sesión, recuperación de contraseña, proveedores externos, tokens.
Realtime. Escucha los cambios de la base y los transmite por WebSocket. Tu interfaz se actualiza cuando alguien modifica una fila, sin que programes nada para eso.
Storage. Archivos, con permisos apoyados en las mismas reglas de la base.
Edge functions. Código del lado del servidor para lo que no encaja en una consulta.
La pieza que lo hace funcionar: seguridad a nivel de fila
Esto es lo que más sorprende y lo que más importa entender.
Si exponés tu base directamente como API, la pregunta obvia es: ¿qué impide que un usuario consulte los datos de otro?
La respuesta no está en la API. Está en Postgres, con una función que existe hace años y casi nadie usaba: row level security. Se escriben políticas que dicen qué filas puede ver o modificar cada usuario, y las aplica el motor de la base.
create policy "cada uno ve lo suyo" on pedidos for select using (auth.uid() = usuario_id);
La consecuencia: no importa por dónde entre la consulta, la regla se cumple. La seguridad deja de depender de que cada endpoint se acuerde de filtrar.
Es también donde se cometen los errores. Una tabla sin políticas activas, expuesta por la API, es pública. Vale revisarlo tabla por tabla antes de publicar.
Qué significa que sea open source
Todas las piezas son proyectos abiertos y se pueden ejecutar en tu propio servidor. Eso cambia dos cosas:
No hay encierro. Tus datos están en un Postgres estándar. Si mañana querés mudarte, es un volcado y una restauración. Comparado con plataformas donde exportar significa reescribir la aplicación, la diferencia es enorme.
Podés autoalojarlo. Con Docker Compose, en tu VPS. Ganás control y costo fijo; perdés la parte administrada.
Cuándo conviene, y cuándo no
Conviene para prototipos y productos donde la mayor parte del backend es CRUD con permisos. Ahorra semanas.
No conviene cuando la lógica de negocio es compleja: si cada operación implica varias validaciones, llamadas externas y reglas, terminás peleando con la API generada. Ahí un backend propio es más simple.
Un camino intermedio que funciona bien: Supabase (o simplemente Postgres) para los datos, y tu propio backend para las operaciones con reglas, sin exponer esas tablas por la API automática.
La versión sin capas
Vale decirlo: para muchos proyectos, Postgres solo alcanza. Si ya tenés un backend, lo que Supabase agrega es en buena parte lo que tu backend ya hace.
En ArduMaker podés levantar Postgres en tu VPS desde el panel, con su usuario, sus copias de seguridad y acceso por túnel en vez de puerto abierto. Y si querés el paquete completo, Supabase autoalojado corre con Docker en el mismo VPS. En los dos casos, la base es tuya y los datos no salen de tu infraestructura.