Supabase o PostgreSQL a secas en tu propio servidor

La configuración Docker autoalojada de Supabase, versión v0.8.3 del 16 de octubre de 2026, arranca 11 contenedores. Uno de ellos es PostgreSQL 17. Los otros diez son una pasarela, el inicio de sesión, una API REST, el almacenamiento de archivos, el redimensionado de imágenes, las actualizaciones en tiempo real, las funciones de servidor, un pooler de conexiones, una API de administración de la base de datos y el panel Studio. En un servidor x86, las 11 imágenes suman unos 2,15 GB de descarga, según nuestra suma de los tamaños x86 que indica Docker Hub para las etiquetas de imagen del archivo compose. La imagen oficial de PostgreSQL 17 ocupa unos 161 MB.

La documentación de la API de Supabase describe dos formas de usarlo; puedes llamar a sus API: directly from the browser (two-tier architecture), or as a complement to your own API server (three-tier architecture). Si una aplicación de navegador o de móvil se comunica con tu base de datos, esos diez servicios son el backend que, de lo contrario, tendrías que escribir. Si en medio hay un servidor propio, PostgreSQL es la parte que usa tu aplicación.

Lo que Supabase añade a PostgreSQL

Para cada tarea de la lista, la columna central indica el servicio de Supabase que se encarga de ella, según la página de arquitectura de Supabase y su README de autoalojamiento en la v0.8.3.

Nuestra recomendación para un caso habitual: una aplicación Next.js, React o móvil que todavía no tiene código de servidor es la que más partido le saca a Supabase. Sin él, todo eso es código que tendrías que escribir antes del lanzamiento. Un equipo que ya tiene un backend en Rails, Django o Express apenas saca provecho de los diez servicios adicionales.

DreamHost vende ambos como servidores con el software ya instalado, hosting VPS para Supabase y hosting VPS para PostgreSQL, en los mismos planes Stack y a los mismos precios. Si ahora usas Supabase Cloud y te preguntas si un servidor te saldría más barato, empieza por lo que cuesta Supabase Cloud a medida que creces. Si estás comparando un servicio de PostgreSQL administrado con PostgreSQL a secas en un servidor, lee lo que cuesta Postgres administrado frente a un servidor propio.

Lo que funcionó desde el primer día

Probamos cada tarea en Supabase justo después de la instalación, sin más código propio que los scripts de prueba, y las siete funcionaron.

• Iniciar sesión con un usuario y obtener un token. Creamos el usuario mediante la API de administración, ya que la configuración predeterminada no incluye servidor de correo para los correos de confirmación.
• Leer y escribir en una tabla por HTTP bajo una política de seguridad a nivel de fila. El usuario con sesión iniciada vio su única fila, y una petición sin usuario autenticado obtuvo 0 filas.
• Subir un archivo y descargar los mismos bytes. Usamos un bucket privado, y la descarga coincidió byte a byte.
• Redimensionar una imagen. El servicio imgproxy convirtió un PNG de 800x600 en uno de 200 píxeles de ancho.
• Llamar a una función de servidor. Respondió la función hello incluida.
• Recibir un evento al añadir una fila. Un cliente supabase-js recibió la nueva fila 283 ms después de la inserción.
• Abrir un panel web. Studio pidió primero sus credenciales.

En PostgreSQL 17 a secas ejecutamos las dos tareas que la base de datos hace por sí sola. La misma política de seguridad a nivel de fila funcionó en SQL, y LISTEN y NOTIFY transmitieron un evento entre dos sesiones SQL. El resto requiere software aparte de la base de datos: una API HTTP, inicio de sesión, almacenamiento de archivos, funciones de servidor, una conexión desde el navegador para las actualizaciones en tiempo real y un panel.

Realtime nos jugó una mala pasada en la primera prueba: el cliente supabase-js indicó que se había suscrito a los 35 ms, y la fila que insertamos justo después nunca llegó. Al repetirla, registramos los eventos de sistema del canal: el cliente dijo subscribed a los 32 ms, y el mensaje Subscribed to PostgreSQL del propio Realtime llegó unos 2,4 segundos después. Si tu aplicación escribe una fila justo después de suscribirse, escucha el evento system del canal y espera a ese mensaje antes de insertar.

Lo que cada uno le pide a tu servidor

Supabase publica los requisitos de su stack. PostgreSQL no, así que nuestras mediciones cubren ese hueco. En la tabla, Supabase es la configuración autoalojada v0.8.3 y PostgreSQL es PostgreSQL 17 a secas.

Las filas desde la memoria en reposo hasta las extensiones son mediciones propias, del 19 de octubre (VM de 8 GB) y del 20 de octubre de 2026 (VM de 4 GB), descritas en cómo lo medimos. Los tiempos se midieron con las imágenes ya descargadas. Los recuentos proceden del archivo compose de Supabase en la etiqueta self-hosted/v0.8.3; los tamaños de descarga, de los datos de etiquetas de Docker Hub, y los requisitos, de la documentación de cada fabricante. Todo se consultó el 16 de octubre de 2026.

Logs & Analytics están desactivados en la configuración predeterminada de Supabase para reducir el consumo de memoria; los activas con un archivo de override que añade Logflare y Vector y aumenta los requisitos del stack.

Stack 4 cumple el mínimo de Supabase. Stack 8 añade la RAM y el disco recomendados, pero mantiene 2 vCPU. Stack 16 es el plan más pequeño que cumple todas las cifras recomendadas por Supabase, con 4 vCPU, 16 GB de RAM y 250 GB de almacenamiento NVMe según la página del VPS para Supabase, así que es nuestra recomendación para producción; Stack 8 sirve para una aplicación pequeña o una copia de preproducción.

Nuestra prueba con 4 GB demuestra que el stack predeterminado cabe en Stack 4 en reposo. Los 11 contenedores siguieron funcionando sin reiniciarse, y su memoria se estabilizó en algo más de un tercio de los 3904 MiB de la VM. Las imágenes ocuparon unos 9,7 GB de disco, muy por debajo de los 75 GB de Stack 4.

El mismo stack usó aproximadamente un 50 % más de memoria en la VM de 4 GB que en la de 8 GB. Studio, Realtime y el pooler subieron entre un 16 y un 22 %, y cinco servicios pequeños multiplicaron su consumo por entre dos y siete; imgproxy, por ejemplo, pasó de unos 13 MiB a 94 MiB. Hicimos cada prueba una sola vez y no sabemos explicar la diferencia, así que nosotros contaríamos con entre 1 y 1,5 GB para Supabase en reposo y dimensionaríamos el servidor para el tráfico de tu aplicación por encima de eso.

Para PostgreSQL solo, nosotros pondríamos una base de datos de producción en Stack 8, el plan que la página del VPS para PostgreSQL etiqueta como Para aplicaciones en producción. Stack 4, etiquetado como Para aplicaciones ligeras y proyectos individuales, basta para empezar. La página indica que pasar de Stack 4 a Stack 32 es sencillo y que tu entorno se mueve contigo. Para dimensionar el servidor según todo lo demás que vayas a ejecutar en él, consulta qué plan VPS necesitas.

Lo que PostgreSQL a secas deja en tus manos

Tu backend se encarga de esas tareas, y Rails y Django traen gran parte de serie. Rails incluye un generador de autenticación, Active Storage gestiona las subidas y las variantes de imagen, y Action Cable da WebSockets al navegador. Django tiene un sistema integrado de autenticación de usuarios, y Channels añade WebSockets. Una aplicación Express los añade como bibliotecas; por ejemplo, Socket.IO para una conexión bidireccional en directo entre el navegador y tu servidor.

El propio PostgreSQL cubre parte de la lista. Sus políticas de seguridad de filas limitan, para cada usuario, qué filas devuelve o modifica una consulta, y las reglas de acceso de Supabase son esas mismas políticas. LISTEN y NOTIFY envían un evento a cada sesión de la base de datos que esté escuchando, así que un proceso en segundo plano de tu backend puede reaccionar a las filas nuevas. Un navegador no abre sesiones de base de datos, así que las actualizaciones en directo en el navegador pasan por un servidor WebSocket propio, como Action Cable, Channels o Socket.IO. Las extensiones como pgvector y PostGIS se instalan en nuestro servidor de PostgreSQL con acceso root completo.

Si lo que echarías de menos es la API automática, puedes ejecutar PostgREST por separado. Es el servidor web que hay detrás de la API REST de Supabase, y su README dice que serves a fully RESTful API from any existing PostgreSQL database.

Supabase autoalojado en el día a día

La página de autoalojamiento de Supabase enumera lo que asumes al ejecutarlo: el mantenimiento del servidor, mantener actualizados el sistema operativo y los servicios, el mantenimiento de Postgres, la alta disponibilidad y las copias de seguridad y la recuperación.

• HTTPS. La configuración Docker de Supabase responde por HTTP sin cifrar, lo cual vale para una máquina de pruebas. Para producción, la guía de proxy de Supabase coloca Caddy o Nginx con Let’s Encrypt delante de la pasarela.
• Correo electrónico. La configuración Docker predeterminada de Supabase activa el registro por correo con confirmación y dirige el correo a un contenedor que solo existe en el archivo de desarrollo de Supabase. Añade tu propio servidor SMTP antes de que se registren usuarios reales, o no se enviarán los correos de confirmación ni de restablecimiento de contraseña.
• Actualizaciones. La guía de Docker de Supabase indica que publica una instantánea estable aproximadamente una vez al mes. Su script de actualización combina la configuración de la nueva versión con la tuya. Después, descargas las nuevas imágenes y recreas los contenedores. Haz una copia de seguridad antes de ejecutarlo.
• Proyectos. Cada instalación ejecuta un solo proyecto. Studio autoalojado no admite varias organizaciones ni proyectos, así que una segunda aplicación necesita su propia instalación.

La guía paso a paso de autoalojamiento recoge los pasos de configuración, y la guía de Docker de Supabase es la referencia para cada ajuste.

Cómo lo medimos

En DreamHost ejecutamos ambos stacks el 19 de octubre de 2026 en una VM de prueba local con 2 vCPU y 7922 MiB de memoria: Ubuntu 24.04.4 en arm64, con Colima en un Mac con Apple silicon. Nuestros planes funcionan con procesadores x86 AMD EPYC, así que no era un servidor de DreamHost. Además, el tamaño de las imágenes cambia según el procesador, y por eso la tabla también indica la descarga para x86.

Supabase se ejecutó desde su carpeta de Docker v0.8.3 tal como se publicó, con secretos generados por sus propios scripts de claves. PostgreSQL se ejecutó desde el archivo compose de ejemplo de Docker Hub, fijado en postgres:17.11 y sin su servicio Adminer. Cada cifra de memoria es la mediana de 12 lecturas de docker stats, una cada 5 segundos, a partir de los 10 minutos tras el arranque. Descargamos las imágenes antes de cronometrar los arranques.

El 20 de octubre volvimos a ejecutar Supabase en una segunda VM del tamaño de Stack 4, con 2 vCPU, 3904 MiB de memoria y sin swap, con las mismas versiones de Ubuntu y Docker. Usamos una copia nueva de la misma carpeta v0.8.3, secretos nuevos y las mismas 12 lecturas pasados 10 minutos. En esa VM también se estaba ejecutando una pequeña app de prueba sin relación, de unos 180 MiB, que no se incluye en ninguna de las cifras de Supabase que citamos.

Ejecutamos cada configuración una sola vez, así que no hay variación que comunicar. Las pruebas cubren un stack en reposo y lo que funciona nada más instalar. No cubren una app bajo carga ni una semana de funcionamiento, y no probamos con Logs & Analytics activado.

Preguntas frecuentes sobre Supabase o PostgreSQL a secas