---
slug: performance-issues
title: Performance Issues
section: Reference
description: Diagnose slow queries, high memory usage, or sluggish dashboards.
listed: false
---
# Performance Issues

**Use this page to diagnose slow queries, high memory usage, or sluggish Dashboards. Start by finding out which stage is slow, then apply the matching fix.**

## Quick triage

Work out where the slowness is:

- **Slow to connect?** Check network, VPN, and database reachability.
- **Slow to run?** Check query shape (filters, joins, aggregations) and source-system performance.
- **Slow to render?** Reduce result set size or pre-aggregate before visualising.

## The fastest wins (most common)

- **Filter early**: limit time ranges and partitions first, so fewer rows enter the pipeline.
- **Select fewer columns**: avoid `SELECT *` when you can, so the source returns less data over the wire.
- **Aggregate before charting**: Charts render far faster on tens of rows than on millions.

## Query-level fixes

- **Filter aggressively** on date range, partitions, and key subsets.
- **Select only required columns** to avoid pulling unused data.
- **Pre-aggregate** before charting, especially for high-cardinality dimensions.

## Source-system checks

- **Indexes and partitions**: verify they exist for the columns you filter on.
- **Warehouse compute**: check size and concurrency if you are on Snowflake, BigQuery, or similar.
- **Locks and contention**: check whether other workloads are fighting for the same resources.

## When to escalate

If performance is consistently poor even for small queries, collect:

- **Source type** (Postgres, Snowflake, DuckDB, etc.).
- **Example query**, sanitised.
- **Approximate row counts** at each stage.
- **Machine specs** (CPU and RAM).

Then contact support with that bundle.

## Related pages

- [Connection Problems](/docs/connection-problems)
- [Querying Data](/docs/querying-data)
- [Filtering Data](/docs/filtering-data)
- [Building Dashboards](/docs/building-dashboards)