El mejor VPS para Supabase autohospedado de 2026
Autoalojar Supabase implica ejecutar aproximadamente quince contenedores Docker, no una sola aplicación. Incluye PostgreSQL, GoTrue para la autenticación, PostgREST para la API, Realtime para las suscripciones WebSocket, almacenamiento, Kong como puerta de enlace, Studio para el panel de control y servicios de soporte. Es una plataforma, y su tamaño se ajusta a ello.
Por eso, las recomendaciones que verá varían desde "2 GB funcionan" hasta "16 GB como mínimo"; ambas son ciertas, para diferentes implementaciones:
- 2 GB y 1-2 vCPU Ejecuta una instancia de desarrollo o de prueba desechable. Funcionará y tendrá un rendimiento óptimo.
- 4 GB y 2 vCPU es el nivel de producción más realista. Solo PostgreSQL requiere entre 1 y 2 GB antes de que se inicien los otros catorce contenedores.
- 8–16 GB Es ahí donde debería estar una aplicación de producción con tráfico real, con espacio para que la base de datos ocupe memoria.
- La E/S del disco es más importante que la CPU. Supabase utiliza PostgreSQL internamente, y un bajo rendimiento de E/S por segundo (IOPS) se refleja directamente en respuestas lentas de la API.
Comparación rápida
| Proveedor | Desde | NVMe | Ideal para |
|---|---|---|---|
| Hostinger | ~$5.84/mes | ✅ sí | La mejor relación precio-rendimiento |
| Digital Ocean | ~$4/mes | ✅ sí | Experiencia de desarrollador |
| Vultr | ~$6/mes | ✅ sí | Alcance global, baja latencia en el borde. |
| AWS (EC2) | Variable | ✅ sí | Empresa y cumplimiento normativo |
| Ferrocarril | Usage-Basado | ✅ sí | Despliegue instantáneo |
| Hetzner | ~$4.49/mes | ✅ sí | Memoria RAM por dólar |
| Liquid Web | ~$3.50/mes | ✅ sí | Opción gestionada |
Dimensionamiento de una pila de quince contenedores
Los servicios individuales son, en su mayoría, modestos. El problema es que hay muchos, y uno de ellos es una base de datos.
| Despliegue | CPU virtual | RAM | Almacenaje |
|---|---|---|---|
| Desarrollo / puesta en escena desechable | 1-2 | 2GB | 40GB |
| Aplicación de producción pequeña | 2 | 4GB | 80GB |
| Producción con tráfico real | 4 | 8GB | 160GB |
| Mayor producción | 4+ | 16GB + | 160GB + |
¿Por qué 2 GB no funcionan en producción? PostgreSQL requiere entre 1 y 2 GB para almacenar un conjunto de datos útil en búferes compartidos. Si a esto le sumamos GoTrue, PostgREST, Realtime, Storage, Kong, Studio y demás, además de la sobrecarga del sistema operativo y Docker, un servidor con 2 GB lo ejecuta todo sin apenas recursos disponibles. Funciona correctamente hasta que llega el tráfico; entonces Postgres empieza a acceder al disco para todo y la API se ralentiza por completo.
El almacenamiento crece en tres direcciones. La instalación base ocupa unos 10 GB. A continuación, se almacenan los datos, los registros y, por último, las copias de seguridad. Es recomendable empezar con 80 GB y planificar hasta 160 GB, ya que quedarse sin espacio en disco en un servidor de base de datos es un problema mucho peor que quedarse sin espacio en un servidor web.
Las IOPS merecen mayor atención de la que suelen recibir. Todo lo que hace una aplicación Supabase pasa por PostgreSQL. Un disco lento implica consultas lentas y, por lo tanto, respuestas lentas a la API, y ninguna cantidad de CPU lo soluciona. Esta es la razón principal por la que NVMe es indispensable para esta carga de trabajo, mientras que para muchas otras es simplemente una ventaja.
Qué evaluar realmente
Para Supabase, hay cuatro criterios que importan más que para un proveedor de alojamiento web general:
IOPS y latencia de la base de datos. Rendimiento de lectura y escritura, y latencia P95/P99 en lugar de promedios. El tipo de almacenamiento es lo primero, todo lo demás es secundario.
Estabilidad de red para Realtime. Supabase envía los cambios de la base de datos a través de WebSockets. Las conexiones que permanecen abiertas durante horas no toleran las fluctuaciones de la red, a diferencia del tráfico HTTP de solicitud-respuesta convencional, por lo que la latencia constante y los límites de conexión generosos son importantes.
Escalabilidad sin migración. Las bases de datos son lo más difícil de migrar. Un servidor donde se pueda agregar RAM y CPU directamente, en lugar de reconstruir en una instancia más grande y transferir datos, justifica la inversión adicional en este caso.
Rapidez en la implementación y el desmontaje. Reconstruirás esta pila varias veces mientras configuras correctamente las variables de entorno. El aprovisionamiento rápido y la compatibilidad con plantillas o IaC convierten ese proceso de una tarde en tan solo unos minutos.
Los 7 mejores proveedores de VPS para Supabase autohospedado
1. Hostinger — mejor relación precio-rendimiento
Hostinger Lo más importante aquí es la especificación clave: 8 GB de RAM en el nivel más común, con almacenamiento NVMe. Para una pila de quince contenedores con PostgreSQL como núcleo, esta combinación es fundamental: suficiente memoria para que Postgres mantenga un conjunto de datos de trabajo real en búferes y un disco lo suficientemente rápido para que las consultas que acceden al almacenamiento no ralenticen la API.
Sus herramientas Docker gestionan la pila de Compose de forma impecable, y usted conserva el acceso de administrador para la configuración que inevitablemente requiere una instalación autoalojada de Supabase. Las copias de seguridad semanales gratuitas son más importantes que nunca cuando se trata de una base de datos.
La virtualización KVM con recursos dedicados es otro requisito que se está cumpliendo discretamente: una pila de quince contenedores en una virtualización compartida sobrecargada no es una buena señal.
Ventajas: 8 GB en el nivel práctico; NVMe con un rendimiento de IOPS medido sólido; KVM con recursos dedicados; herramientas Docker; copias de seguridad semanales gratuitas; cortafuegos incluido; garantía de devolución de dinero de 30 días.
Desventajas: los precios promocionales requieren un largo plazo de prepago y la renovación tiene un precio más alto; para acceder a planes superiores, eventualmente será necesaria una migración.
Para quién es: la mayoría de las implementaciones de Supabase autohospedadas, desde entornos de prueba hasta pequeños entornos de producción.
Comprobar HostingerPrecios actuales de VPS →
2. DigitalOcean: la mejor experiencia para desarrolladores.
DigitalOcean es la opción ideal cuando las herramientas de apoyo son tan importantes como la propia plataforma. La documentación para ejecutar cargas de trabajo de Postgres en contenedores es realmente buena, la API y la CLI hacen que el entorno sea reproducible, y las instantáneas permiten crear un punto de control de una pila funcional antes de actualizar la versión de Supabase, algo que, dada la cantidad de componentes involucrados, querrás hacer al menos una vez.
También ofrece PostgreSQL administrado por separado, lo cual conviene saber: una solución intermedia válida consiste en autoalojar los servicios de Supabase y apuntarlos a una base de datos administrada, de modo que otra persona se encargue de las copias de seguridad, la conmutación por error y las actualizaciones de versión de la parte más importante.
El rendimiento por gigabyte es el más bajo en este caso, y se trata de una carga de trabajo que consume mucha memoria.
Ventajas: excelente documentación y API; instantáneas robustas; Postgres administrado disponible como vía intermedia; red privada; SLA del 99.99%; regiones globales.
Contras: es la memoria RAM más cara de esta lista; las copias de seguridad aumentan el precio en un 20% aproximadamente; no ofrece garantía de devolución de dinero.
A quién va dirigido: a equipos que desean una infraestructura reproducible y que podrían dividir la base de datos.
Consulta los precios actuales de DigitalOcean →
3. Vultr: el mejor alcance global.
La relevancia de Vultr para Supabase radica en su funcionalidad en tiempo real. Si tus usuarios están dispersos geográficamente y mantienen conexiones WebSocket, estar cerca de ellos mejora notablemente la experiencia, y Vultr cuenta con una de las listas de regiones más amplias disponibles.
Las instancias de alta frecuencia con NVMe también son útiles en el lado de la base de datos, ya que los núcleos más rápidos y el almacenamiento rápido en conjunto reducen la latencia de las consultas en los márgenes.
Sin plantilla, sin garantía de devolución de dinero, y la consola presupone competencia.
Ventajas: amplia selección de regiones para aplicaciones en tiempo real sensibles a la latencia; instancias NVMe de alta frecuencia; precios competitivos; buen rango de escalabilidad.
Contras: no incluye plantilla para Supabase; no ofrece garantía de devolución de dinero; sus herramientas son de uso básico.
A quién va dirigido: aplicaciones con usuarios distribuidos geográficamente que dependen de la información en tiempo real.
4. AWS (EC2): la mejor opción para empresas y cumplimiento normativo.
AWS está aquí para los casos en los que el requisito no es técnico. Los regímenes de cumplimiento, los estándares de adquisición, los acuerdos empresariales existentes o una organización que ya ejecuta todo lo demás en AWS: esas son limitaciones reales, y EC2 les da respuesta.
Las ventajas técnicas son las siguientes: RDS si se desea que la base de datos esté gestionada y separada, volúmenes EBS que se pueden redimensionar sin necesidad de reconstruirlos y una capacidad de escalabilidad prácticamente ilimitada.
El costo radica en la complejidad y el precio. El precio de EC2 es realmente difícil de predecir para una carga de trabajo como esta, una vez que se consideran el almacenamiento, la transferencia y el soporte, y la consola representa una constante exigencia de atención. Para una pequeña instancia de Supabase autohospedada, la plataforma es considerablemente más potente de lo que requiere la tarea.
Ventajas: todas las certificaciones de cumplimiento; RDS para una base de datos administrada; almacenamiento EBS redimensionable; escalabilidad ilimitada; se adapta a las infraestructuras de AWS existentes.
Contras: precios difíciles de predecir; complejidad operativa significativa; excesivo para implementaciones pequeñas.
A quién va dirigido: empresas, entornos regulados y equipos que ya utilizan AWS de forma estandarizada.
5. Ferrocarril: ideal para despliegue inmediato.
Railway es la forma más rápida de crear una infraestructura similar a Supabase desde cero. Es una plataforma, no un servidor: implementas los servicios, se encarga de la infraestructura y no hay que actualizar el sistema operativo.
Para la creación de prototipos, herramientas internas y proyectos donde el tiempo del desarrollador cuesta más que la capacidad de procesamiento, es un intercambio ventajoso.sageLa tarificación basada en precios significa que un proyecto tranquilo cuesta muy poco.
Las desventajas son las habituales de PaaS. Menos control de bajo nivel, usageLa facturación basada en Docker es más difícil de predecir a medida que aumenta el tráfico, y se basa en sus abstracciones en lugar de Docker puro. Para una pila de quince contenedores, normalmente se implementan los servicios individualmente en lugar de copiar el archivo Compose estándar completo.
Ventajas: Implementación más rápida; sin administración de servidores; usageLa tarificación basada en precios se adapta a proyectos tranquilos; experiencia de desarrollador limpia.
Desventajas: menor control que un VPS; costes menos predecibles a gran escala; no es compatible directamente con la pila estándar de Compose.
A quién va dirigido: prototipos, herramientas internas y equipos que prefieren no gestionar servidores.
Consulta los precios actuales del ferrocarril →
6. Hetzner: la mejor RAM por dólar.
En una carga de trabajo que consume tanta memoria, el coste por gigabyte es prácticamente un factor decisivo, y Hetzner se lleva la palma. Por unos 13.99 € se obtienen 4 vCPU y 8 GB (el nivel de producción con tráfico real), por un precio similar al de una instancia de 4 GB en el nivel premium.
Los volúmenes conectables son especialmente relevantes en este caso: el almacenamiento de la base de datos crece, y poder añadir discos sin migrar el servidor es precisamente la propiedad de "escalabilidad sin migración" que necesitan las implementaciones de Supabase.
Sin plantilla, sin acuerdo de nivel de servicio (SLA) publicado, copias de seguridad adicionales y verificación de registro lenta. Para una base de datos en producción, la falta de un SLA merece una reflexión profunda, no una simple indiferencia.
Ventajas: la mejor relación RAM por dólar, con mucha diferencia; volúmenes conectables para bases de datos en crecimiento; NVMe; facturación por horas con límite de gasto; ubicaciones que cumplen con el RGPD.
Contras: no hay un acuerdo de nivel de servicio (SLA) publicado, lo cual es más importante para una base de datos que para un servidor web; no hay plantilla; las copias de seguridad son adicionales; el proceso de registro es complicado.
A quién va dirigido: implementaciones que priorizan el ahorro de costes y necesitan memoria real, donde no se acepta ningún acuerdo de nivel de servicio (SLA).
Consulta los precios actuales de Hetzner →
7. Liquid Web: la mejor opción gestionada.
Liquid Web es la solución para equipos que desean la economía de Supabase autogestionada sin tener que administrar la capa de servidor. Sus planes gestionados delegan la actualización del sistema operativo, la monitorización y la respuesta a incidentes a un tercero, lo que, para una infraestructura que contiene su base de datos de producción, representa una inversión justificada en lugar de un lujo.
Los planes autogestionados comienzan con precios bajos y ofrecen acceso root completo si prefieres hacerlo tú mismo.
No incluye herramientas específicas de Supabase, no ofrece garantía de devolución de dinero y los planes gestionados cuestan considerablemente más de lo que indica el precio de entrada.
Ventajas: opción de gestión genuina; sólida reputación de soporte; hardware y NVMe robustos; acceso root completo en la opción autogestionada.
Desventajas: no incluye plantilla de Supabase; no ofrece garantía de devolución de dinero; los planes gestionados suponen un desfase de precio considerable.
A quién va dirigido: equipos que utilizan Supabase en producción sin un responsable de operaciones dedicado.
Consulta los precios actuales de Liquid Web →
¿Autogestionado o gestionado?
El autoalojamiento de Supabase le brinda la misma funcionalidad principal (Postgres, autenticación, almacenamiento, tiempo real, funciones de borde) a una fracción del precio de un plan administrado, con costos fijos en lugar de variables.sageFacturación basada en datos y sin límites en el crecimiento de la base de datos.
Lo que se pierde es la comodidad del panel de control y, lo que es más importante, la responsabilidad operativa. La configuración se realiza mediante archivos y variables de entorno en lugar de una interfaz gráfica, las actualizaciones se gestionan manualmente en quince contenedores y el soporte de la comunidad sustituye a un contrato de soporte.
Autoalojamiento cuando: costos en su usage El nivel es importante, necesita residencia de datos o control total, se siente cómodo con Docker y la administración básica del servidor, o los precios fijos y predecibles importan más que la conveniencia.
Utilice la opción gestionada cuando: El flujo de trabajo del panel de control es importante para tu equipo, nadie quiere ser dueño de las operaciones de la base de datos, o tusage Es lo suficientemente bajo como para que los precios gestionados sean realmente económicos. Para un proyecto pequeño, los planes gratuitos y de bajo costo de Supabase gestionado son difíciles de superar en cuanto al costo total, una vez que se calcula el precio del tiempo invertido.
Vale la pena repetir la solución intermedia: alojar los servicios de Supabase en su propio servidor, pero apuntarlos a una instancia administrada de PostgreSQL. De esta manera, se mantiene el control de costos y se elimina la parte del trabajo con los peores modos de fallo.
Como elegimos
Tuvimos en cuenta los criterios clave para una arquitectura multicontenedor centrada en bases de datos: memoria a precios razonables, tipo de almacenamiento y E/S, escalabilidad de RAM y disco sin necesidad de migrar, consistencia de red para conexiones WebSocket de larga duración y gestión de copias de seguridad. La memoria y el disco recibieron la mayor ponderación, ya que PostgreSQL es el componente que determina la velocidad de toda la plataforma.
Las cifras de requisitos reflejan las directrices publicadas para Supabase autoalojada, no nuestras propias pruebas de carga. Hemos indicado un rango en lugar de una cifra única, ya que el desarrollo y la producción difieren considerablemente, al menos en un factor de cuatro. Los precios corresponden a las tarifas publicadas por cada proveedor en el momento de redactar este informe. Dos de los siete proveedores mencionados no nos generan ningún ingreso.
Cómo escoger
- ¿Desarrollo o producción? 2 GB realmente funcionan para el primero y realmente fallan para el segundo.
- Priorizar NVMe y E/S sobre la CPU. Todo pasa por Postgres.
- ¿Se puede añadir RAM y disco duro en su lugar? Migrar una base de datos es algo que sin duda querrás evitar.
- ¿Importa el tiempo real? Si los usuarios mantienen conexiones WebSocket, la proximidad regional y la consistencia de la red suben en la lista de prioridades.
- Ponle precio en comparación con la gestión antes de comprometerse, incluyendo el tiempo que dedique a las actualizaciones y copias de seguridad.
Para la mayoría de la gente es Hostinger — 8 GB en NVMe en el nivel que realmente comprarías es la configuración correcta para esta pila. Hetzner si el costo por gigabyte domina y no se acepta ningún SLA, Digital Ocean para herramientas y la ruta intermedia de base de datos administrada, Vultr para tiempo real distribuido globalmente, Ferrocarril para omitir los servidores por completo, Liquid Web si quieres que lo gestionen, y AWS cuando el cumplimiento de la normativa o un patrimonio existente lo decidan por usted.
Preguntas Frecuentes
¿Cuáles son los requisitos mínimos para instalar Supabase de forma autogestionada?
Una instancia de desarrollo o de prueba mínima se ejecuta con 2 GB de RAM y 1 o 2 vCPU. Para producción, 4 GB y 2 vCPU es el mínimo realista, y entre 8 y 16 GB es lo ideal para una aplicación con tráfico real. El almacenamiento NVMe es más importante que la CPU, ya que todo se enruta a través de PostgreSQL. Comience con 80 GB de disco y planifique hasta 160 GB una vez que se acumulen datos, registros y copias de seguridad.
¿Por qué Supabase necesita tanta RAM?
Dado que no se trata de una sola aplicación, Supabase, autoalojada, ejecuta aproximadamente quince contenedores Docker: PostgreSQL, GoTrue para la autenticación, PostgREST para la API, Realtime, Storage, Kong como puerta de enlace, Studio para el panel de control y servicios de soporte. Solo PostgreSQL requiere entre 1 y 2 GB para un funcionamiento óptimo, y los contenedores restantes, junto con el sistema operativo y la sobrecarga de Docker, consumen el resto de un equipo pequeño.
¿Es más económico alojar Supabase por cuenta propia que utilizar un servicio gestionado?
En un momento significativo usage, sustancialmente — tú intercambias usagePrecios basados en un costo mensual fijo por servidor, sin límites en el tamaño de la base de datos. A pequeña escala, la administración suele ser más económica si se valora el tiempo, ya que se asumen las actualizaciones en quince contenedores, la verificación de copias de seguridad y la respuesta a incidentes. La opción intermedia es autoalojar los servicios en una instancia administrada de PostgreSQL.
¿Puedo ejecutar Supabase autoalojado en un VPS de 2 GB?
Para desarrollo, sí. Para producción, no: PostgreSQL necesita entre 1 y 2 GB antes de que se inicien los demás contenedores, por lo que un servidor de 2 GB no tiene suficiente memoria. Funcionará bien en las pruebas, pero su rendimiento se degradará en cuanto llegue el tráfico real, ya que Postgres leerá del disco las consultas que debería procesar desde la memoria. 4 GB es el mínimo recomendable para producción.
Blog y artículos
