Redash: a self-hosted SQL query and dashboard layer for teams that already have data sources

What Redash solves, and who ends up using it

The problem Redash addresses is narrow and common: a company has data sitting in Postgres, MySQL, BigQuery, Snowflake or a dozen other places, and the only way to get a number out of it is to ask an engineer who has a database client installed. Redash puts a query editor in the browser, keeps the query, its result and its visualisation together, and gives each of them a URL that can be pasted into a chat thread.

The README frames the audience directly: it is designed so that anyone, regardless of technical sophistication, can work with data, while SQL users do the querying. That split matters. Redash is not a tool that removes SQL. It assumes somebody writes the query, then hands the output to people who never will. If nobody on your team writes SQL, the product has nothing to offer you. If several people do, the sharing model is the actual feature.

The secondary audience is the engineer who is tired of running the same query by hand. Scheduled refreshes and alerts mean a query can be written once and then report on its own. The REST API means the same objects can be created by a script, which is how most teams eventually populate a fresh instance.

How a query becomes a dashboard: the moving parts

The repository layout shows the shape of the system without needing to run it. There is a Python backend under redash/, a React frontend under client/, a separate visualisation library in viz-lib/, and migrations/ for schema changes. The top level contains a Dockerfile, a compose.yaml and a Makefile, which tells you the intended deployment unit is a container image plus a database.

The compose.yaml file is explicitly labelled as the development setup, and it lists the process split: a server, a scheduler, a worker, plus Redis and Postgres. That is the architecture in one screen. The server handles HTTP and the UI. The scheduler decides when a saved query is due to run. The worker executes the query against the remote data source and writes the result back. Redis sits between them as the queue and cache; Postgres holds users, queries, dashboards and results.

This split has a practical consequence. Query execution is asynchronous, so a slow warehouse does not tie up the web process, but it also means a failing worker is invisible from the dashboard until a chart stops updating. The compose file also disables fsync and synchronous_commit on Postgres, with a comment saying this trades durability for test speed. Anyone copying that file into production is copying a setting that was written for tests.

Installing Redash with Docker and running a first query

The README does not carry install instructions itself. It points to a setup page on redash.io for setting up an instance, and mentions ready-made AWS and GCE images. The repository also ships a compose.yaml, which the file header describes as the development configuration, with a note that production examples live in the getredash/setup repository.

To start from the repository, the compose file expects a .env file next to it, referenced by env_file. The environment block in compose.yaml sets the host, the Redis URL and the database URL, so a local run needs those values present before the containers come up.

REDASH_HOST: http://localhost:5001
REDASH_REDIS_URL: "redis://redis:6379/0"
REDASH_DATABASE_URL: "postgresql://postgres@postgres/postgres"

With that in place, the services are started with Docker Compose. The compose file maps the server to port 5001 on the host and forwards 5000 inside the container, so the UI is reached at localhost:5001 rather than the default port.

docker compose up

The compose file defines five long-running services: server, scheduler, worker, redis and postgres. On a first run, expect the server to wait on Postgres and Redis before it answers, and expect the scheduler and worker to stay quiet until a query exists. The README points to redash.io/help for documentation on what to do next.

Once the instance is up, the workflow is the one the README describes: connect a data source, write a query in the editor with the schema browser and autocomplete, then attach a visualisation and place it on a dashboard. Everything created this way is also reachable through the REST API, which the README lists as a first-class feature rather than an add-on.

Where Redash stops being the right tool

Redash is a query and presentation layer. It is not a transformation engine, and the repository gives no sign of one. There is no dbt-style model graph, no semantic layer where a metric is defined once and reused, and no data quality testing. If two analysts write the same revenue calculation slightly differently, Redash will happily show two different numbers on two dashboards, and the tool has no mechanism to notice.

The second limit is operational. Running Redash means running Postgres, Redis, a web process, a scheduler and at least one worker, and keeping them on the same schema version. The repository carries a migrations/ directory and the Python project pins its dependencies to exact versions, including Flask 2.3.2 and SQLAlchemy 1.3.24. Pinned dependencies make a known-good install reproducible, and they also mean an upgrade is a deliberate exercise rather than a background event.

The third limit is the frontend build. The Dockerfile takes a build argument called skip_frontend_build, and the compose file sets it to "true" with a comment saying to set it to an empty string to build. When skipped, the build touches placeholder HTML files. That is fine for backend work and useless for anyone who wants to change the UI, who then needs Node, pnpm and the webpack build to succeed.

Finally, Redash assumes the data source is reachable from the worker. A warehouse behind a private network with no route from the container is not a configuration problem Redash can solve.

Redash against Metabase and Superset

The closest comparison is Metabase, and the difference is in who writes the query. Metabase is built around a question builder that generates SQL for people who do not write it, with a native SQL editor as the escape hatch. Redash inverts that: the README's own framing is that SQL users explore and query, and their work enables everyone else. If your organisation is mostly non-technical and wants to click together a chart, Redash will feel like a tool for somebody else.

Apache Superset sits on the other side. It carries a heavier stack and a broader set of chart types and dashboard controls, and it expects more from whoever operates it. Redash's pitch is closer to immediate productivity: the README lists browser-based access, a query editor with schema browsing, drag-and-drop visualisation, sharing, scheduled refreshes and alerts as the core feature set, and the compose file shows a deployment that a single engineer can bring up.

The honest summary is that Redash is the smallest of the three in scope. That is the reason to choose it, and also the reason to leave it. A team that outgrows ad hoc queries into governed metrics will eventually want something Redash does not claim to be.

Maintenance, releases and what the licence means in practice

The repository is not archived, and the last push was on 2026-09-03. Releases are not weekly: the recent list shows v26.3.0 on 2026-03-02, v25.8.0 on 2025-08-01 and v25.1.0 on 2025-01-08. That cadence is worth planning around. Between releases, the master branch carries a development version, visible in pyproject.toml as 26.09.0-dev and in package.json as 26.09.0-dev, so a build from master is not a release build.

The upgrade cost comes from the pinned dependency set and the migrations directory. Because Flask and SQLAlchemy are both pinned to versions several years behind their current lines, a jump across several Redash releases is a jump across several dependency generations, and the migrations have to run in order. The README does not document rollback, so a team should verify its own before upgrading a production instance.

The licence is BSD-2-Clause, which is permissive and short. Two obligations matter for planning: the copyright notice and the licence text must be retained in redistributions of source or binary form. That is a light requirement, and it is worth confirming with whoever handles your legal review how it applies to a modified frontend bundle that you serve to users. Nothing here is legal advice.

Editorial conclusion

Adopt Redash if you have SQL-literate people, a Postgres instance and a Redis instance to spare, and you want query results shared by URL rather than exported to slides. Do not adopt it if you need a hosted product with no operations work, or if your reporting is really a spreadsheet and a scheduled email. Before rolling it out, verify the upgrade path between the release you install and the next one, confirm which of the 35-plus data sources your warehouse needs is actually listed, and read the BSD-2-Clause licence text against how you plan to redistribute the frontend.

Frequently asked questions

Official sources

1. getredash/redash on GitHub
2. License: BSD-2-Clause
3. Project website
4. README
5. Releases