## Summary
Part 4 of the SafeSql migration stack
([#45897](https://github.com/supabase/supabase/pull/45897),
[#45903](https://github.com/supabase/supabase/pull/45903),
[#45990](https://github.com/supabase/supabase/pull/45990), this PR, …).
Converts the remaining reports, query performance, observability, index
advisor, and privileges call sites of `executeSql` to produce
`SafeSqlFragment` values. The `ReportQuery.sql` field flips from
`string` to `SafeSqlFragment`, which cascades into every consumer —
landed here atomically so each branch typechecks cleanly.
Touched areas:
- `interfaces/Reports/*` — `ReportQuery.sql: SafeSqlFragment`, plus all
report definitions/utilities updated
- `interfaces/QueryPerformance/useQueryPerformanceQuery.ts`
- `interfaces/Database/IndexAdvisor/*` and
`data/database/{table-index-advisor,retrieve-index-advisor-result}-query.ts`
-
`data/privileges/{table-api-access,update-exposed-entities}-mutation.ts`
- `interfaces/Storage/StoragePolicies/StoragePolicies.tsx`
- `hooks/analytics/useDbQuery.tsx`
- `Observability/useSlowQueriesCount.ts` +
`useQueryInsightsIssues.utils.test.ts`
## Test plan
- [x] `pnpm typecheck` passes
- [x] `useQueryInsightsIssues.utils.test.ts` passes
- [x] Dev-server smoke test: reports pages, query performance, index
advisor, storage policies
<!-- This is an auto-generated comment: release notes by coderabbit.ai
-->
## Summary by CodeRabbit
* **Refactor**
* Reworked SQL construction and typings across reporting, query
performance, index advisor, and privilege features to use safer SQL
fragments, improving reliability and preventing query composition
issues.
* **Types**
* Reporting query types were split to distinguish database vs. logs
queries, enabling correct handling and validation.
* **Docs/Utils**
* Added a helper to consistently generate logs SQL for report hooks.
* **Tests**
* Updated tests to exercise the new SQL-building API.
<!-- review_stack_entry_start -->
[](https://app.coderabbit.ai/change-stack/supabase/supabase/pull/45998)
<!-- review_stack_entry_end -->
<!-- end of auto-generated comment: release notes by coderabbit.ai -->
## Problem
On self-hosted Supabase instances where the `pg_stat_statements`
extension is not installed, the Observability Overview page
automatically queries the extension on every page load. This produces
"relation pg_stat_statements does not exist" errors in Postgres logs for
all projects without the extension. Additionally, if a user navigated to
the Query Performance page, they received a generic error with no
actionable guidance. A secondary issue allowed malformed sort URL params
(e.g. `?sort=created_at:asc&order=asc`) to be interpolated directly into
SQL ORDER BY clauses.
## Fix
- Wrapped the `useSlowQueriesCount` SQL in a `CASE WHEN EXISTS (SELECT 1
FROM pg_extension WHERE extname = 'pg_stat_statements')` guard. The
query now returns 0 silently instead of erroring when the extension is
absent.
- Added a `VALID_SORT_COLUMNS` whitelist in
`generateQueryPerformanceSql`. Invalid column names from URL params are
rejected and the query falls back to the preset default ORDER BY.
- When the Query Performance page fails because `pg_stat_statements`
does not exist, a `warning` admonition now appears with "Enable it in
Database -> Extensions" guidance instead of a generic destructive error.
The Sentry capture is skipped for this expected configuration state.
- Extracted `buildSlowQueriesCountSql` as a testable function and added
unit tests for both fixes.
## How to test
**Extension not installed (self-hosted):**
1. Run a self-hosted Supabase instance without the `pg_stat_statements`
extension enabled.
2. Navigate to the Observability Overview page.
3. Check Postgres logs -- no "relation pg_stat_statements does not
exist" errors should appear.
4. Navigate to the Query Performance page.
5. Expected: a yellow warning admonition appears saying the extension is
not enabled, with a link to Database -> Extensions. No red error.
**Extension installed (normal flow):**
1. With `pg_stat_statements` installed, navigate to Observability
Overview.
2. Expected: slow queries count loads as normal.
3. Navigate to Query Performance -- data loads as normal.
**Invalid sort URL param:**
1. Navigate to
`/project/<ref>/observability/query-performance?sort=created_at:asc&order=asc`.
2. Expected: the page loads and falls back to the default sort order
(total time descending). No SQL error in logs.
**Unit tests:**
```
node apps/studio/node_modules/vitest/dist/cli.js run --no-coverage \
apps/studio/components/interfaces/Observability/useSlowQueriesCount.test.ts \
apps/studio/components/interfaces/QueryPerformance/useQueryPerformanceQuery.test.ts
```
All 28 tests should pass.
---------
Co-authored-by: Claude Sonnet 4.6 <noreply@anthropic.com>
<!-- This is an auto-generated comment: release notes by coderabbit.ai
-->
## Summary by CodeRabbit
* **New Features**
* Observability Dashboard: unified overview for service health and
database infrastructure with interactive charts and metric cards (CPU,
memory, disk I/O, connections, error rate, slow queries).
* Service Health Monitoring: per-service health cards and a
multi-service table with error/warning counts and drill-down links to
reports/logs.
* Interval Selector: new chart-interval dropdown with plan-aware
retention messaging.
* Menu & Reports: updated Observability menu with Overview entry and
Custom Reports management.
* **Documentation**
* Added a footer link to troubleshooting guides.
<sub>✏️ Tip: You can customize this high-level summary in your review
settings.</sub>
<!-- end of auto-generated comment: release notes by coderabbit.ai -->