Supabase Select 2026: Multigres, OrioleDB y dbarena

Tres anuncios para borrar tres cuellos de botella clásicos de Postgres

Supabase eligió su conferencia Select 2026 para atacar, en una sola jornada, tres problemas históricos de Postgres cuando una aplicación crece: la falta de alta disponibilidad con cero pérdida de escrituras, la deuda operativa del VACUUM y el wraparound de transacciones, y la opacidad de los benchmarks de proveedores administrados. Los tres anuncios —Multigres, OrioleDB y dbarena— son open source y se entregan como capas que se pueden activar sobre el Postgres que ya gestionas.

La jugada llega en un momento concreto: Supabase reveló en su comunicado de prensa que hoy suma más de 1 millón de usuarios y 4 millones de bases de datos nuevas cada mes, con el 70% de esas nuevas bases desplegadas por agentes o herramientas de IA. La propia compañía enmarca la conferencia como su respuesta directa a ese crecimiento: escalar Postgres sin que el desarrollador tenga que pagarlo con operaciones.

Multigres: alta disponibilidad y pooling sin perder una sola fila

Multigres es un "sistema operativo" open source para Postgres construido por el equipo detrás de Vitess, el proyecto que sostiene los sharding de MySQL en YouTube desde 2010. Lo lidera en Supabase Sugu Sougoumarane, cocreador de Vitess y antiguo CTO de PlanetScale, que se reincorporó tras un año sabático para traer ese modelo de orquestación al mundo Postgres.

👥 ¿Quieres ir más allá de la noticia?

En nuestra comunidad discutimos las tendencias, compartimos oportunidades y nos ayudamos entre emprendedores. Sin humo, solo acción.

👥 Unirme a la comunidad

El problema concreto que ataca Multigres es doble. Primero, el patrón clásico de replicación primary / standby en Postgres tiene una debilidad conocida: si el primario falla antes de que una escritura se replique al standby, esas filas pueden perderse. Multigres lo resuelve con un protocolo de consenso generalizado construido sobre la replicación síncrona de Postgres: si un nodo cae, el cluster se pone de acuerdo en qué escrituras quedaron confirmadas antes de aceptar nuevas y promueve una réplica en segundos. Cada escritura confirmada sobrevive al failover.

Segundo, el connection pooling. Hoy, una sola instancia de Postgres maneja un número finito de clientes concurrentes y forzar a los equipos a desplegar un pooler separado añade complejidad. Multigres trae pooling escalable integrado: la aplicación puede conectar muchos más clientes sin tocar su código. En alpha privada corre tres nodos Postgres a través de zonas de disponibilidad dentro de una misma región, así que perder una zona no tira la base de datos abajo. Durante el alpha, Supabase añade las réplicas de lectura y los gateways por ti.

Multigres está en alpha privada por invitación, es compatible con Supabase Auth, Storage y Edge Functions, y la propia compañía lo etiqueta para pruebas, no para cargas de producción todavía.

OrioleDB: el motor de almacenamiento que quiere jubilar al VACUUM

OrioleDB es un motor de almacenamiento open source para Postgres que reemplaza el heap tradicional. Lo desarrolla Supabase desde 2021 junto a contribuidores externos, entre ellos Alexander Korotkov, uno de los contribuidores más activos al Postgres upstream y uno de los creadores originales del motor, que ahora trabaja en la propia Supabase.

El heap de Postgres tiene tres limitaciones que cualquier operación a escala conoce de memoria: bloat, VACUUM constante y wraparound de XIDs de 32 bits. OrioleDB ataca las tres a la vez.

La pieza clave es el undo log a nivel de página. En el heap, un UPDATE nunca modifica la fila en su lugar, deja una copia vieja como dead tuple, y limpiar esos cadáveres exige al famoso VACUUM corriendo permanentemente. OrioleDB escribe la información inversa en un registro de undo que el sistema reclama solo, así que el bloat desaparece y el VACUUM deja de ser necesario. Además, como las lecturas de página son lock-free, el motor rinde mejor bajo concurrencia alta, sobre todo en cargas con mucha E/S.

El número que Supabase muestra en sus benchmarks públicos de dbarena es hasta 1,8 veces más throughput que el heap de Postgres en workloads derivados de TPC-C. En pruebas internas publicadas por el equipo de OrioleDB en su beta12, sobre una instancia Supabase 2XL con almacenamiento io2, el motor llegó a 218.716 tpmC frente a 83.653 del heap en la misma instancia 16XL, más del doble incluso con la fruta.

El otro frente es claro. Con heap, los XIDs son de 32 bits y se guardan en cada versión de fila: pasarlos a 64 bits añade 8 bytes por fila y se propaga por miles de millones de versiones con tuplas muertas, más páginas, más I/O, índices más grandes. OrioleDB rompe ese compromiso: como su MVCC ya no se apoya en el formato de tupla heredado del heap, los XIDs de 64 bits se adoptan sin heredar la penalización. Se acabó el ritual de congelar filas para evitar que el reloj se quede sin números.

OrioleDB está en beta pública: al crear un proyecto nuevo en Supabase aparece como opción en configuración avanzada. Y se puede mezclar: USING orioledb o USING heap por tabla dentro del mismo proyecto.

dbarena: benchmarks abiertos donde el método se puede auditar

dbarena.com es el tercer anuncio y, aunque parece el menos técnico, es el más incómodo para la competencia. Es un sitio de benchmarks abiertos y reproducibles entre proveedores de Postgres administrado, con el código, la metodología, los datos crudos descargables y enlaces compartibles de comparación. Al lanzamiento compara Supabase, Amazon RDS y Google Cloud SQL.

Para cada corrida, dbarena publica transacciones por dólar, costo total mensual, transacciones por minuto, p95 y especificaciones del hardware, y dibuja el throughput a lo largo del tiempo. La regla editorial es dura y razonable a la vez: cada resultado se puede verificar de forma independiente, las comparaciones se normalizan por costo y la metodología es pública. Cualquier proveedor puede replicar el test en su infraestructura y publicar su propio resultado con la misma metodología.

El problema que viene a resolver es real. Los benchmarks de los proveedores suelen correr en condiciones favorables para ellos, los benchmarks de la comunidad son fotos de un momento y armar una evaluación seria internamente cuesta semanas de trabajo. dbarena pretende ser la respuesta neutral y reproducible, y para los founders significa que la próxima vez que evalúen dónde alojar su Postgres, van a poder comparar con números comparables en lugar de folletos.

El contexto: Supabase en plena explosión agentica

Estos tres lanzamientos llegan envueltos en una operación financiera que la propia Supabase anunció el mismo día: US$150M en una nueva ronda liderada por GIC, con CapitalG (el fondo independiente de Alphabet), IronArc y SquarePeg, apenas cuatro meses después de cerrar una Serie F de US$500M con valoración pre-money de US$10B, según reportó TechCrunch en junio. La nota de prensa añade que Supabase también está adquiriendo Turso, la plataforma de bases de datos por agente creada por Glauber Costa, que se incorpora como Head of Agentic Services.

Lo que hace tangible el momento para un founder son dos cifras del propio comunicado. Primero, el 70% de las nuevas bases de datos en Supabase las crean hoy agentes o herramientas de IA, no humanos. Eso explica por qué la urgencia de la conferencia fue eliminar cada fricción operativa que Postgres impone: si un agente tiene que aprovisionar, hacer failover o tunear VACUUM, no escala.

Segundo, la base instalada: más de 13 millones de desarrolladores usan Supabase según el comunicado, tras un crecimiento interanual de bases de datos del 600% medido en junio. Cuando tu usuario típico es un agente que crea y destruye bases de datos por minuto, los cuellos de botella del heap, los connection limits y la falta de HA dejan de ser problemas de DBA y se vuelven problemas de producto.

¿Qué significa esto para tu startup?

Si estás construyendo producto sobre Postgres, esta tanda cambia tres decisiones que probablemente tienes pendientes.

1. Planifica la HA antes de tu primer incidente. Si hoy corres una sola instancia de Postgres y dependes de backups para recuperarte, estás aceptando pérdida de escrituras en cada failover. Multigres apunta exactamente a eso: cero pérdida de escrituras con consenso y failover en segundos. La acción concreta: revisa tu RPO actual, documenta cuántas escrituras puedes permitirte perder en el peor caso y evalúa si tiene sentido moverte a una arquitectura con consenso cuando Supabase abra el beta. Mientras Multigres esté en alpha, al menos deja escrita la decisión de migrar.

2. Decide si tu carga es candidata a OrioleDB. El caso de uso fuerte es cualquier tabla con updates y deletes frecuentes que hoy te obliga a correr pg_repack, ajustar autovacuum o sobreprovisionar cómputo para mantenerlo al día. La acción concreta: identifica las tablas con más dead tuples según pgstattuple, mide cuánto IOPS y CPU te consume VACUUM hoy y crea un proyecto nuevo en Supabase con OrioleDB activado para mover esas tablas con USING orioledb. Vas a poder comparar el comportamiento en producción sin tocar el resto.

3. Usa dbarena antes de tu próxima decisión de proveedor. La próxima vez que evalúes RDS, Cloud SQL o Supabase para una carga seria, entra a dbarena.com y replica el test con tu propia carga sintética. La acción concreta: descarga los datos crudos de un test comparable a tu perfil de uso y grafica transacciones por dólar a tu escala, no a la escala del folleto. Si la diferencia de costo por transacción es de 3x a 5x, esa cifra vale más que cualquier descuento negociado.

Y un punto para founders que están vendiendo infraestructura o herramientas para agentes: la propia Supabase dijo que el 70% de sus nuevas bases las crean agentes. Si tu producto backend no está diseñado para ser aprovisionado, escalado y observado por otro software, vas a perder a la capa de clientes que más rápido se está moviendo.

Conclusión

Los tres anuncios de Supabase Select 2026 son, en el fondo, la misma jugada contada tres veces: quitar de la mesa las tres excusas históricas para no correr Postgres a escala. Multigres resuelve el miedo al failover con pérdida de datos, OrioleDB jubila al VACUUM, y dbarena le quita el argumento al vendor que decía ser el más rápido. Todo open source, todo sobre el Postgres que ya conoces, todo lanzado en un día en el que la propia Supabase anunció US$150M adicionales y la adquisición de Turso para empujar el caso de los agentes. Para founders hispanohablantes construyendo sobre Postgres, la señal práctica es clara: el costo operativo de escalar tu backend en Supabase acaba de bajar, y el de defender tu stack legacy acaba de subir.