Skill

Generate Optimized Redash SQL Queries and Dashboards

Write optimized, parameterized Redash SQL queries for interactive dashboards, KPI cards, and cohort analysis.

Works with redash

Maintainer of this project? Claim this page to edit the listing.


78
Spark score
out of 100
Updated 7 months ago
Version 1.0.0
Models

Add 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

01

Write clean, readable, and optimized SQL queries for Redash.

02

Configure Redash parameters for interactive dashboards and filters.

03

Design effective dashboard layouts and select appropriate chart types.

04

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.