# explorerhq/sql-explorer: Django SQL reporting with an AI query assistant > SQL Explorer is a Django app for writing, saving and sharing SQL queries, with CSV and JSON uploads, scheduled snapshots and an optional LLM assistant. It fits teams already running Django, and it is not a standalone desktop SQL client. **explorerhq/sql-explorer** — SQL reporting that Just Works. Fast, simple, and confusion-free. Write and share queries in a delightful SQL editor, with AI assistance. - Repository: https://github.com/explorerhq/sql-explorer - Website: https://www.sqlexplorer.io - Stars: 2,874 · Forks: 372 - Language: Python - License: NOASSERTION - Published: 2026-09-28 · Updated: 2026-09-28 · Language: en - Canonical page: https://hysenlabs.com/projects/explorerhq-sql-explorer ## What explorerhq/sql-explorer is for SQL Explorer is a Django application that you add to an existing Django site, or run on its own as a small business intelligence tool. The problem it addresses is the gap between a database and the people who need numbers out of it. Analysts write SQL once, save it, and non-technical colleagues run the same query through an auto-generated form instead of asking for a fresh export every week. The README describes the goal as making "the flow of data between people fast, simple, and confusion-free". That framing tells you who it is for: teams that already have a Django deployment and a database, and that want query sharing, parameterized reports and light in-browser analysis without standing up a separate BI stack. It is not aimed at a single developer who wants a desktop SQL client on a laptop. ## How SQL Explorer runs queries and stores results The architecture follows Django conventions closely. Queries, connections, logs and snapshots are Django models, and the UI is a set of Django views served by your web process. The README states that it connects to any SQL database Django supports, and that admin-configured or user-provided connections are both possible. That means database credentials and connection definitions live in the Django database and are managed through the admin, not in a config file you hand to each user. Data flow is straightforward: a saved query holds SQL text, the app executes it against the chosen connection, and the result set is rendered in the browser. From there the README lists in-browser statistics, pivot tables and scatter plots, email delivery of results, and the option to expose a saved query as a JSON API. CSV, JSON and SQLite files that users upload are treated as queryable sources in the same way, which is the cheapest path to ad-hoc analysis without touching production. The AI assistant is opt-in. You add an OpenAI or other provider API key, and the assistant builds a prompt that includes relevant schema context before calling the model. That detail matters for anyone evaluating data exposure: the README says the assistant adds schema into the prompt, so what leaves your infrastructure is structure, not just the question you typed. ## Quick start with docker compose The README ships a complete test project for exactly this purpose. Run the compose file from the repository root, then open the explorer path in a browser. The compose service maps port 8000 for the Django app and port 5173 for a Vite dev server with hot reloading, and it sets DJANGO_SETTINGS_MODULE to test_project.settings. ```bash docker compose up ``` Once the containers are up, navigate to 127.0.0.1:8000/explorer/ and log in with admin/admin, which the README gives as the demo credentials. From there you can create a connection, write a query and save it. The Dockerfile shows what happens on first build: it runs python manage.py migrate and then creates the admin user if one does not exist. That is convenient for a demo and a bad idea to carry into production unchanged, since a superuser with a known password is created by the image build itself. For a real installation into an existing Django project, the package is distributed as django-sql-explorer on PyPI, and the documentation site is django-sql-explorer.readthedocs.io. The README does not spell out the INSTALLED_APPS and URL wiring in the text available here, so treat the readthedocs pages as the source for those steps. ## Parameterized queries and the schema helper Two features carry most of the day-to-day value. The first is parameterized queries: a saved query can declare parameters, and SQL Explorer generates a friendly form so someone who does not write SQL can run it with their own values. This is the mechanism that turns a one-off query into a reusable report, and it is the reason the tool belongs in a team rather than on one person's machine. The second is schema access inside the editor. The README mentions quick access to schema information including autocomplete, and the screenshots show a schema helper alongside the query editor. The editor itself is CodeMirror 6 with the SQL language package, per package.json, so the editing experience is a browser component rather than a native application. If your team lives in a desktop client with a full object browser, this will feel thinner. If they live in a browser tab, it will feel normal. ## Where SQL Explorer is the wrong tool The dependence on Django is the hard boundary. If your stack is not Django, you cannot add this as a library; you would be adopting a Django project and its deployment, authentication and admin model along with it. The quick start makes that concrete: the demo runs Django's development server via manage.py runserver, and the compose file is a development setup, not a production one. There are other limits worth naming. Access control follows Django's user and permission system, so any sharing model you want has to be expressed there. The README does not document rollback behaviour, version pinning or a migration path between releases, and the newest release listed in the repository is 5.3.0 from 2024-09-24, while the last push to master was on 2026-09-23. That gap between the tagged release and the branch means anyone installing from PyPI and anyone tracking master are running different code, and the README does not describe how those two lines relate. Finally, the project is not a database administration console. It runs queries and presents results. If you need to inspect indexes, manage users on the database server or browse object definitions the way a native client does, SQL Explorer is the wrong category of tool. ## SQL Explorer compared with Metabase and Superset The nearest alternatives are Metabase and Apache Superset. Both are standalone BI applications: you deploy them as their own service, point them at your databases, and they bring their own user model, dashboards and scheduling. SQL Explorer takes the opposite approach. It is a Django app you embed in a site you already operate, so authentication, permissions and deployment are inherited rather than rebuilt. The trade-off is scope. Metabase and Superset ship dashboarding and a broader visualization layer as first-class features, while SQL Explorer's README lists statistics, pivot tables and scatter plots as quick in-browser conveniences, with the emphasis on writing and sharing queries rather than assembling dashboards. If your reporting need is a catalog of parameterized queries that non-SQL users can run, the embedded approach removes an entire service from your infrastructure. If you need a dashboard product, you will be building that on top. ## Licence and upgrade cost The README and setup.py both state that the project is MIT licensed, and the package metadata carries the same identifier. The repository's licence field is reported as NOASSERTION, which is a scanner classification rather than a statement about the project, so the MIT text in the repository and the package metadata are the concrete sources to check. This is not legal advice; if you redistribute the project or embed it in a commercial product, confirm the terms against the LICENSE file yourself. Upgrade cost is where the release cadence matters. The listed releases are 5.3b1, 5.3b2 and 5.3.0, the last of which is dated 2024-09-24. If you install from PyPI, that is the version line you are on unless a newer release exists that is not listed here. The front end is built with Vite and Node 20.15.1 per the Dockerfile and package.json, so a source install pulls in a Node toolchain in addition to Python 3.12. The README does not document a supported upgrade procedure between major versions, so budget time for reading HISTORY.rst and the readthedocs history page before moving a production instance. ## Conclusion Adopt SQL Explorer if you already run Django and want shared, parameterized SQL reports without building a reporting layer yourself; the quick start is docker compose up and the demo login is admin/admin. Skip it if you need a native desktop client or a general-purpose database IDE, since access to queries runs through Django's auth and admin. Before committing, verify the licence situation for your own use, check that your database is one Django supports, and confirm the current release line, since the newest release in the repository is 5.3.0 from 2024-09-24 while the last push to master was on 2026-09-23. ## FAQ ### What is SQL Explorer? It is a Django application for writing, saving and sharing SQL queries, usable either inside an existing Django site or as a standalone reporting tool. It connects to any database Django supports and also accepts uploaded CSV, JSON and SQLite files. ### How do I install SQL Explorer? The README's quick start runs the bundled test project with docker compose up, then you open 127.0.0.1:8000/explorer/ and log in with admin/admin. For a real project the package is published as django-sql-explorer on PyPI, with setup instructions on the readthedocs documentation site. ### Does SQL Explorer work with databases other than the one Django uses by default? The README states it will connect to any SQL database that Django supports, and connections can be admin-configured or user-provided. It also accepts user-uploaded CSV, JSON and SQLite databases as queryable sources. ### Does SQL Explorer include an AI assistant? Yes, if you add an API key from OpenAI or another provider. The README says the assistant automatically adds relevant context and schema into the underlying LLM prompt, so schema information is part of what is sent. ### Can SQL Explorer expose a saved query as an API? The README lists this as a feature: saved queries can be exposed as a quick JSON API if desired. It describes the capability rather than the endpoint format, so check the documentation for the details. ## Sources - [explorerhq/sql-explorer on GitHub](https://github.com/explorerhq/sql-explorer) - [Issues](https://github.com/explorerhq/sql-explorer/issues) - [Project website](https://www.sqlexplorer.io) - [README](https://github.com/explorerhq/sql-explorer/blob/master/README.md) - [Releases](https://github.com/explorerhq/sql-explorer/releases) --- Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/explorerhq-sql-explorer