Supabase Select 2026: backend declarativo y agentes con límites claros
Supabase mueve el schema y la configuración a código, deja que tu agente opere con permisos acotados, y suma motores de almacenamiento y alta disponibilidad para Postgres a escala.
El problema que resuelve este release
Tu agente de código ya escribe la lógica de tu aplicación, pero configurar el backend seguía siendo trabajo manual en el dashboard y en la documentación. Revisar producción y arreglar lo que se rompe también quedaba fuera del alcance del agente, porque esas tareas vivían en una interfaz web, no en el repositorio. Supabase ahora expone el schema y la configuración del proyecto como código, para que el agente pueda modificar el proyecto con los mismos archivos que usas tú. También puede revisar el proyecto y reportar problemas, pero la decisión de qué se aplica y se mergea sigue siendo tuya. Esa separación entre lo que el agente puede ver y lo que puede ejecutar sin confirmación es el eje de todo el anuncio.
Desarrollo local sin Docker
Hasta ahora correr Supabase localmente dependía de tener un daemon de Docker activo, lo que no funciona en entornos como el sandbox de Claude Code. Con esta función en alpha, Supabase local puede correr como procesos nativos del sistema operativo, sin esa dependencia. Además, podés levantar varias instancias locales de Supabase al mismo tiempo, una por directorio, así varios checkouts del mismo repositorio corren en paralelo sin pisarse. Está desactivado por defecto porque es alpha, así que necesitás actualizar la CLI de Supabase y activarlo explícitamente para probarlo.
Declarative Schemas 2.0
Antes, mantener el schema sincronizado entre el dashboard y el repositorio era manual: cambiabas algo en la UI y tenías que replicarlo a mano en tus archivos de migración. Con Declarative Schemas 2.0 escribís el schema como archivos SQL, y pg-delta genera la migración correspondiente, así el schema vive en el repo como fuente de verdad. La configuración del proyecto también pasa a vivir en código. Si alguien hace un cambio desde el dashboard, el comando trae ese cambio de vuelta al archivo para que no se pierda y quede versionado junto al resto del schema.
supabase config pullSupabase Compute y el MCP server de tu propia app
Supabase Compute, en alpha privada, permite correr servicios web y agentes en cualquier lenguaje junto a tu base de datos, sin límite de tiempo de ejecución, cada uno con un entorno Linux completo y las mismas variables de entorno por defecto que tus Edge Functions. En paralelo, ahora podés exponer un servidor MCP propio de tu aplicación, para que los usuarios conecten sus propios agentes. Ese servidor corre como una Edge Function junto a tus datos, los usuarios se autentican con tu flujo de Auth existente, y cada llamada a una herramienta se ejecuta como ese usuario, respetando tus políticas de RLS. Es distinto del servidor MCP oficial de Supabase, y se construye sobre el paquete @supabase/server y el nuevo Supabase Middleware, que también sirven por separado en cualquier código de servidor que necesite saber quién está autenticado.
@supabase/serverObservabilidad y agentes con acceso de solo lectura
Este bloque suma varias piezas para detectar problemas antes de que escalen. Los Agent Prompts te dan prompts listos y un calendario sugerido para chequeos de salud, seguridad, performance o recursos, que corrés en Claude, Codex o Cursor; el agente lee tu proyecto a través del servidor MCP de Supabase conectado en modo solo lectura y reporta hallazgos, sin poder modificar nada por sí mismo. Los Health Check Advisors ahora marcan tasas de error elevadas en Data API, Auth, Storage y Edge Functions, además de los problemas de seguridad y performance que ya detectaban. La vista de Database Connections, activada por defecto incluso en proyectos self-hosted, muestra qué sesiones mantienen conexiones abiertas, cuáles corren hace mucho tiempo o están bloqueadas, y quién sostiene el lock, con la opción de cancelar la consulta o cortar la conexión desde ahí. La nueva herramienta MCP query_logs deja que el agente consulte tus logs directamente, y el agent skill de Supabase ahora apunta a un documento vivo con las señales de salud, seguridad, performance y recursos que el agente debería vigilar.
query_logsExplorer: logs y base de datos en un mismo lugar
Explorer es la siguiente versión del editor SQL, pero amplía el alcance: consultás tus logs o tu base de datos en el mismo espacio de trabajo, y podés guardar esa investigación como un Notebook que cualquiera en tu equipo puede volver a ejecutar. Antes, cruzar logs y datos de la base para diagnosticar un incidente significaba saltar entre herramientas distintas sin un historial compartido. El rollout llega a todos los proyectos de forma escalonada hasta el 12 de octubre, y una vez que aparece en tu proyecto lo activás manualmente en Feature Previews.
Control de acceso para agentes y tokens
Varias funciones apuntan a limitar qué puede hacer un agente o un token sin supervisión. Enterprise-Managed Auth for MCP, ya en disponibilidad general para planes Team o Enterprise con SSO configurado, deja que tu identity provider (empezando por Okta) decida quién puede conectarse al servidor MCP de Supabase, y cada token queda atado a la persona que inició sesión. Los Scoped Personal Access Tokens, también en disponibilidad general y ahora el valor por defecto para tokens nuevos creados desde el dashboard, te dejan limitar un token a organizaciones, proyectos y permisos específicos en lugar de darle acceso total a la cuenta. Y las MCP Elicitations hacen que el servidor MCP pida confirmación antes de crear un proyecto o branch pago, o antes de ejecutar SQL que podría borrar datos; está activado por defecto, y ayuda a evitar cargos no deseados o pérdida de datos, aunque las notas aclaran explícitamente que no es una garantía absoluta.
Pipelines, Multigres, OrioleDB y dbarena
Supabase Pipelines suma destinos nuevos: BigQuery, ClickHouse, DuckLake y Snowflake, para transmitir datos de Postgres casi en tiempo real y que las consultas analíticas corran ahí en vez de pegarle a tu base de producción; está en alpha pública para los planes Pro, Team y Enterprise. En el frente de escalabilidad, Multigres aporta alta disponibilidad multi-nodo para Postgres, construido por el equipo detrás de Vitess: si un nodo falla, promueve una réplica en segundos y las escrituras confirmadas sobreviven, sin cambios en tu aplicación, con connection pooling incluido; es open source, y en Supabase está en alpha privada por invitación. OrioleDB es un motor de almacenamiento que reemplaza el heap por defecto con un undo log, evita el bloat de tablas y la necesidad de VACUUM, y mantiene el comportamiento habitual de Postgres; está en beta pública y se elige al crear el proyecto. Por último, dbarena publica benchmarks de bases de datos abiertos y reproducibles, con el código del benchmark, los datos, el throughput absoluto y el throughput por dólar disponibles para que vos mismo inspecciones el método y repitas el resultado.
Qué te llevas
El schema y la configuración del proyecto ahora viven en código, lo que permite que un agente los modifique con el mismo flujo de trabajo que usás vos, sin tocar el dashboard.
El acceso de agentes está separado en dos capas: lectura para diagnóstico (MCP solo lectura, advisors, query_logs) y escritura con confirmación explícita (MCP Elicitations) o tokens acotados (Scoped PAT, Enterprise-Managed Auth).
Podés exponer un servidor MCP propio para que los usuarios de tu app conecten sus agentes, con autenticación y RLS aplicándose por usuario, no un acceso genérico.
El desarrollo local ya no depende de Docker, y Compute permite correr servicios de larga duración junto a la base de datos, aunque ambas funciones siguen en etapas tempranas (alpha).
Para escalar, Multigres ataca alta disponibilidad multi-nodo y OrioleDB ataca el bloat de tablas con un storage engine alternativo; ambas siguen en fases de prueba (alpha privada y beta pública respectivamente).
¿Quieres una clase de esto?
Si varias personas lo piden, entra al programa. No hace falta dejar mail ni nombre.