Redash

Last reviewed Aug 26, 2026 · 871 words

Redash is worth running only if the people who will use it already write SQL. Its entire model is a shared SQL editor whose saved queries become the source for every chart, dashboard and alert, and that model is either exactly what your team wants or a wall it will never climb. Someone who doesn't write SQL gets a parameter dropdown on a colleague's query and nothing else. The admission price is a 2 GB box and a Docker stack of 6 containers that all have to be healthy at the same time.

The stack is six containers, not one

The application ships as one Python image, but it runs as several processes with different jobs: a server for the web UI and API, a scheduler that enqueues refreshes, and one or more worker processes that execute queries. Around those sit PostgreSQL for metadata, Redis for the job queue, and nginx in front. The official setup script writes exactly that compose file into /opt/redash.

The practical consequence is that "Redash is down" has 6 candidate causes, and the most common one I've hit is a worker that stopped consuming the queue while the UI on port 5000 looked perfectly healthy. Queries sit at "executing" forever and nobody sees an error. Health-check the worker container, not just the web port, and give the workers room: a 500,000-row result is held in memory before it is written to Postgres, so the 2 GB minimum is a real floor, not a starting suggestion.

Cached results are why it feels fast

Every query run writes its result into Redash's own Postgres as a JSON blob. Dashboards read that cached copy; they do not touch your warehouse on each page load. That is the reason Redash stays snappy on a slow BigQuery or a creaking MySQL replica, and it is also why the metadata database grows without obvious cause. Two knobs matter. Per query, set a refresh schedule that matches how often the data actually changes, not "every minute" because the dropdown offered it. Globally, leave QUERY_RESULTS_CLEANUP_ENABLED on and tune QUERY_RESULTS_CLEANUP_MAX_AGE (days) so old unscheduled results get pruned.

A related trick people miss: the built-in "Query Results" data source lets you write SQLite-syntax SQL against other saved queries by number, so you can join a Postgres result with a Google Sheets result without a warehouse. It is slow and it is wonderful for one-off reporting.

Where it beats Metabase and Superset

Metabase is a single JAR with a point-and-click question builder that business users can drive unaided; it is the safer default for a mixed team. Superset has far more chart types and a semantic layer, and costs you a steeper setup and a heavier box. Redash sits between them with a different emphasis: the query is the first-class object. Parameters like {{ start_date }} turn one query into a self-serve report, snippets share boilerplate, and alerts fire to email or Slack when a query's first row crosses a threshold. Pick Redash when you have 2 or more SQL writers, more than a couple of data sources, and a need for alerts. Pick Metabase when the audience is the sales team.

The .env file is part of the database

Data source credentials are stored in Postgres encrypted with REDASH_SECRET_KEY from the environment file. A nightly pg_dump alone is therefore not a backup: restore it on a fresh host with a new secret and every connection is unreadable. Back up /opt/redash/env alongside the dump, and treat REDASH_COOKIE_SECRET the same way. Restore once into a scratch VM to prove it.

Releases come slowly, so pin your tag

The project's cadence is slow and has had long quiet stretches, which is fine for a tool this mature but means latest can jump a long way in one pull. Pin a specific image tag, read the changelog before moving, and run the migration step (docker compose run --rm server manage db upgrade) deliberately rather than letting a restart surprise you.

Setup that holds up

Run the official script on a clean Ubuntu VM, then docker compose run --rm server create_db to initialise Postgres. Put Caddy in front for TLS, create your admin account, and immediately turn off open registration in the org settings. Wire Google OAuth or SAML if you have it, because Redash's built-in password auth has no 2FA. Give the VM 2 vCPUs and 4 GB, which leaves headroom for one heavy worker. One clarification while you are choosing: Redash is BI over your databases, not website analytics; for pageviews look at the analytics category instead.

What I'd do

Only deploy it for a team with SQL writers. 4 GB VM, official compose, image tag pinned, worker health-checked, Caddy in front, signups closed after day one. Nightly pg_dump plus the env file to off-box storage, restore-tested once. Run that way, Redash is the cheapest way I know to turn a pile of databases into a shared, alertable set of answers, and I'd still choose Metabase for a team that wants to click instead of type.