Supabase: por qué los agentes de IA eligen su backend

Por qué los agentes eligen Supabase y no otra base de datos

Casi todos los modelos frontera que un rastreador de respuestas de IA probó como backend de aplicaciones eligieron Supabase como primera opción. Ese es el hallazgo que Paul Copplestone y Ant Wilson intentan explicar en su primer podcast juntos, seis años después de pasar por YC S20 y de llevar una empresa open source y totalmente remota de cero a una valoración de US$10.000 millones.

Para un founder, la pregunta no es académica. Si los agentes de código están creando la mayoría de las bases de datos nuevas del mercado, entender qué backend prefieren —y por qué— define qué infraestructura conviene elegir hoy para no reescribir mañana.

La respuesta corta: no es solo familiaridad del modelo con el nombre. Es que Supabase lleva años eliminando pasos manuales que un agente repite cientos de veces.

Leíste lo que hace la IA. ¿Y en tu negocio?

Un agente de IA puede quedarse con parte de tu día: ordenar lo pendiente y pedirte el OK antes de actuar. El Kit «tu mano derecha con IA» trae un video de 11 minutos y una ficha para dejar al tuyo trabajando. CAR está cerrada por ahora; al anotarte, te avisamos cuando abra.

👥 Quiero el Kit →

Qué agrupó Supabase en Select: Build, Operate y Scale

En su evento Select, la compañía ordenó sus anuncios en tres bloques: construir, operar y escalar. Los tres apuntan al mismo problema: un agente puede generar código en segundos, pero convertir ese código en una aplicación que funciona sigue requiriendo una cadena de configuraciones.

Los anuncios más relevantes del bloque Build son tres:

Un runtime en alpha para correr Supabase en local sin Docker. Menos dependencias en el camino hacia una base de datos funcional.
Esquemas declarativos versionados en Git. En lugar de una historia de migraciones encadenadas, el agente lee un archivo con el estado deseado.
Supabase Compute, en alpha privada, para ejecutar cargas de trabajo junto a la base de datos.

El detalle importa: para un desarrollador humano, montar el entorno local es una molestia semanal. Para un agente que crea y prueba entornos de forma iterativa, es una molestia constante. La fricción que un humano tolera, un agente la multiplica.

¿Qué cambia un esquema declarativo en Git para un agente?

El flujo SQL clásico acumula historia: creas el esquema, luego migras, migras y migras. El resultado funciona, pero reconstruir el estado actual exige leer toda la secuencia.

Un esquema declarativo es distinto. Describe el estado que quieres, en archivos que el agente puede inspeccionar, editar y bifurcar junto al resto del repositorio. Es, en palabras del propio análisis, un momento Terraform para la base de datos.

La ventaja no es exclusiva de los agentes. Un equipo humano entiende el backend sin tener que arqueologizar su historial de cambios. Pero el agente gana algo más: puede trabajar contra el repositorio completo sin pedir permiso a una consola externa.

Si estás construyendo una herramienta para desarrolladores, ahí hay una lección de producto. Las mejoras que un agente necesita suelen ser las mismas que el humano pedía desde hace años. El agente solo le da al equipo una razón adicional para terminar el trabajo.

Supabase Compute: el hueco entre arrancar y operar

Tener una base de datos resuelve el almacenamiento, no el trabajo. Una aplicación necesita un lugar donde trocear documentos, generar embeddings o correr procesos largos. Supabase Compute, en alpha privada, apunta a ejecutar contenedores cerca de la base de datos.

Eso cierra una brecha concreta: menos servicios separados que configurar, conectar y explicarle al agente. Las edge functions siguen siendo útiles, pero no cubren todas las cargas.

El otro lado es el operativo. Logs, checks, conexiones y contexto permiten que un agente entienda qué está cambiando. Un modelo que sabe emitir SQL todavía necesita saber qué contiene la base de datos, cómo la usa la aplicación y qué falló cuando algo se rompió. Los anuncios de Operate se leen mejor junto a los de Build, no por separado.

De prototipo a petabyte: OrioleDB, Multigres y Turso

Los fundadores hablan de unos cinco millones de bases de datos al mes en la conversación. El comunicado de la compañía de principios de octubre cifra el ritmo en más de 4 millones de bases de datos y 1 millón de usuarios nuevos al mes, con 70% de las bases nuevas creadas por agentes o herramientas de IA, según PR Newswire.

Ese volumen convive con otro problema: los clientes existentes crecen hacia cargas mucho más grandes. Servir millones de bases pequeñas y sostener la base de datos gigante de un cliente son problemas de ingeniería distintos. De ahí la amplitud del bloque Scale: OrioleDB, Multigres y la adquisición de Turso.

TechCrunch reportó en junio que Supabase lanzó Multigres como un "sistema operativo" para Postgres, pensado para centralizar réplicas de lectura, failovers, límites de conexión y backups. Y en octubre la compañía anunció la compra de Turso, cuya arquitectura permite aprovisionar bases de datos aisladas por agente a bajo costo, con clientes como Superhuman, Sauna.ai, CTO.new y Mastra. Glauber Costa, fundador de Turso, se incorpora como Head of Agentic Services junto a su cofundador Pekka Enberg.

El contexto financiero ayuda a dimensionar la apuesta: US$150 millones nuevos liderados por GIC, con CapitalG, IronArc y SquarePeg, apenas cuatro meses después de una Serie F de US$500 millones a una valoración pre-money de US$10.000 millones, según PR Newswire y TechCrunch.

¿Qué significa esto para tu startup?

Primero: elige backend pensando en el agente, no solo en el humano. Si tu equipo usa Claude Code, Codex o cualquier agente de código a diario, la pregunta relevante es si ese agente puede leer el estado de tu infraestructura sin fricción. Un esquema declarativo en el repositorio, con el estado deseado en archivos versionados, reduce iteraciones fallidas y hace que el agente entienda el contexto sin adivinar.

Segundo: separa desde el día uno el almacenamiento del cómputo. Muchos proyectos jóvenes mezclan ambas cosas y terminan con procesos largos colgados de una base de datos que debería estar dedicada a servir consultas. Diseña dónde corren tus trabajos pesados antes de que el primer cliente real aparezca.

Tercero: mide la activación como una secuencia, no como un formulario. Copplestone y Wilson observan que, a medida que creció el uso impulsado por IA, mejoraron la activación y la conversión. Su explicación: un agente puede llevar al usuario desde el registro hasta una configuración funcional en un solo flujo, sin que la persona tenga que resolver cada paso antes de ver la aplicación funcionando. Si tu onboarding depende de que el usuario entienda la configuración, tienes margen para automatizarlo.

Conclusión

La tesis de Supabase no es que los agentes sean un canal de marketing, sino que cambian el estándar de ergonomía que un backend debe cumplir. Un humano tolera un docker-compose roto una vez por semana; un agente lo encuentra cien veces al día.

Para los founders hispanohablantes que construyen sobre estos modelos, la lectura práctica es doble. Por un lado, la infraestructura que elijas debería ser legible por máquina desde el primer commit. Por otro, el patrón de producto que funciona —quitar pasos, no añadir funciones— aplica igual a tu propio SaaS, sea cual sea el vertical.