Supabase Select 2026: backend desde código y MCP para tu app

Lo que Supabase acaba de cambiar en su Select 2026

En su evento anual Supabase Select, la plataforma open source de backend sobre Postgres presentó un paquete de novedades orientado a un mismo público: los coding agents que ya escriben la mayor parte del código de aplicación. La promesa es concreta: que esos mismos agentes puedan ahora crear tablas, ajustar políticas de seguridad, desplegar servicios y hasta dar acceso a la app desde Claude, ChatGPT o Cursor, sin que el founder tenga que volver al dashboard.

Supabase fue fundada en 2020 por Paul Copplestone y Ant Wilson como un proyecto Y Combinator (W20) que ofrecía una alternativa open source a Firebase sobre Postgres. Hoy afirma llegar a 4 millones de desarrolladores y más de 100.000 clientes, entre ellos PwC, McDonald’s y GitHub Next, y según TechCrunch más del 50% del último batch de Y Combinator usa Supabase como backend por defecto. El contexto importa: en junio de 2026 cerró una Serie F de US$500M a una valoración de US$11.000M liderada por GIC, con Salesforce Ventures y Stripe como participantes, según el registro de funding citado por Multiples.vc.

Dicho de otro modo: cuando una plataforma con esa tracción reorienta su roadmap hacia los agentes, el resto del ecosistema toma nota.

👥 ¿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

Tres anuncios, un solo hilo: que el agente haga el trabajo del backend

Schemas declarativos 2.0 y pg-delta: el SQL como única fuente de verdad

El cambio más profundo es de filosofía. Hasta hoy, modificar un esquema en Supabase era un viaje de ida y vuelta: creabas la tabla en el dashboard, ajustabas una RLS policy a mano y luego intentabas reconstruir esa migración desde la CLI para que el repo quedara sincronizado. Con la nueva Declarative Schemas 2.0, el agente escribe archivos SQL en supabase/schemas/*.sql y un motor nuevo del CLI llamado pg-delta se encarga de generar la migración diff automáticamente.

En la práctica esto invierte la relación. El dashboard deja de ser la fuente de verdad y pasa a ser una vista: cualquier cambio se trae al repo con supabase config pull (config, schema y Edge Functions en un solo comando). Para los proyectos nuevos que arranquen con supabase init, pg-delta viene activado por defecto. Los existentes lo encienden añadiendo la flag [experimental.pgdelta] enabled = true en config.toml.

Desarrollo local sin Docker: el agente ya puede probar antes de pushear

Hasta ahora, levantar un stack local de Supabase exigía Docker, lo que dejaba fuera entornos donde los agentes se mueven: el sandbox de Claude Code, Codex, Perplexity Computer y la mayoría de runners de CI. La nueva opción experimental corre Supabase como procesos nativos, sin daemon de Docker. En una máquina con Docker, el comportamiento no cambia. En una sin él, el agente puede iterar.

El segundo ajuste relevante es que ahora se pueden correr varias instancias locales de Supabase en paralelo, una por directorio, lo que permite tener varios checkouts o git worktrees del mismo repo probando cambios al mismo tiempo. Sigue en alpha y se activa off by default, pero resuelve un dolor real para equipos que hacen code review con agentes o que mantienen varias feature branches activas.

Supabase Compute: servicios de larga vida junto a la base de datos

Edge Functions están bien para una API corta o un webhook, pero muchas apps necesitan procesos que se queden arriba: agentes, jobs de embeddings sobre miles de archivos, servicios de scraping, sandboxes para ejecutar código no confiable. Supabase Compute es la respuesta: un servicio long-lived que vive en el mismo proyecto que la base de datos, sin límite de duración, con CPU y memoria configurables y un entorno Linux completo.

El despliegue se hace desde el CLI o vía Management API, y la definición del servicio vive en config.toml (el mismo archivo de siempre). Incluye agent skills para Compute, instrucciones que el coding agent entiende para escribir, desplegar, monitorear y debuggear el servicio. Cada servicio expone una URL pública HTTP al estilo Edge Function, escala por número de instancias, y puede desplegarse también en modo private (sin endpoint) para usarlo como worker de una cola o como sandbox. Por seguridad, las restricciones de red pueden limitar el acceso a la base de datos solo a esas instancias de Compute.

MCP para tu app: el agente del usuario, pero autenticado

El anuncio más estratégico para founders B2B es el MCP server por aplicación. MCP (Model Context Protocol) es el estándar abierto que permite a los agentes hablar con sistemas externos en nombre del usuario. Anthropic lo creó en 2024 y lo donó a la Linux Foundation; según eWeek, para diciembre de 2025 ya estaba integrado en ChatGPT, Gemini, Microsoft Copilot, Cursor y Visual Studio Code.

Lo que Supabase ofrece es un MCP server generado por un comando de shadcn: npx shadcn@latest add @supabase/mcp-server. Lo que se despliega es una Edge Function autenticada que vive en tu proyecto. Importa lo que esto significa en la práctica:

El agente del usuario entra ya logueado. No hay que reinventar auth: se reutiliza Supabase Auth.
Las RLS siguen decidiendo qué ve cada usuario. El agente no obtiene poderes de admin; hereda los permisos del usuario firmado.
Tú posees el código. El repo incluye instrucciones que tu propio coding agent puede leer para agregar tools a medida según el producto, usando el cliente de Supabase.

El stack se apoya en @supabase/server y en un nuevo Supabase Middleware pensado para cualquier código de servidor que necesite saber quién está logueado. Como complemento, Supabase también publicó un headless app template: un backend cuyo cliente principal es un agente, listo para desplegar.

En el frente de la estandarización, MCP sigue moviéndose rápido. Forkast reportó que en OpenAI DevDay 2026 se anunciaron los MCP Events, que completan el protocolo con notificaciones push nativas, y que el MCP 2.0 (spec 2026-07-28) cambió la arquitectura a un core sin estado, según eWeek. Para un founder, la consecuencia es que invertir en un MCP server propio hoy es apostar por un estándar que los grandes agentes ya están adoptando.

Qué significa esto para tu startup

Si estás construyendo con vibe coding (Lovable, Bolt, Cursor, Claude Code o Replit), tres movimientos concretos para esta semana:

Activa pg-delta en tus proyectos existentes. El coste de migrar es bajo (un flag en config.toml) y el beneficio es alto: tu agente deja de pelearse con migraciones y empieza a operar sobre el schema como código. Documentación oficial de Supabase.
Habilita el stack experimental local si trabajas con agentes en sandbox. Elimina la dependencia de Docker y desbloquea flujos donde el agente itera solo. Recuerda que está en alpha: pruébalo en una rama, no en producción.
Si tu producto tiene usuarios que ya usan agentes (Claude, Cursor, ChatGPT), expón un MCP server. Es la diferencia entre que tu cliente tenga que copiar y pegar entre su agente y tu UI, o que el agente trabaje directamente sobre tu producto respetando sus permisos. Una sola Edge Function con shadcn te pone en marcha.

El contexto que importa

Supabase no está solo en este terreno, pero su posición es particular. Vercel, citado como comparable privado por Multiples.vc, está valorado en US$9.300M con US$200M de revenue (un múltiplo de 46,5x); Supabase, con US$70M de revenue reportados en su Serie E, cotizaba a 72,9x revenue. La diferencia no es solo de precio: Vercel corre la capa de presentación y edge; Supabase corre la capa donde vive el estado de tu app, que es exactamente la pieza que un coding agent necesita para dejar de generar «código bonito pero que no persiste nada».

Por eso el roadmap de Supabase Select 2026 no se lee como un batch de features aisladas, sino como una tesis: si el agente va a construir tu producto, tiene que poder construir todo el producto, incluido el backend y la propia interfaz para los agentes de tus usuarios. Si esa tesis se cumple, la categoría entera de «backend as a service» se redefine alrededor de quién le da al coding agent el mejor terreno de juego.