Novedades de Supabase: semana del 30/9 al 6/10/2026

Esta semana Supabase marcó una fecha límite: los cuatro adaptadores de frameworks de @supabase/server (Hono, H3, Elysia y NestJS) se eliminan el 1 de diciembre de 2026, y quien los use tiene que pasarse a los nuevos "bridges". En paralelo, @supabase/middleware llegó a la versión 1.0 y OrioleDB pasó a beta pública también en los planes pagos. Si estás suscripto a la página de estado por SMS, webhook u otro canal que no sea email, tenés que volver a suscribirte después del 7 de octubre.

Esta es la primera edición semanal de nuestro resumen de Supabase en español. Cubre del 30 de septiembre al 6 de octubre de 2026. Los anuncios del evento Select 2026 y la compra de Turso ya los contamos en detalle en Supabase Select 2026 y la compra de Turso: qué cambia para tu backend, así que acá no los repetimos.

Resumen de la semana#

Lo que tenés que revisar ya#

Los adaptadores de frameworks de @supabase/server se eliminan el 1 de diciembre#

El 5 de octubre Supabase anunció en su changelog la deprecación de los cuatro adaptadores de frameworks que trae @supabase/server (el paquete para usar Supabase del lado del servidor):

• @supabase/server/adapters/hono
• @supabase/server/adapters/h3
• @supabase/server/adapters/elysia
• @supabase/server/adapters/nestjs

Se eliminan el 1 de diciembre de 2026 y Supabase aclara que no va a aceptar adaptadores nuevos. El reemplazo son los "bridges": archivos únicos que copiás a tu proyecto y que conectan el motor de middleware de Supabase con tu framework. Los proyectos autohospedados (self-hosted) no están afectados, porque el cambio es en la librería y no en la plataforma.

A quién afecta: a quien tenga un backend en Node con Hono, H3 (o Nuxt), Elysia o NestJS que importe algo de @supabase/server/adapters.

Qué hacer, según los pasos del changelog:

1. Buscá en tu código todas las importaciones de @supabase/server/adapters.
2. Reemplazá cada valor de auth por su equivalente; por ejemplo, auth: 'user' pasa a withRequiredClaims(). El changelog advierte que no uses withClaims() en lugar de auth: 'user'.
3. Agregá @supabase/middleware como dependencia directa.
4. Copiá el bridge de tu framework desde la carpeta examples/frameworks del repositorio supabase/server.
5. Cambiá los registros por llamadas al bridge, por ejemplo toHono([withRequiredClaims(), withSupabaseClient()]).
6. Actualizá los accesos al contexto: ahora son claves planas como c.var.supabase y c.var.jwtClaims, en lugar del objeto anidado supabaseContext.
7. Verificá que el proyecto compile sin errores de tipos y que las solicitudes anónimas reciban un 401.

Los bridges requieren @supabase/server 1.6.0 o superior y Node 22 o superior. La guía de frameworks lista los bridges disponibles: toHono() para Hono, toH3() para H3 y Nuxt, wrapElysia() y supabaseCtx() para Elysia, toNestGuard() para NestJS y toTanStackStart() para TanStack Start. Este es el ejemplo oficial para Hono:

app.use('*', toHono([withRequiredClaims(), withSupabaseClient()]))
.get('/todos', async (c) => {
  const { data } = await c.var.supabase.from('todos').select()
  return c.json(data)
})

Si seguís la página de estado por SMS, Slack o webhook, volvé a suscribirte#

Supabase avisó el 30 de septiembre que el 7 de octubre, de 15:00 a 17:00 UTC (12:00 a 14:00 en Argentina), migra su página de estado a otra plataforma. La dirección sigue siendo https://status.supabase.com. Las suscripciones por email se migran solas, pero las de "SMS, Slack, webhook, RSS, etc." no se trasladan y hay que volver a crearlas. La plataforma nueva solo ofrece notificaciones por email, RSS y Slack, así que si recibías avisos por SMS o webhook (por ejemplo, para disparar una automatización), vas a tener que pasarte a uno de esos tres canales. Lo bueno: vas a poder suscribirte solo a los productos, servicios y regiones que usás.

Novedades de la semana#

@supabase/middleware llega a la versión 1.0#

El 30 de septiembre Supabase publicó la versión 1.0 de @supabase/middleware, que el changelog define como "a small, MIT-licensed engine for per-request logic on Web Fetch handlers": un motor chico, de código abierto, para ejecutar lógica en cada solicitud (autenticación, CORS, identificadores de pedido, etc.) en funciones que usan el estándar Fetch.

Para qué sirve: escribís una pieza de middleware una vez y la reutilizás en distintos entornos. Según el anuncio, corre "wherever fetch runs": Supabase Edge Functions, Vercel Functions, Cloudflare Workers, Deno, Bun y Node 22 o superior.

Qué trae la 1.0:

• defineMiddleware para escribir cada pieza de lógica.
• pipeline([...], handler) para encadenar varias en orden.
• Contexto tipado que se comparte entre middlewares.
• Dos middlewares incluidos: withCors y withFeatureFlag.
• La posibilidad de interceptar la respuesta, no solo la solicitud.

Desde la 1.0 el paquete sigue versionado semántico: los cambios incompatibles solo llegan en una versión mayor nueva. Está en npm y en JSR con la etiqueta latest. La release middleware-v1.0.0 en GitHub se publicó el mismo 30 de septiembre.

A quién le sirve: a equipos que escriben APIs en Edge Functions o en otro runtime y repiten la misma validación de usuario en cada endpoint. @supabase/server está construido sobre este motor y ofrece middlewares listos como withSupabase, withRequiredClaims, withSupabaseClient y withOAuthProtectedResource.

Cómo empezar: se instala con npm install @supabase/middleware. El changelog incluye este ejemplo para una Edge Function que exige un usuario autenticado y consulta una tabla:

import { pipeline } from 'npm:@supabase/middleware@1'
import { withOAuthProtectedResource, withSupabase } from 'npm:@supabase/server@1'

Deno.serve(
  pipeline(
    [withOAuthProtectedResource(), withSupabase({ auth: 'user' })],
    async (req, { supabase }) => {
      const { data } = await supabase.from('tasks').select('id, title')
      return Response.json(data)
    },
  ),
)

Para escribir tus propios middlewares está la guía de autoría del repositorio.

OrioleDB pasa a beta pública también en los planes pagos#

En Select 2026 Supabase había mencionado OrioleDB en beta pública, como contamos en nuestra nota sobre Select 2026. El 1 de octubre el changelog precisó qué implica: ahora podés crear proyectos con OrioleDB en los planes Pro, Team y Enterprise, "not only Free", con las mismas funciones pagas que cualquier otro proyecto. Se facturan igual que un proyecto Postgres estándar.

OrioleDB es un motor de almacenamiento de código abierto para Postgres que, según el post de Supabase sobre escalar sin límites, reemplaza el almacenamiento tradicional y elimina el "bloat" (filas muertas que ocupan espacio en las tablas) y la necesidad de VACUUM. La versión disponible es OrioleDB beta18 sobre Postgres 17.11.

Qué funciona: cambio de tamaño de cómputo y disco, pausa y restauración, actualizaciones de versión de Postgres, réplicas de lectura y backups programados.

Qué no funciona todavía en la beta:

• Point-in-Time Recovery (PITR, restaurar la base a un momento exacto).
• Restaurar un backup en un proyecto nuevo.
• Los índices que no son B-tree, incluido HNSW de pgvector, pasan por un puente experimental.
• Las extensiones plv8, plls, plcoffee y timescaledb-apache no están disponibles.

La documentación de OrioleDB suma otras limitaciones del motor, como que todavía no implementa CLUSTER ni VACUUM FULL y que CREATE INDEX CONCURRENTLY tiene restricciones.

Cómo empezar: al crear un proyecto, en Advanced Configuration > Postgres Type, elegí "Postgres with OrioleDB". Para desarrollo local, supabase init --use-orioledb, que requiere la CLI v2.119.0 o superior. Los proyectos autohospedados no están afectados por este cambio.

Nuestra lectura: si tu proyecto depende de PITR o de pgvector con HNSW, todavía no es momento de usarlo en producción. Para una base nueva con mucha escritura, vale la pena probarlo en un entorno de prueba.

Incidentes de la semana#

La página de estado registró latencia intermitente en el API Gateway para clientes que se conectan desde el este de Estados Unidos, sobre todo en horario laboral de esa zona y cerca de los minutos :00 y :30. El problema se identificó el 29 de septiembre y afecta a quien se conecta desde esa región, sin importar dónde esté alojado el proyecto. El 1 de octubre los socios de red de Supabase aplicaron una mitigación y la empresa registró una "significant improvement" en la latencia, pero el 2 de octubre informó que "some users are still experiencing issues" en horas pico. Si tu app o tus servidores están en esa zona y notaste lentitud, este es el motivo probable.

Preguntas frecuentes#

¿Mi proyecto deja de funcionar el 1 de diciembre si uso los adaptadores?#

Lo que se elimina son los adaptadores de @supabase/server, no tu proyecto en Supabase. Si tu backend importa @supabase/server/adapters/hono, h3, elysia o nestjs, a partir de esa fecha esas importaciones dejan de estar disponibles en el paquete, así que conviene migrar a los bridges antes.

¿Tengo que usar @supabase/middleware si ya uso supabase-js?#

No. Es una herramienta opcional para organizar la lógica que se repite en cada solicitud de tus funciones o APIs. Solo pasa a ser necesaria si migrás desde los adaptadores deprecados, porque los bridges la usan como dependencia.

¿Puedo pasar mi proyecto actual a OrioleDB?#

El changelog explica cómo crear un proyecto nuevo con OrioleDB, no cómo convertir uno existente. Hoy la opción aparece al crear el proyecto, en la configuración avanzada.

¿OrioleDB cuesta más que Postgres normal?#

No. Según Supabase, los proyectos con OrioleDB se facturan igual que los proyectos Postgres estándar.

¿Necesitás ayuda con tu proyecto en Supabase?#

Si tu backend usa los adaptadores que se deprecan, o querés evaluar OrioleDB sin arriesgar tus datos, en Mark-Co Digital podemos ayudarte con la implementación de Supabase y con todo lo que hacemos en Supabase. Y si estás revisando tokens y claves de acceso, te puede servir nuestra guía sobre claves de API expuestas en GitHub y cómo proteger las de tu pyme. Escribinos desde nuestra página de contacto.

Fuentes#

• Supabase Changelog
• Supabase Changelog: Framework adapters in @supabase/server are deprecated
• Supabase Changelog: Supabase Middleware 1.0
• Supabase Changelog: OrioleDB is now in Public Beta with paid plans and paid features
• Supabase Docs: Frameworks (@supabase/server)
• GitHub: supabase/server, examples/frameworks
• GitHub: supabase/middleware releases
• GitHub: supabase/middleware authoring guide
• Supabase Blog: Scale without limits: Multigres, OrioleDB, and dbarena
• OrioleDB Docs: Getting started, current limitations
• Supabase Status: Statuspage migration
• Supabase Status: Intermittent latency in Eastern US
• Mark-Co Digital: Supabase Select 2026 y la compra de Turso