SQL Dashboards: Combine Queries on One Page
Last updated August 2, 2026 · By the SaturnSQL team
A SQL dashboard is several saved queries gathered onto one page, with one filter bar controlling every tile instead of a separate link for each query. That is what a dashboard is in SaturnSQL: a place to read a handful of related reports together, each one still backed by a plain SQL query.
This page covers what a SaturnSQL dashboard actually does, how to build one, and, just as importantly, who it is not for.
What's on a SQL dashboard
- Several tiles, one page. Each tile is a saved query. Add as many as the page needs.
- One shared filter bar. It is the union of whatever the tiles ask for, so a "region" filter used by two tiles and a "start date" filter used by a third all appear once, at the top, not once per tile.
- Seven chart types, chosen automatically. Line, area, bar, scatter, share of total, a single big number, or a plain table, picked from the shape of the columns a query returns. Override the guess by hand if it picks wrong, or force a table yourself when a result suits no chart.
- Folders, one level deep. File a dashboard under a folder in the edit dialog, or leave it at the top level.
- Share with the company, or keep it private. A tile is only ever as visible as the query behind it: adding a private query to a shared dashboard does not make that tile visible to anyone else until the query itself is shared.
- A viewer role that gets dashboards, not the SQL editor. Give non-technical teammates the viewer role and they can open every dashboard shared with the company, change filters and read results, with no schema browser, no query editor and no way to see the SQL behind a tile.
- One tile becomes the full report. When only one tile is visible to you, whether that is the whole dashboard or the rest are not shared with you, it stops being a glance and becomes the full report underneath: every row, paginated, with CSV, Excel and JSON export.
- A refresh that skips the cache. Opening a dashboard can show a cached result so it loads fast. Press Update and every visible tile reads the database again, live.
Nothing above is a promise of a future release. It is what shipped, and what this page describes is what you get today.
Building one
1. Write and save the query
Any query that returns rows can become a tile. Add filters with query variables so the same tile can answer "this region" or "this quarter" without a new query for each.
2. Add it to a dashboard
Press Add to dashboard above the results and send it to a dashboard you already have, or start a new one. If the query is still private you are asked whether to share it, since an unshared tile reads as broken to anyone else who opens the dashboard.
3. Share it, or keep it to yourself
Share the dashboard with the whole company when the numbers are for everyone, or leave it private while you are still shaping it. Each tile's query still carries its own share setting underneath.
The queries behind a dashboard's tiles are ordinary saved queries, so anything that already works for a single query still works here: they can be delivered on a schedule to Google Sheets or Slack independently of the dashboard, the same as any other saved query.
Who should not use this
Honesty is the point of this section, not a formality. A SaturnSQL dashboard is several SQL queries on one page with a shared filter bar and automatic charts. It is not a BI platform, and some real needs are out of scope today:
- A drag-and-drop visual builder. Tiles sit in a fixed two-column grid in the order you add them. There is no canvas to drag charts and fields onto.
- Embedded, customer-facing analytics. Dashboards are for your team, shared inside your company. There is no embed SDK for putting a dashboard in front of your own customers.
- A semantic layer. There is no shared metric layer that stops two dashboards from defining "active customer" differently. Every tile is the SQL that built it, which is inspectable but not centrally governed.
- Non-SQL self-serve exploration. Someone has to write the query behind a tile. A business user can change a filter value, not explore new dimensions by clicking around.
If any of those four is the actual requirement, a dedicated BI platform is the right tool, not this page's pitch.
How this fits with the rest of SaturnSQL's reporting
Dashboards are the "several queries together" layer. For a single scheduled report delivered where the team already looks, see automated SQL reports. For row-level work lists refreshed constantly, see operational reporting. For the broader model of getting a whole team to answers without a BI rollout, see self-service analytics. A dashboard is usually a handful of tiles pulled from those other patterns, arranged on one page for a shared view.
Frequently asked questions
What is a SQL dashboard?
Several saved queries on one page, each in its own tile, with a single filter bar covering every tile that shares a filter. It replaces opening one report link at a time with one page that reads together.
Can I chart SQL query results automatically?
Yes. A tile picks from seven chart types, line, area, bar, scatter, share of total, a big number, or a plain table, based on the shape of the result, or you can set the type by hand.
Can non-technical teammates use a SQL dashboard?
Yes, with the viewer role. A viewer opens every dashboard shared with the company, changes filters and reads results, without ever seeing the SQL editor, the schema, or a query's underlying SQL.
Is this a replacement for Tableau or Power BI?
Not for every team. SaturnSQL dashboards cover several SQL queries on one shared filter bar with automatic charts. There is no drag-and-drop builder, no embedded customer-facing analytics, and no semantic layer. Teams that need those should choose a dedicated BI platform.
Put your first few queries on one dashboard