Supabase abre Multigres: failover automático en Postgres

Supabase abre la alpha privada de Multigres

Supabase abrió la alpha privada de Multigres, un sistema que corre Postgres en tres nodos distribuidos entre zonas de disponibilidad y promueve una réplica automáticamente en cuestión de segundos si el primario falla. Hasta ahora, cada proyecto de Supabase escribía en un único primario de Postgres: si el hardware fallaba o la zona de disponibilidad se caía, la base de datos quedaba inaccesible hasta recuperarla.

Para un founder, la diferencia es concreta: el downtime de base de datos no se mide en minutos de ingeniería, se mide en carritos abandonados, usuarios que no vuelven y confianza perdida. La propuesta de Multigres es que ese trabajo deje de ser un proyecto interno de infraestructura y pase a ser una casilla que se activa al crear el proyecto.

¿Qué es Multigres y por qué Supabase lo lanza ahora?

Multigres es un sistema operativo open source para Postgres, construido por el equipo detrás de Vitess, la tecnología creada en YouTube para escalar MySQL. Supabase anunció Multigres en 2025, liberó la versión v0.1 bajo licencia Apache 2.0 y lo mostró por primera vez en Supabase Select el 2 de octubre. Esta alpha privada es la primera vez que corre sobre la plataforma de Supabase.

¿Y esto cómo se aplica en tu negocio?

Dueños de negocio de Latinoamérica y España usan un agente de IA para ganar más y recuperar su tiempo. El Kit «tu mano derecha con IA» te muestra cómo en un video de 11 minutos, con una ficha para armar el tuyo. CAR está cerrada por ahora; al anotarte, te avisamos cuando abra.

👥 Quiero el Kit →

Un punto clave de arquitectura: Multigres no es un fork de Postgres. Los datos viven en Postgres estándar y Multigres administra el clúster alrededor — enrutamiento de conexiones, pooling, replicación, failover y backups. Eso importa porque evita el lock-in técnico que suele venir con las bases de datos propietarias.

El contexto de la compañía ayuda a entender el timing. Según PR Newswire, Supabase anunció el 2 de octubre de 2026 una ronda de US$150 millones liderada por GIC, con CapitalG, IronArc y SquarePeg, apenas cuatro meses después de su Serie F de US$500 millones. La misma compañía reportó que suma más de 1 millón de usuarios y 4 millones de bases de datos por mes, con el 70% de las bases nuevas creadas por agentes o herramientas de IA. Cuando ese volumen de proyectos nace sin un DBA detrás, la operación de la base de datos se vuelve el cuello de botella.

¿Cómo funciona el failover basado en consenso?

La mayoría de las herramientas de alta disponibilidad para Postgres tratan el failover como un problema de monitoreo: detectan que el primario desapareció, eligen una réplica y la promueven. El problema es elegir una réplica segura. Si el primario anterior confirmó un commit que nunca llegó a la réplica promovida, esa escritura se pierde aunque la aplicación ya la haya dado por exitosa.

Multigres lo trata como un problema de consenso. Usa un protocolo de consenso generalizado sobre replicación síncrona de Postgres: la aplicación solo recibe confirmación de una escritura cuando esta se replicó en suficientes nodos como para sobrevivir a una falla. Cuando el primario cae, los nodos restantes acuerdan el conjunto completo de escrituras confirmadas y verifican que la réplica a promover las tenga todas antes de aceptar escrituras nuevas.

Además, durante el failover la pasarela de Multigres puede retener las peticiones entrantes hasta que el nuevo primario esté listo, en lugar de devolver errores de conexión a la aplicación. Ese detalle es el que separa una caída visible para el usuario de un bache interno.

Pooling sin elegir modo

Con PgBouncer, hay que decidir el modo de pooling por adelantado. El modo transacción permite que muchos clientes compartan pocas conexiones, pero restringe funciones a nivel de sesión. El modo sesión soporta esas funciones, pero cada cliente retiene una conexión mientras esté conectado.

Multigres analiza cada petición y rastrea el estado de sesión que genera, así que decide por sí mismo cómo manejar cada consulta. No hay modo que elegir. Cada usuario de base de datos obtiene su propio pool, y un algoritmo de reparto equitativo divide el presupuesto de conexiones entre usuarios para que un rol con mucho tráfico no deje sin recursos a los demás. Las sentencias preparadas se deduplican, de modo que Postgres las parsea y cachea una sola vez en lugar de una vez por cliente.

¿Qué incluye la alpha y qué limitaciones tiene?

Al crear un proyecto con Multigres habilitado obtienes:

Un clúster de tres nodos repartidos entre zonas de disponibilidad de una misma región.
Failover automático con promoción de réplica en segundos.
Connection pooling integrado, sin pooler separado que configurar.
Una sola cadena de conexión estándar de Postgres: no hay que cambiar el código de la aplicación.
Buena parte de Supabase: Auth, la API REST de datos, Storage, Edge Functions y las librerías cliente funcionan con proyectos Multigres.

Las limitaciones son igual de importantes y conviene leerlas antes de entusiasmarse:

No es para producción. Los proyectos Multigres no están cubiertos por el SLA de uptime durante la alpha.
Se elige al crear el proyecto. No se puede habilitar en un proyecto existente y hoy no hay camino gestionado de vuelta a un proyecto estándar de Postgres.
Sin Realtime, porque Multigres todavía no soporta replicación lógica.
Sin Point-in-Time Recovery. Solo hay backups diarios estándar.
Una sola región: únicamente East US (North Virginia), sin réplicas de lectura entre regiones.
Tamaño fijo: cómputo, disco y número de réplicas no se pueden cambiar después de crear el proyecto.
Multigres u OrioleDB, no ambos en el mismo proyecto.

Multigres es gratis durante la alpha para hasta dos proyectos por organización. No está disponible en el plan Free y el precio puede cambiar cuando salga de la alpha.

¿Qué significa esto para tu startup?

Lo primero es no confundir disponibilidad con madurez. Que Supabase ofrezca failover automático no significa que debas migrar tu base de producción esta semana: la propia compañía dice que no está cubierta por el SLA y que no hay vuelta atrás gestionada. La lectura correcta es que la alta disponibilidad de Postgres está dejando de ser un privilegio de equipos con infraestructura dedicada.

Dos acciones concretas que puedes tomar ahora:

Audita tu costo real de downtime antes de decidir. Calcula cuánto facturas por hora y cuántas horas al año has tenido la base caída. Si ese número es pequeño, el primario único sigue siendo la opción sensata y más barata. Si es grande, Multigres entra en la conversación.
Usa la alpha como entorno de prueba, no como producción. Crea un proyecto Multigres con el mismo esquema y las mismas consultas que tu app real, y mide cómo se comporta el pooling bajo tu carga. Así llegas con datos cuando la función salga de la alpha y el precio se defina.

Hay un tercer punto que suele pasarse por alto: el failover basado en consenso ataca un problema que muchos equipos ni saben que tienen. Si hoy corres réplicas manuales o un gestor de failover casero, la pregunta no es si tu sistema promueve una réplica, sino si esa réplica tiene todas las escrituras confirmadas. Un failover que pierde un commit silenciosamente es peor que una caída visible, porque corrompe datos sin avisar.

Para el ecosistema hispanohablante, donde muchos equipos operan con plantillas pequeñas y sin un DBA dedicado, este tipo de abstracción tiene un valor particular: permite sostener aplicaciones con tráfico real sin contratar el perfil más caro y escaso del mercado. La contrapartida es la de siempre — dependes de que el proveedor resuelva bien lo que antes controlabas tú. Con una alpha privada, sin SLA y sin camino de retorno, la decisión razonable es observar de cerca y preparar el terreno.