Supabase lanza Explorer y Notebooks para logs y SQL

Explorer: un solo editor para tu base de datos y tus logs

El 70% de las bases de datos nuevas que se crean en Supabase ya las levantan agentes o herramientas de IA, según reportó la compañía en su comunicado de octubre recogido por Yahoo Finance. Ese número explica por qué el nuevo editor de consultas del dashboard, Explorer, tiene una obsesión poco habitual: que el trabajo de diagnóstico quede guardado y sea reproducible, no solo ejecutable una vez.

Hasta ahora, diagnosticar un problema en producción obligaba a leer logs, gráficos de uso y reportes de base de datos por separado, y a correlacionarlos mentalmente. Los logs hablan un dialecto de consulta distinto y el vínculo entre ambos vive en la cabeza de quien investiga. Explorer pone las dos fuentes en un mismo editor: eliges el origen, escribes SQL contra él y cada resultado se renderiza como tabla o como gráfico.

Las consultas de logs llevan su propio rango de tiempo, así que la consulta que encontró el error y la que encontró la petición lenta quedan lado a lado, sin exportar nada entre herramientas.

¿Y esto cómo se aplica en tu negocio?

Dueños de negocio de Latinoamérica y España usan un agente de IA para ganar más y recuperar su tiempo. El Kit «tu mano derecha con IA» te muestra cómo en un video de 11 minutos, con una ficha para armar el tuyo. CAR está cerrada por ahora; al anotarte, te avisamos cuando abra.

👥 Quiero el Kit →

Explorer está en feature preview y disponible para todos los proyectos. Se activa desde Feature Previews en el dashboard de Supabase y reemplaza al SQL Editor en la barra lateral.

Notebooks: la investigación que tu equipo puede volver a ejecutar

Un Notebook es un archivo dentro de tu carpeta supabase que combina consultas de base de datos o de logs como celdas, la lógica entre ellas y markdown que describe el razonamiento. Cualquier celda de consulta puede renderizar su resultado como gráfico.

El detalle que cambia el flujo de trabajo: un notebook guarda consultas, no resultados. Al ejecutarlo más tarde siempre devuelve datos actuales. Eso lo convierte en una herramienta de verificación, no en un reporte congelado.

El problema que resuelve es concreto y lo conoce cualquiera que haya hecho guardia. El resultado habitual de una investigación es una respuesta perdida en Slack y un snippet de consulta sin título que nadie vuelve a encontrar. Un notebook conserva el trabajo: otra persona del proyecto lo retoma donde lo dejaste, y tú puedes re-ejecutar la misma comprobación después de un deploy para confirmar que los números se movieron como esperabas.

El asistente escribe las consultas, tú las apruebas

Supabase Assistant, el panel de chat integrado en el dashboard, funciona dentro de Explorer. Si le pides que investigue algo, escribe las celdas del notebook, las ejecuta y persiste el notebook para reutilizarlo. También puedes pedirle que modifique una sola celda y la edita en su lugar.

Hay dos salvaguardas que conviene subrayar para cualquier equipo que evalúe herramientas con IA. Primero, cada creación y cada edición espera tu aprobación antes de guardarse, y lo que apruebas es SQL y markdown legible línea por línea. Segundo, y esto es lo importante: nada de esto requiere al asistente. Explorer es un espacio de trabajo SQL completo sin nada habilitado por IA, y un notebook se puede escribir enteramente a mano.

Tus notebooks viven en el repositorio, no en un panel

Un notebook vive en tu carpeta supabase, así que recibe el mismo tratamiento que el resto del proyecto: se versiona, se revisa en un pull request y lo tiene quien clone el repositorio. Puedes crearlo en el dashboard y bajarlo con la CLI, o escribirlo localmente, incluso con tu propio agente, y subirlo para que aparezca en el dashboard.

Los comandos son supabase notebooks pull y supabase notebooks push, disponibles en la versión beta de la CLI. Como los resultados no se guardan en el archivo, el mismo notebook funciona contra cualquier rama.

Por qué Supabase empuja hacia las investigaciones reproducibles

El contexto de la compañía ayuda a leer el anuncio. Supabase cerró una Serie F de US$500M con una valoración post-money de US$10.500M, liderada por GIC y con la participación de inversores existentes como Accel, Y Combinator, Craft Ventures, Felicis, Peak XV Partners y Coatue, según reportó Pulse 2.0. La empresa declaró entonces más de 250.000 clientes y más de 9 millones de desarrolladores, con un crecimiento del 600% interanual en bases de datos.

En octubre, según el comunicado recogido por Yahoo Finance, Supabase sumó US$150M adicionales liderados por GIC, con CapitalG, IronArc y SquarePeg, y anunció la adquisición de Turso. La compañía dijo que añade más de 1 millón de usuarios y 4 millones de bases de datos por mes, y que el 70% de las bases nuevas las crean agentes o herramientas de IA.

Ese último número es la clave del lanzamiento. Si los agentes crean la mayoría de las bases de datos, alguien tiene que poder auditar qué hicieron. Un notebook versionado, con el SQL a la vista y aprobación humana en cada paso, es exactamente el artefacto que hace falta para eso.

El movimiento tampoco es aislado en el sector. Datadog puso en disponibilidad general su MCP Server, que lleva logs, métricas y trazas en vivo a agentes de código como Claude Code, Cursor, Codex, GitHub Copilot y VS Code, según Help Net Security. En su segundo trimestre de 2026 la compañía reportó US$1.120M de ingresos, un 36% más interanual, y dijo que las llamadas a su MCP Server se cuadruplicaron respecto del trimestre anterior, según The Motley Fool. La observabilidad dejó de ser un panel que mira un humano: ahora es también una interfaz que consumen agentes.

¿Qué significa esto para tu startup?

1. Convierte tus incidentes en activos, no en anécdotas. El próximo incidente de producción que atiendas, resuélvelo dentro de un notebook en lugar de en la consola. Guarda la consulta que encontró el error, la que encontró la petición lenta y una celda de markdown con la hipótesis. Cuando el mismo síntoma reaparezca en tres meses, ejecutas el notebook en lugar de reconstruir el razonamiento desde cero.

2. Usa el notebook como verificación post-deploy. Como los notebooks guardan consultas y no resultados, sirven como test manual de comportamiento. Arma uno con las métricas que te importan (latencia, tasa de error, volumen de escritura) y ejecútalo después de cada release. Es la versión barata de un smoke test para equipos que todavía no tienen infraestructura de testing.

3. Revisa el SQL que genera la IA antes de aprobarlo. La aprobación paso a paso es una función de seguridad, no un trámite. Si tu equipo adopta asistentes que escriben consultas contra producción, el notebook versionado en el repo es tu registro de auditoría: queda en el pull request quién aprobó qué consulta y cuándo.

4. Ten en cuenta la etapa del producto. Explorer está en feature preview y los comandos de notebooks viven en la versión beta de la CLI. Para un equipo que depende de la observabilidad en producción, eso significa probarlo primero en un proyecto secundario antes de mover el flujo de guardia completo.

Conclusión

La propuesta de Explorer y Notebooks no es "más IA en tu editor". Es que el trabajo de investigar un problema deje de ser un momento privado y se convierta en un archivo que el equipo hereda, revisa y re-ejecuta. Para startups pequeñas, donde la persona que diagnosticó el incidente puede ya no estar en la empresa, esa diferencia vale más que cualquier autocompletado.