In today’s data-driven world where SQL remains the lingua franca for analysts, data engineers, and DBAs, the dbdiagram team has introduced RunSQL, a browser-based tool to create mock database environments, validate queries, and collaborate instantly. Think of it as a natural extension of dbdiagram: model schemas with DBML, upload sample data from CSV, run queries in cloud sandboxes, and share results in secure, self-contained environments.
Traditionally, testing a complex query meant spinning up a local database, defining schemas, populating tables, and configuring dependencies. RunSQL collapses that overhead into a simple pipeline: model → data → execute → share. At launch, it supports PostgreSQL, with additional SQL dialects planned.
What RunSQL Solves (and Why It Matters)
RunSQL is designed to remove common points of friction in SQL workflows:
- Zero setup: no Docker, no manual installs. Open a browser and start working.
- Self-contained runs: each environment includes schema, data, and queries, making issues reproducible.
- Faster iteration: test complex logic against curated datasets without touching production.
- Collaboration: share a link with teammates so they can run, tweak, and validate queries in the exact same environment.
This makes it particularly useful for debugging, teaching, and prototyping, where reproducibility and speed are key.
How It Works: From DBML to SQL Execution
RunSQL leverages DBML (Database Markup Language), the open-source DSL popular for schema modeling.
- Define schemas with DBML: describe tables, fields, keys, and relationships.
- Upload sample data: load CSVs from spreadsheets or BI tools to populate tables.
- Execute queries instantly: run SQL on cloud-hosted Postgres sandboxes.
- Share securely: teammates access the exact same schema, data, and query context.
Who Benefits From RunSQL?
- Data engineers testing complex SQL daily: validate logic on small, representative datasets before moving to production.
- Teams debugging together: share reproducible runs to resolve bugs collaboratively instead of exchanging snippets.
- Technical interviewers: create SQL challenges and evaluate candidates in real time with shared sandboxes.
- Educators and trainers: provide students with identical environments, avoiding setup headaches.
Built-In Best Practices
While not a full linter, RunSQL promotes healthy habits:
- Warns against
SELECT *usage. - Encourages filtering with
WHEREto avoid returning unnecessary rows. - Checks if
JOIN/WHEREcolumns are indexed (schema mode). - Recommends CTEs or materialized views for overly complex subqueries or heavy window functions.
These nudges help prevent performance pitfalls early, making SQL development more reliable.
Known Limitations
- PostgreSQL only (for now): support for MySQL and SQL Server is on the roadmap.
- Sample data focus: sandboxes are meant for lightweight testing, not production-scale performance.
- Extension support: some PostgreSQL extensions may not be available in the hosted environment.
Still, for logic validation and collaboration, RunSQL fills an important niche.
Real-World Example: The “Relation Does Not Exist” Error
One of the first reported issues in the community was:
Error: relation “public.users” does not exist
In most cases, this happens because the table wasn’t defined in DBML or the CSV wasn’t loaded. Common fixes include:
- Ensuring the table is declared in the schema.
- Verifying the dataset was uploaded.
- Checking identifiers (case sensitivity, quoting, schema).
If the problem persists, the RunSQL team recommends sharing the run URL with support so they can debug without compromising security.
Why DBML Matters
DBML is central to RunSQL’s design:
- Readable: anyone on the team can understand the schema quickly.
- Versionable: it’s plain text, ideal for Git workflows.
- Bridges design and execution: visualize with dbdiagram, test with RunSQL.
This duality reduces miscommunication between design and implementation.
Recommended Workflow
- Model schema in DBML.
- Upload curated test datasets in CSV (include nulls, duplicates, outliers).
- Validate queries in RunSQL.
- Share the run with teammates for feedback.
- Promote validated logic to your pipeline (dbt, stored procs, production views).
Security and Privacy
Runs are intended for test data only. Best practice is to anonymize sensitive datasets while preserving statistical distributions, ensuring tests are realistic without exposing private information.
Conclusion
RunSQL positions itself as a lightweight SQL lab in the cloud: no setup, reproducible environments, and effortless collaboration. It streamlines debugging, accelerates prototyping, and simplifies education, making SQL development more efficient across contexts.
In a landscape where setting up infrastructure often consumes more time than solving the actual problem, RunSQL lets teams focus on writing correct, efficient SQL instead of battling with their environments.
FAQs
What is RunSQL?
RunSQL is a cloud-based tool to create mock database environments, load sample datasets, run SQL queries, and share results with others in reproducible sandboxes.
Which databases does RunSQL support?
Currently PostgreSQL. Support for MySQL and SQL Server is under development.
Can RunSQL be used for teaching SQL?
Yes. Instructors can prepare identical environments for students, making it ideal for workshops, training, and classroom use.
How is RunSQL different from running SQL locally?
It requires no setup, works entirely in the browser, and provides self-contained runs that can be shared easily with teammates.
Is it safe to share runs?
Yes, as long as you only use test data. Sharing runs allows others to reproduce the exact schema and dataset for debugging or learning purposes.
