I spent three years writing about Redash. The first post in late 2018 framed it as on-demand analytics with a SQL console that worked against any database, including ClickHouse, which at the time no other BI tool supported well. Across the next nine posts I covered visualizations, the funnel and cohort widgets, query-result chaining via the internal SQLite, parameters (text, number, dropdown, query-dropdown, date ranges), email and Slack alerts, and the new multi-select feature in v8. Each post was a small recommendation: here’s why this Redash feature is good, here’s how to use it.
In This Article
Six years later, the recommendations need an update. Databricks acquired Redash in June 2020 and folded the work into Databricks SQL. The last open-source release shipped in March 2024. The product itself isn’t gone, but the active development is, and the BI landscape around it has moved on. Most teams I work with still running Redash in 2026 are doing so because nobody scheduled the migration. This is a guide to scheduling it, written from the perspective of someone who already wrote the manual for using Redash and is now writing the manual for leaving it.
The features that made Redash worth using
Reading back through my 2018-2020 posts, the case for Redash came down to five things, in roughly this order:
The SQL console as the primary interface. Save a query, name it, share a link to it. Everyone who opens the link sees the same SQL and the same result. The first paragraph of my 2018 introduction said “the main thing Redash gives you is a convenient console for writing SQL queries.” That was the product’s center of gravity, and it’s why analysts who learned on Redash sometimes resist BI tools that hide SQL behind a semantic layer.
Real visualizations from a single query. My 2018 post on visualizations walked through bar, line, area, stacked, and mixed-chart-type combinations — including a dual-axis chart with MAU as bars and “share of new users” as a line on a secondary axis. The Redash visualization layer was good enough that the chart in the post is one I’d still ship in 2026, with the caveat that the secondary axis is now a more controversial choice than it used to be.
Funnel and cohort widgets as first-class chart types. I wrote a separate post on each in 2018-2020 because most BI tools at the time didn’t have a built-in cohort widget; you’d build it manually with a heatmap and a custom color scale. Redash had a dedicated “Cohort” visualization that took a query with cohort/day/value columns and rendered the triangle correctly. Same for funnels: feed it a stage/value table and it draws the funnel.
Parameters in queries and shared across dashboards. The 2020 parameters post covered six parameter types (text, number, dropdown, query-dropdown, date, date-range), the multi-select that arrived in v8, and a useful trick: a “Disabled” entry in a dropdown that makes the parameter optional via WHERE ('{{parameter}}' = 'Disabled' OR geo = '{{parameter}}'). Parameters that share a name across multiple queries on the same dashboard automatically become a single dashboard-level filter. That last property is still worth migrating to, and not every modern BI tool does it as cleanly.
Alerts on query results, into email or Slack. The 2019 alerts post showed how to wire a daily query to a Slack channel when a metric moved beyond a threshold. The pattern Nick used in the post — store query results in the internal SQLite via the query-results data source, then alert on the delta — was elegant and worked for a long time.
What you’re leaving behind, by the numbers
Our team’s BI-systems comparison from December 2020 scored Redash 6.5 / 10 against Metabase 8.0, Superset 7.7, Tableau 8.8, Power BI 8.0, Looker 7.7, Qlik Sense 8.4, and Yandex DataLens 8.0. The 6.5 wasn’t a bad score; it was a “fine for what it is, weaker than the alternatives on most axes” score. The specific axes were entry barrier, functionality, ease of use, fit-to-spec, and visual appearance. Redash scored above average on entry barrier (low — anyone who writes SQL is productive in an afternoon) and below average on functionality and visual appearance.
Those 2020 scores roughly hold in 2026, with one important shift: Metabase and Superset both moved meaningfully forward over the last five years, Redash didn’t, and the gap widened. A team that scored Redash 6.5 in 2020 should expect to score it around 5 in 2026, mostly from features the alternatives added (semantic layer, audit logs, modern auth) that Redash did not.
The inventory you need before choosing a target
The Redash UI hides more state than it shows. Before comparing target tools, pull four things out via the API (/api/queries, /api/dashboards, /api/alerts):
1. Queries. Every saved query, with its SQL, parameters, data source, and last-viewed timestamp. Tag each row “active in last 90 days” or “stale.” Most Redash instances I’ve audited have 200-2,000 queries; the split is usually 30-60% stale.
2. Dashboards. Every dashboard, its layout, the widgets it contains, and which queries each widget references. The layout matters for the migration: rebuilding the same 3×4 grid in the target tool is faster when you have the original layout.
3. Parameters. Every parameter on every query, especially the query-dropdown ones. A query-driven dropdown (“region → store → SKU”) is the highest-risk migration object because each target tool handles cascading parameters differently. Inventory these separately.
4. Alerts. Every alert, its condition (e.g. “value < 100"), and its destination (email or Slack channel). Decide per alert whether it stays in the BI tool or moves to dbt tests / Slack Workflow / a small Cron + curl script.
The output of this step is a Google Sheet with one row per query, dashboard, and alert, scored by “active in last 90 days” and “load-bearing yes/no.” Without this sheet the migration drifts on for months.
Three target architectures
There are more than three modern BI tools, but for a team coming off Redash the realistic choices fall into three families.
Metabase. The closest spiritual successor to Redash. SQL editor is first-class (and includes the dropdown-driven parameter UX that Redash analysts will recognize). Cohort and funnel are available as standard chart types. The free self-hosted version is genuinely usable; Metabase Cloud Pro adds SSO, embedding, and audit logs. Internal scores in our 2020 comparison: 8.0 / 10, and the gap to Redash has only widened. Most ex-Redash teams I’ve moved to Metabase tell me within a quarter that they don’t miss the old tool.
Apache Superset. The other strong open-source option, originally from Airbnb, now an Apache top-level project. SQL Lab is the part ex-Redash analysts gravitate to: modern editor with autocomplete, query history, and saved queries. Dashboards are more powerful than Metabase’s, with richer visualizations and a row-level security layer. The cost is operational — Superset is a Python service + Celery + Redis + metadata DB, and deploying it is heavier than Metabase. Internal score in our 2020 comparison: 7.7 / 10.
Warehouse-native (dbt + lightweight viz). Compute the metric in dbt, materialize it as a wide table, and use a thin viz layer (Lightdash, Hex, Mode, even Google Sheets via Connected Sheets) on top. This is the right call when 80% of the Redash usage was “analyst writing SQL for an internal request” and only 20% was “stakeholder reads a dashboard on Monday.” It removes the BI tool from the metric definition entirely, which solves the “every team has a different number” problem at the cause.
A four-question decision framework
The framework I use in engagements answers the choice in about 30 minutes:
Q1. How many active SQL authors, how comfortable with deployment? Two or three analysts who don’t want to learn Kubernetes → Metabase. A platform-aware data engineering team → Superset. A team where Redash is mostly used for ad-hoc one-offs that would be better as dbt models → warehouse-native.
Q2. What’s the dashboard-to-query ratio? If 80% of Redash’s value is the saved queries (notebook-style use), warehouse-native + Lightdash/Hex usually wins. If 80% is the dashboards on the office TV, Metabase or Superset.
Q3. Hard requirements around row-level security, SSO, audit logs? Superset and Metabase Pro both handle it; vanilla Metabase handles it lightly; warehouse-native pushes it into BigQuery row-level access policies or Snowflake row access policies — the most defensible place but the longest to set up.
Q4. Operational budget for the tool itself? Metabase Cloud Pro is roughly $85/user/month with seat discounts above 25. Self-hosted Metabase is free + a small share of an engineer. Superset on Preset Cloud starts in a similar range; self-hosted Superset is more engineering time. Warehouse-native pushes the cost into compute, which is linear with usage and harder to estimate up-front.
Most of the time the answers point cleanly at one tool. The teams that get stuck are the ones answering “yes, all of those” — and the right answer there is sometimes “Superset for the platform team, Metabase for the business teams,” which is less expensive than it sounds.
The migration itself, eight weeks
A workable plan, drawing on the migrations our team has run:
Week 1 — inventory + freeze. Pull queries, dashboards, alerts via the Redash API. Tag each row active / archive / migrate. Freeze new dashboard creation in Redash (Slack announcement, pinned message).
Weeks 2-3 — target setup + parameter library. Stand up the target tool. Recreate data-source connections to the warehouse, pointing at the same sources. Build the parameter library — every shared dropdown filter — once, centrally, so each migrated dashboard reuses it rather than recreates it.
Weeks 4-6 — rebuild in priority order. Go down the migration list dashboard-by-dashboard, top-10 most-viewed first. For each: rebuild it, send a Slack message with the new link to its stakeholders, then hide the Redash original. Resist the urge to “make it better” while migrating; an exact rebuild is approved faster.
Week 7 — alerts and schedules. Move scheduled refreshes to the new tool. Per alert, decide where it belongs: BI tool alert / dbt test / Slack Workflow / Cron + script.
Week 8 — decommission. Snapshot the Redash metadata DB and the query-results SQLite. Turn off the worker. Leave the read-only instance up behind a “deprecated — use [new tool]” banner for one more month, then shut it down.
The two places this plan slips, every engagement: the parameter library takes longer than budgeted (especially query-driven dropdowns), and the “active / archive / migrate” tagging is too loose the first time and gets redone after stakeholders complain. Budget extra time for both.
A checklist before you start
- Full inventory of queries, dashboards, alerts exported via the Redash API
- Each row tagged active / archive / migrate, with a stakeholder name
- Target tool chosen with a one-paragraph rationale that references the four questions
- Parameter library mapped: query-driven dropdowns → semantic-layer filters
- Alerts inventoried separately, with a decision per alert (BI tool / dbt test / Slack Workflow)
- Freeze date for new Redash content communicated to stakeholders
- Decommission date on the calendar (8 weeks for a 500-query instance is realistic)
- Snapshot policy for the read-only Redash DB post-shutdown
If any of those are missing, the migration will overrun — not by a week, by a quarter.
Further reading
- 10 Dashboard Design Rules, Six Years Later — what the dashboards on top of the new tool should look like
- Cohort Analysis in 2026: Beyond Redash, Beyond Mixpanel — the cohort widget Redash had natively and where it lives now
