Redash is an open-source tool for querying data sources and assembling the results into dashboards. Its center of gravity is the SQL editor: you write a query against a connected database, save it, and visualize the result as a chart or table. Around that it adds scheduled refreshes, query parameters, alerts, and a REST API. It connects to more than 50 sources - Postgres, MySQL, BigQuery, Redshift, Snowflake, ClickHouse, Elasticsearch, and others - so a single Redash instance often becomes the shared query layer for a team that lives in SQL.
Queries, parameters, and the data-source model
Every Redash query belongs to one data source and returns a flat result set that Redash caches. Parameters turn a static query into a reusable one: you reference {{ }} placeholders and Redash renders dropdowns, date pickers, or text inputs on the query page and on any dashboard that embeds it.
SELECT date_trunc('day', created_at) AS day,
count(*) AS signups
FROM users
WHERE created_at >= '{{ start_date }}'
AND created_at < '{{ end_date }}'
AND plan = '{{ plan }}'
GROUP BY 1
ORDER BY 1;The {{ plan }} placeholder can be wired to a dropdown whose options are themselves the result of another query, which keeps filter lists in sync with the data. Be careful with parameters in production: text parameters are interpolated into the SQL, so restrict who can edit queries and prefer dropdown or number types over free text where the source allows it.
Dashboards, refresh, and alerts
A dashboard is a grid of query visualizations plus optional dashboard-level parameters that fan out to every widget. Each query has its own refresh schedule - Redash runs it on a worker and stores the result - so a dashboard load reads cached results rather than hammering the warehouse on every view. Alerts watch a query's result: you pick a column, a comparison, and a threshold, and Redash notifies Slack, email, or a webhook when the condition trips.
| Concept | What it does |
|---|---|
| Query | One SQL statement against one data source, result cached |
| Parameter | Placeholder rendered as a UI control, query- or dashboard-level |
| Visualization | Chart/table/pivot built from a query result |
| Alert | Threshold check on a query column, pushes to Slack/email/webhook |
Architecture and operation
A Redash deployment is a web server, a Postgres metadata database, a Redis queue, and Celery workers that execute queries and scheduled jobs. The Docker Compose setup wires these together for a small team; larger installs scale the worker pool and split the scheduled-query workers from the ad-hoc ones so a slow report doesn't starve interactive queries. Results live in Redash's Postgres, so a runaway query that returns millions of rows bloats that database - cap result sizes and lean on aggregation in the source query.
Frequently asked questions
Is Redash actively maintained? The open-source project slowed after the Databricks acquisition in 2020, but the self-hosted edition is widely run and community forks keep it patched. Evaluate the release cadence before standardizing on it.
How is it different from Metabase? Redash is SQL-first - you write queries, then visualize. Metabase leads with a point-and-click question builder for non-technical users. Pick Redash when your audience writes SQL and wants parameters and alerts on top.
Does it store a copy of my data? Only cached query results, in its own Postgres metadata database. Source tables stay in the connected database; set result-row limits to keep the cache small.
Can I version-control queries? Not natively as files. Queries live in the metadata DB, but the REST API lets you export and back them up, which teams script into a Git mirror.