## I have read the
[CONTRIBUTING.md](https://github.com/supabase/supabase/blob/master/CONTRIBUTING.md)
file.
YES
## What kind of change does this PR introduce?
Bug fix
## What is the current behavior?
search is passed in un-escaped
## What is the new behavior?
escapes to ensure correct query format
<!-- This is an auto-generated comment: release notes by coderabbit.ai
-->
## Summary by CodeRabbit
## Bug Fixes
- Enhanced query safety and reliability in performance monitoring with
improved parameter handling
- Fixed query condition handling for edge cases with non-finite values
## Refactor
- Simplified query generation logic and streamlined internal
implementation
<!-- 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>
## Problem
The Query Performance page loaded all results in a single query with a
fixed limit of 20 rows, giving users no way to browse beyond the first
page. There was also no way to control how many rows were shown at once.
## Fix
adds pagination
## How to test
- Navigate to `/observability/query-performance` in Studio
- scroll to bottom
- should automatically load more results
---------
Co-authored-by: Claude Sonnet 4.6 <noreply@anthropic.com>
## Context
Adds a source filter for the query performance advisor so you can filter
out queries from the dashboard, or not from the dashboard
<img width="309" height="217" alt="image"
src="https://github.com/user-attachments/assets/c1fab9af-e57e-482f-afdb-d77a6600edb3"
/>
For transparency how this works:
- Queries fired via the dashboard through the /query endpoint get
enriched with metadata from the API to include a comment like `--
source: dashboard`
- That's mainly how this filter works atm, to check if this comment
exists if the source "Dashboard" is selected, and the inverse if the
source "Non dashboard" is selected
Etienne Stalmans