En un mundo donde las decisiones de negocio se alimentan de datos y el SQL sigue siendo el idioma común entre analistas, ingenieras de datos y DBAs, el equipo de dbdiagram ha presentado RunSQL, una herramienta web pensada para crear entornos de base de datos de prueba en minutos, validar consultas y colaborar sin dolores de cabeza. La propuesta es simple y potente: aprovechar el modelado con DBML, cargar datos de ejemplo en CSV, ejecutar consultas en sandboxes gestionados en la nube y compartir el resultado con el equipo mediante espacios seguros y autosuficientes.
Hasta ahora, probar una consulta compleja solía requerir levantar un servidor local, definir esquemas, poblar tablas y cuidar dependencias. Con RunSQL, esa escalera se convierte en rampa: modelo → datos → ejecutar → compartir, todo desde el navegador. De entrada, el servicio soporta PostgreSQL y el equipo avanza para incorporar otros dialectos en futuras iteraciones.
Qué resuelve RunSQL (y por qué importa)
La propuesta ataca un conjunto de fricciones que toda persona que lidia con SQL reconoce:
- Arranque rápido sin instalaciones: nada de configurar contenedores, paquetes ni extensiones. Abres el navegador y trabajas.
- Entornos autocontenidos: cada “run” encapsula esquema, datos y consultas, lo que facilita reproducir un bug o compartir un escenario exacto con otra persona.
- De la idea al experimento en minutos: modelas con DBML, subes CSV y validas hipótesis sobre un dataset reducido, evitando golpear producción y sin esperar a ventanas de pruebas.
- Colaboración real: un enlace basta para que un compañero ejecute la misma consulta, vea el mismo resultado y comente sobre el mismo contexto, sin “pero en mi máquina sí funciona”.
Detrás de esa simplicidad hay un objetivo claro: acelerar ciclos de validación. Donde antes una duda se convertía en horas de preparación, ahora se resuelve con un sandbox que replica lo esencial.
Cómo funciona: de DBML a SQL ejecutándose en la nube
RunSQL se apoya en el ecosistema de dbdiagram y su lenguaje DBML (Database Markup Language), una DSL abierta, legible y muy popular para visualizar y versionar esquemas.
- Definir esquemas con DBML
Escribes el modelo de tus tablas —campos, tipos, claves, relaciones— en DBML. La curva es suave: DBML es conciso y fácil de leer en revisiones de código o en un documento de diseño. - Cargar datos de ejemplo (CSV)
Subes datasets desde tus hojas de cálculo o herramientas BI. Con pocos clics tienes tablas pobladas con valores realistas, ideales para cubrir los “edge cases” que suelen romper una consulta. - Ejecutar consultas al instante
Lanzas tu SQL sobre sandboxes cloud de RunSQL (actualmente PostgreSQL). Sin latencias derivadas de VPNs ni firewalls corporativos; sin miedo a tocar tablas sensibles. - Compartir y colaborar
Generas un entorno seguro y autocontenido que puedes enviar al equipo. Quien lo abra contará con el mismo esquema y los mismos datos; podrá probar variaciones de la consulta, comparar planes y dejar comentarios.
Casos de uso donde brilla RunSQL
- Ingeniería de datos que prueba SQL complejo a diario
Cuando una transformación en producción cuesta tiempo y recursos, la alternativa es curar un conjunto reducido y validar la lógica en un sandbox. RunSQL acelera ese ciclo y permite mantener un histórico de casos. - Debug conjunto entre compañeras/os
El clásico “me falla en staging” encuentra antídoto compartiendo un run con el esquema y datos exactos. Dos ojos (o cuatro) revisan la misma evidencia y no una captura de pantalla. - Entrevistas técnicas con SQL
Preparas un banco de ejercicios con datasets y reglas claras, compartes el entorno y evalúas en tiempo real sin instalar nada en el equipo de la persona candidata. Transparente y reproducible. - Docencia y formación interna
Para cursos y talleres, cada grupo recibe el mismo entorno. Se evitan las primeras horas perdidas en instalaciones, versiones y drivers. El foco queda en aprender SQL, no en pelear con la máquina.
Buenas prácticas incorporadas (y errores comunes que te ahorrarás)
Aunque RunSQL no pretende ser un linter exhaustivo, la filosofía del proyecto —y del ecosistema dbdiagram— es promover hábitos sanos desde el minuto uno:
- Evitar
SELECT *cuando te importa el coste de red y el acoplamiento a cambios de esquema. - Filtrar siempre que tenga sentido: una
WHEREbien pensada divide por diez el volumen procesado y el tiempo de CPU. - Indexar columnas de
JOINyWHEREpara prevenir nested loops costosos y planes de ejecución imprevistos. - Descomponer subconsultas monstruosas: a veces una CTE o una vista materializada simplifica la vida y mejora la latencia.
- Tener datasets pequeños, pero representativos: cubre valores nulos, duplicados, claves ausentes y outliers.
Esa cultura de “probar con intención” es la que convierte a los sandboxes en herramientas de ingeniería, no en simples juguetes.
Postgres hoy, más motores mañana
El equipo confirma que en este arranque PostgreSQL es el motor soportado. No es casual: Postgres es robusto, estándar y con tooling maduro (planes de ejecución legibles, extensiones útiles, tipos avanzados). La hoja de ruta prevé ampliar a otros dialectos (MySQL, SQL Server, etc.), algo que ya gestionan en otros componentes del ecosistema.
Mientras tanto, si trabajas multi-motor, puedes modelar en DBML (neutro) y luego ensayar la lógica en Postgres, ajustando sintaxis cuando migres a otro SQL dialect.
Colaboración sin fricción: compartir el contexto, no solo el error
Quien ha depurado SQL por chat sabe lo ineficiente que es enviar snippets sueltos. RunSQL propone compartir el sistema mínimo que reproduce el fallo: esquema + datos + consulta. Es como adjuntar un “repro” de calidad en un issue de ingeniería. Eso:
- Acelera la revisión: quien ayuda no debe imaginar el esquema ni fabricar datos.
- Eleva la calidad del feedback: se discute sobre hechos, no conjeturas.
- Crea una base de conocimiento: los runs se convierten en patrones de solución para consultas similares en el futuro.
¿Y si algo no compila? El clásico “relation does not exist”
En los foros de la comunidad ya asomó uno de los errores más comunes en Postgres:
Error: relation «public.users» does not exist
En la mayoría de casos, la explicación es prosaica: la tabla no existe (o no en ese esquema), el nombre difiere, o no se ha cargado el dataset. La recomendación es verificar:
- Que el DBML creó la tabla (nombres y esquema).
- Que el CSV se cargó en la tabla esperada.
- Que los identificadores coinciden (mayúsculas/minúsculas, comillas, esquema).
Si aun así persiste, el equipo sugiere compartir la URL del run con soporte para revisar el caso y orientar una solución rápida. La idea es preservar seguridad y acotar el problema al entorno que tú mismo has compartido.
Por qué DBML marca la diferencia
DBML se ha consolidado como lenguaje de facto para describir bases de datos de un modo legible por humanos y máquinas. Tres ventajas clave:
- Legibilidad: cualquier persona del equipo entiende qué tablas existen, qué claves tienen y cómo se relacionan.
- Versionado: es texto plano; se revisa en Git, se comenta en PRs, se prueba en CI.
- Paridad con herramientas: se integra con dbdiagram para visualizar y con RunSQL para ejecutar.
Ese puente entre diseño y práctica —del diagrama a la consulta que corre— reduce malentendidos y acelera entregas.
Un flujo de trabajo recomendado (paso a paso)
- Modela el esquema en DBML con las tablas absolutamente necesarias para tu caso.
- Diseña casos de datos en CSV: piensa en mínimos, máximos, nulos, duplicados, claves externas huérfanas.
- Carga en RunSQL y genera el sandbox.
- Escribe la consulta pensando en coste y legibilidad (alias claros, CTE si ayuda).
- Mira el plan de ejecución: aunque sea un entorno pequeño, te dará pistas de joins y accesos a índices.
- Comparte el run con el equipo para feedback.
- Documenta los hallazgos directamente en el hilo/issue del proyecto, con enlace al run como evidencia.
- Promueve la consulta a tu pipeline real (dbt, stored procedures, vistas), ya con confianza.
Limitaciones actuales (y cómo sortearlas)
- Solo PostgreSQL por ahora. Si tu producción es MySQL/SQL Server, usa el sandbox para validar lógica y forma, y ajusta sintaxis al migrar.
- Datos de muestra, no productivos: por diseño, RunSQL no pretende emular el volumen de producción. Si te preocupa el rendimiento a gran escala, prueba en staging con datos reales y usa el sandbox para probar estrategias (índices, desnormalización, particionado).
- Extensiones específicas: si tu SQL depende de extensiones de Postgres no estándar, comprueba la disponibilidad o modela el caso sin ellas en lo posible.
Seguridad y privacidad: sentido común, máxima utilidad
Los runs están pensados para datos de prueba. La recomendación editorial es clara: no subas datos sensibles. Si necesitas reproducir un patrón real, anonimiza y conserva distribuciones (longitudes de texto, cardinalidades, nulos). Conseguirás el mismo valor técnico sin riesgos innecesarios.
Conclusión: menos fricción, más ingeniería
RunSQL se coloca en un hueco muy concreto del flujo de trabajo SQL: validar rápido, reproducir con precisión, colaborar mejor. Encaja con equipos que versionan el esquema en DBML, practican TDD de datos y valoran la reproducibilidad por encima del “me funciona en mi portátil”.
En un ecosistema donde montar infra roba tiempo a resolver problemas, tener un laboratorio SQL de “abrir y usar” marca la diferencia. El resultado tangible es menos horas perdidas preparando entornos y más tiempo invertido en escribir consultas correctas, legibles y eficientes.
Preguntas frecuentes
¿Qué es RunSQL y para qué sirve?
RunSQL es una herramienta web para crear entornos de base de datos de prueba, cargar datos en CSV, ejecutar consultas SQL en la nube y compartir runs autocontenidos con tu equipo. Reduce drásticamente el tiempo de preparación para validar y depurar SQL.
¿Cómo se definen las tablas y relaciones?
Mediante DBML, un lenguaje sencillo y abierto para describir esquemas (tablas, tipos, claves y relaciones). DBML es legible, versionable y se integra con dbdiagram para visualizar.
¿Qué motores de base de datos soporta?
Actualmente PostgreSQL. El equipo trabaja para sumar otros dialectos. Si usas MySQL o SQL Server, puedes validar la lógica en Postgres y ajustar sintaxis al migrar.
¿Puedo usar RunSQL para entrevistas o formación en SQL?
Sí. Es ideal para entrevistas técnicas (retos reproducibles, en tiempo real) y docencia (todos los alumnos trabajan sobre el mismo entorno). El ecosistema también ofrece un SQL Validator gratuito que anima a seguir buenas prácticas.
¿Cómo soluciono el error “relation «public.users» does not exist”?
Verifica que la tabla exista (nombre y esquema), que el CSV se haya cargado y que el identificador coincida (comillas, mayúsculas/minúsculas). Si persiste, comparte la URL del run con soporte para una revisión guiada.
¿Es seguro compartir runs con mi equipo?
Los runs son entornos de prueba. Evita subir datos sensibles; anonimiza cuando sea necesario. Compartir el run aporta contexto completo para depurar en conjunto sin tocar sistemas productivos.
