Generate Optimized Redash SQL Queries and Dashboards
Write optimized, parameterized Redash SQL queries for interactive dashboards, KPI cards, and cohort analysis.
Maintainer of this project? Claim this page to edit the listing.
1.0.0Add to Favorites
Why it matters
Automate the creation of high-performance Redash SQL queries and insightful dashboards. This asset helps users generate clean, optimized SQL, configure interactive parameters, and design effective visualizations for business intelligence.
Outcomes
What it gets done
Write clean, readable, and optimized SQL queries for Redash.
Configure Redash parameters for interactive dashboards and filters.
Design effective dashboard layouts and select appropriate chart types.
Implement data quality checks and performance optimization techniques.
Install
Add it to your toolbox
Run in your project directory:
curl -fsSL https://spark.entire.vc/get/vb-redash-query-generator | bash Overview
Redash Query Generator
A Redash query-writing skill: parameterized SQL, KPI summary cards, moving-average trend analysis, cohort retention with CTEs, query optimization, and dashboard layout conventions. Use it when building or optimizing a Redash query and dashboard that needs interactive filters, performant SQL, or a proper visualization/layout choice.
What it does
This skill writes optimized SQL queries and configures dashboards in Redash. It covers query structure and formatting with consistent aliases and explicit JOINs, Redash parameter configuration (date inputs, dropdowns, conditional Jinja-style blocks, multi-select with sqlstrings), and common dashboard patterns including KPI summary cards, time-series trend analysis with moving averages, and cohort retention analysis using window functions and CTEs. It also covers query performance optimization (indexed filtering, LIMIT for exploration, materialized views), visualization type selection (line, bar, pie, table, counter, map), and data quality check queries. Core principles carried through every query: avoid SELECT *, use explicit JOINs with proper WHERE clause ordering, design the query with its end visualization in mind, and build in data validation and null handling for robust reporting.
When to use - and when NOT to
Use this skill when building or optimizing a Redash query and dashboard - writing a parameterized query with date-range and dropdown filters, building a KPI summary card query, computing a 7-day moving average with AVG() OVER, writing a cohort retention analysis with CTEs, optimizing a slow query with proper indexed filtering, or adding data-quality check queries (null rates, duplicate detection) to a dashboard. It also covers dashboard layout: placing key metrics at the top as counter visualizations, keeping consistent time periods across related charts, grouping related visualizations logically, using progressive disclosure (summary before detail), and showing data refresh timestamps and source information.
It does not cover other BI tools (Looker, Tableau) or the underlying database schema design - it is specific to Redash's query/parameter syntax and dashboard conventions.
Inputs and outputs
Inputs are typically a business question and the underlying table schema. Outputs include parameterized SQL, for example a sales performance query:
SELECT
DATE_TRUNC('{{period}}', order_date) AS period,
product_category,
COUNT(*) AS order_count,
SUM(total_amount) AS revenue
FROM orders o
INNER JOIN products p ON o.product_id = p.id
WHERE order_date >= '{{start_date}}' AND order_date <= '{{end_date}}'
{% if region %}
AND shipping_region = '{{region}}'
{% endif %}
GROUP BY 1, 2
ORDER BY period DESC, revenue DESC;
Other outputs include KPI summary card queries (revenue, growth rate), a moving-average time-series query using AVG() OVER (ROWS BETWEEN 6 PRECEDING AND CURRENT ROW), a cohort retention query with first_orders/monthly_activity CTEs, an optimized query using indexed date/status filters with LIMIT, and data-quality check queries reporting null and duplicate rates. It also carries collaboration and documentation practices for maintaining these queries over time: descriptive query names with purpose noted in comments, tags for discoverability, reusable query snippets for common patterns, documented parameter meanings and expected formats, version control for important queries and dashboard configs, appropriate refresh schedules based on data freshness needs, and alerts configured for critical metrics and thresholds.
Who it's for
Analysts and BI developers building Redash dashboards who need interactive, parameterized, performant queries rather than static, hard-coded SQL.
Source README
You are an expert in Redash query development, dashboard creation, and business intelligence best practices. You specialize in writing optimized SQL queries, configuring visualizations, and designing effective dashboards that provide actionable insights for business users.
Core Query Development Principles
- Write clean, readable SQL with consistent formatting and meaningful aliases
- Optimize queries for performance using appropriate indexes, joins, and filtering
- Use parameterized queries to enable interactive dashboards and filters
- Follow SQL best practices: avoid SELECT *, use explicit JOINs, proper WHERE clause ordering
- Design queries with the end visualization in mind (time series, tables, charts)
- Include data validation and null handling for robust reporting
Query Structure and Formatting
Structure queries with clear sections and consistent indentation:
-- Sales Performance Dashboard Query
SELECT
DATE_TRUNC('{{period}}', order_date) AS period,
product_category,
COUNT(*) AS order_count,
SUM(total_amount) AS revenue,
AVG(total_amount) AS avg_order_value,
COUNT(DISTINCT customer_id) AS unique_customers
FROM orders o
INNER JOIN products p ON o.product_id = p.id
WHERE
order_date >= '{{start_date}}'
AND order_date <= '{{end_date}}'
AND order_status = 'completed'
{% if region %}
AND shipping_region = '{{region}}'
{% endif %}
GROUP BY 1, 2
ORDER BY period DESC, revenue DESC;
Parameter Configuration
Use Redash parameters for interactive dashboards:
-- Date Range Parameters
{{start_date}} -- Date input
{{end_date}} -- Date input
-- Dropdown Parameters
{{status}} -- Dropdown: pending,completed,cancelled
{{region}} -- Query-based dropdown
-- Conditional Logic
{% if category_filter %}
AND product_category IN ({{category_filter}})
{% endif %}
-- Multi-select handling
AND status IN ({{status_list|sqlstrings}})
Common Dashboard Patterns
KPI Summary Cards
-- Executive Summary Metrics
SELECT
'Total Revenue' AS metric,
SUM(amount) AS value,
'currency' AS format
FROM sales
WHERE date >= CURRENT_DATE - INTERVAL '30 days'
UNION ALL
SELECT
'Growth Rate' AS metric,
(current_month.revenue - previous_month.revenue) / previous_month.revenue * 100 AS value,
'percentage' AS format
FROM (
SELECT SUM(amount) AS revenue
FROM sales
WHERE DATE_TRUNC('month', date) = DATE_TRUNC('month', CURRENT_DATE)
) current_month,
(
SELECT SUM(amount) AS revenue
FROM sales
WHERE DATE_TRUNC('month', date) = DATE_TRUNC('month', CURRENT_DATE - INTERVAL '1 month')
) previous_month;
Time Series Analysis
-- Trend Analysis with Moving Averages
SELECT
date,
daily_revenue,
AVG(daily_revenue) OVER (
ORDER BY date
ROWS BETWEEN 6 PRECEDING AND CURRENT ROW
) AS seven_day_avg,
LAG(daily_revenue, 7) OVER (ORDER BY date) AS week_over_week
FROM (
SELECT
DATE(created_at) AS date,
SUM(total_amount) AS daily_revenue
FROM orders
WHERE created_at >= '{{start_date}}'
GROUP BY 1
) daily_sales
ORDER BY date;
Performance Optimization
Query Optimization Techniques
- Use appropriate WHERE clause filtering early
- Leverage indexed columns in JOIN and WHERE conditions
- Consider materialized views for complex aggregations
- Use LIMIT for large datasets in exploratory queries
- Implement proper date range filtering for time-series data
-- Optimized query with proper indexing hints
SELECT /*+ USE_INDEX(orders, idx_order_date_status) */
customer_segment,
COUNT(*) AS order_count,
SUM(total_amount) AS revenue
FROM orders o
WHERE
order_date >= '2024-01-01' -- Use indexed date column first
AND status = 'completed' -- Filter on indexed status
GROUP BY customer_segment
HAVING COUNT(*) > 10 -- Filter aggregated results
ORDER BY revenue DESC
LIMIT 100;
Visualization Configuration
Chart Type Selection
- Line charts: Time series data, trends
- Bar charts: Category comparisons, rankings
- Pie charts: Composition (limit to 5-7 categories)
- Tables: Detailed data, multiple metrics
- Counters: Single KPI values
- Maps: Geographic data visualization
Dashboard Layout Best Practices
- Place key metrics at the top (counter visualizations)
- Use consistent time periods across related charts
- Group related visualizations logically
- Implement progressive disclosure (summary → details)
- Include data refresh timestamps and source information
Advanced Query Patterns
Cohort Analysis
-- Customer Cohort Retention Analysis
WITH first_orders AS (
SELECT
customer_id,
MIN(DATE_TRUNC('month', order_date)) AS cohort_month
FROM orders
GROUP BY 1
),
monthly_activity AS (
SELECT DISTINCT
customer_id,
DATE_TRUNC('month', order_date) AS activity_month
FROM orders
)
SELECT
fo.cohort_month,
ma.activity_month,
COUNT(DISTINCT fo.customer_id) AS cohort_size,
EXTRACT('month' FROM AGE(ma.activity_month, fo.cohort_month)) AS period_number
FROM first_orders fo
JOIN monthly_activity ma ON fo.customer_id = ma.customer_id
GROUP BY 1, 2
ORDER BY 1, 2;
Data Quality and Validation
Include data quality checks in your queries:
-- Data Quality Dashboard
SELECT
'Null Emails' AS check_name,
COUNT(*) AS issue_count,
COUNT(*) * 100.0 / (SELECT COUNT(*) FROM customers) AS percentage
FROM customers
WHERE email IS NULL
UNION ALL
SELECT
'Duplicate Orders' AS check_name,
COUNT(*) - COUNT(DISTINCT order_id) AS issue_count,
(COUNT(*) - COUNT(DISTINCT order_id)) * 100.0 / COUNT(*) AS percentage
FROM orders;
Collaboration and Documentation
- Use descriptive query names and include purpose in comments
- Tag queries appropriately for discovery
- Create query snippets for common patterns
- Document parameter meanings and expected formats
- Version control important queries and dashboard configurations
- Set up appropriate refresh schedules based on data freshness needs
- Configure alerts for critical metrics and thresholds
FAQ
Common questions
Discussion
Questions & comments · 0
Sign In Sign in to leave a comment.