## Context
Currently with the SQL Editor, the auto-completion via intellisense only
works nicely with the `.` operator - e.g after keying in a schema and
trying to find a table as such:
<img width="500" alt="image"
src="https://github.com/user-attachments/assets/86ec8455-47b9-43d3-925a-c13d0fd6ac44"
/>
But lacks support for finding the columns of a table after a `where`
clause - so the changes here addresses that by mainly adjust the
`PgSQLCompletionProvider`
Also addresses a number of type fixes (replaces all the `any` types)
<img width="500" alt="image"
src="https://github.com/user-attachments/assets/e23672a6-2b48-4a98-b300-69f822d12b38"
/>
<img width="415" height="319" alt="image"
src="https://github.com/user-attachments/assets/e6ee64d2-90dd-47d6-9fd2-e8b07821ebb6"
/>
<!-- This is an auto-generated comment: release notes by coderabbit.ai
-->
## Summary by CodeRabbit
* **New Features**
* Improved PostgreSQL SQL editor suggestions with table, column, alias,
schema, and join-aware completions.
* Added context-aware support for statements, quoted identifiers,
subqueries, and qualified columns.
* Enhanced PostgreSQL function signature assistance.
* Added safer behavior when database metadata is incomplete or
unavailable.
* **Bug Fixes**
* Prioritized relevant columns and removed duplicate suggestions.
* **Tests**
* Added comprehensive coverage for SQL parsing, metadata handling, and
completion behavior.
<!-- end of auto-generated comment: release notes by coderabbit.ai -->
## Context
Adds an intellisense toggle for explorer notebooks similar to SQL editor
+ have QueryEditor render definitions via `useAddDefinition`
<img width="259" height="162" alt="image"
src="https://github.com/user-attachments/assets/278fdabd-1a24-4769-972e-1bce29060463"
/>
So intellisense will be running in the QueryEditor if intellisense is
enabled + source selected is database, otherwise will not run.
<img width="982" height="411" alt="image"
src="https://github.com/user-attachments/assets/19497aa0-36fc-49ab-853d-cb938b5b18e7"
/>
Also updated `useAddDefinition` logic to flush the table columns +
functions cache in react query
- For context in the past we had users run into browser performance
issues when definitions were loaded if their database is really big
- Hence why we originally added this intellisense toggle
- But we previously also required users to refresh the browser after
disabling intellisense, as a manual way to flush the cache
- So this change should remove the need to refresh the browser after
disabling intellisense
<!-- This is an auto-generated comment: release notes by coderabbit.ai
-->
## Summary by CodeRabbit
* **New Features**
* Added PostgreSQL IntelliSense with definitions, formatting, and code
completions in SQL editors.
* Added a notebook option to enable or disable IntelliSense, with the
preference saved between sessions.
* Improved the notebook’s empty-state appearance.
* **Bug Fixes**
* Improved IntelliSense cleanup and prevented duplicate registrations
when disabled.
* Improved query execution state handling while background IntelliSense
data loads.
* **Tests**
* Added coverage for shared registration, cleanup, preference
persistence, and IntelliSense-related query handling.
<!-- end of auto-generated comment: release notes by coderabbit.ai -->
## 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?
Feature (SQL editor: execution wiring for logs-source snippets). Part of
the stacked SQL-editor "Database vs Logs" query-source series.
## What is the current behavior?
The SQL editor only ever runs queries against the user's Postgres
database. There is no execution path for a logs (`log_sql`) snippet, and
the run-button telemetry event carries no backend discriminator.
## What is the new behavior?
- `useRunSource(id)` derives the run backend from the snippet type; a
`log_sql` snippet resolves to `{ type: 'logs', dateRange }`, pairing the
run with its session time range (default: last hour).
- `useLogsSqlExecution` runs a promoted `SafeLogSqlFragment` against the
analytics OTEL (ClickHouse) endpoint with the resolved time range as
`iso_timestamp_start`/`iso_timestamp_end` request params. The endpoint
is **pinned to OTEL** — a snippet's dialect must not flip with org
migration.
- The run gestures (toolbar button and Cmd+Enter) branch on the source
and promote with the matching `acceptUntrusted*` right at the user
action, preserving the auditable promotion-at-gesture boundary. pg
intellisense is gated off for logs snippets.
- The `sql_editor_query_run_button_clicked` telemetry event gains a
required `{ source: 'database' | 'logs' }` property, fired from both
execution paths.
- Capability guard: a `log_sql` snippet is reachable by direct URL
regardless of the (later) entry-point flag gating, so `executeLogsQuery`
short-circuits when `otelLegacyLogs` is off — recording a clear "not
available yet" result message instead of firing a request that would
only return an opaque backend error on a non-ClickHouse project. This is
a guard on the gesture, not endpoint selection.
- Tests: `useRunSource` routing, `useLogsSqlExecution`
endpoint/range/structured-error/capability-guard, and a reusable `flags`
option on `renderSqlEditorHook`.
No UI entry points are added — the feature runs dark until the
flag-gated creation/nav PRs later in the stack.
## Additional context
Stacked on the query-source series; base branch is `master` now that PR
4 (log date range domain + session state, #48401) is merged. Follow-ups
in the stack add the toolbar/creation UI (with a run-affordance gate on
`otelLegacyLogs`), nav section, AI dialect support, and reports guard.
<!-- This is an auto-generated comment: release notes by coderabbit.ai
-->
## Summary by CodeRabbit
* **New Features**
* Added support for running log queries directly from the SQL editor.
* Log query results, errors, and time ranges are now handled within the
editor session.
* Added automatic selection between database and log query execution,
including support for custom date ranges.
* SQL assistance is disabled while editing log queries where database
definitions do not apply.
* **Tests**
* Added coverage for log query execution, date ranges, feature
availability, and execution source selection.
<!-- end of auto-generated comment: release notes by coderabbit.ai -->
Hides the "Multigres" term from user-facing surfaces — it's the tech
powering High Availability projects, but "High Availability" is the only
term users should see for now (per Slack discussion with Saxon/Ivan).
**Changed:**
- High Availability badge hover card (project overview) no longer says
"Driven by Multigres"
- Project creation HA toggle description drops the Multigres name +
multigres.com link, keeps the informational copy
- All schema dropdowns now hide the `multigres` schema on HA projects,
by wiring in the previously-unused `filterSchemasForHighAvailability`
helper:
- `SchemaSelector` (shared — Table Editor, Functions, Indexes, Triggers,
Schema Visualizer, etc.)
- `ExposedSchemaSelector` (API settings → exposed schemas)
- `EnableExtensionModal`, `CreateIndexSidePanel`, `ForeignKeySelector`,
`WrapperTableEditor`, Integrations install sheet `AdvancedSettings`
- SQL editor schema autocomplete (`useAddDefinitions`)
- Schema list computations in the touched components are now memoized
(incl. stabilizing `SchemaSelector`'s `excludedSchemas` default so the
memo actually holds)
**Added:**
- Unit tests for `filterSchemasForHighAvailability` /
`resolveHighAvailability`
- MSW component test for `SchemaSelector` asserting `multigres` is
hidden on HA projects and still shown on non-HA projects
The filter is HA-gated on purpose: a self-hosted/non-HA user with their
own schema named `multigres` still sees it. The flag-gated Multigres
option in Logs is intentionally untouched — that exposure is kept for
the Multigres team's debugging (separate track).
## To test
- On an HA project (`high_availability: true`): hover the High
Availability badge on project overview — no "Multigres" mention; open
schema dropdowns in Table Editor / Database pages / SQL editor
autocomplete — no `multigres` schema
- Project creation with HA entitlement: toggle description has no
Multigres wording/link
- On a non-HA project: schema dropdowns behave as before
<!-- This is an auto-generated comment: release notes by coderabbit.ai
-->
## Summary by CodeRabbit
* **Improvements**
* Made schema dropdowns and related selectors high-availability aware
across extensions, indexes, integrations, SQL editing, API exposed
schemas, and relationship editors.
* Updated project high-availability UI text and badge hover description
to remove outdated branding and clarify horizontally scalable Postgres
architecture.
* **Tests**
* Added coverage to ensure the schema “multigres” option is hidden/shown
correctly based on high availability, and validated high-availability
value handling.
<!-- end of auto-generated comment: release notes by coderabbit.ai -->
---------
Co-authored-by: Alaister Young <10985857+alaister@users.noreply.github.com>
## What
Final PR of the SQL editor state re-layering stack. Removes the
compatibility shims left in place during the migration:
- Migrates all **23** consumers of the `@/state/sql-editor-v2` facade to
import directly from `@/state/sql-editor/sql-editor-state`, where
`useSqlEditorV2StateSnapshot`, `getSqlEditorV2StateSnapshot`,
`useSnippets`, and `useSnippetFolders` actually live.
- Deletes `state/sql-editor-v2.ts` (the facade) and
`state/sql-editor/index.ts` (the barrel). Both re-exported the same
symbols; nothing imports them after the migration.
This collapses the two-layer re-export (`sql-editor-v2` → `index` →
source) into direct source imports, matching the repo convention to
avoid barrel re-export files.
## Notes
- Pure import-path migration — no behavior change. All 23 consumers
imported only value symbols that resolve to `sql-editor-state.ts`; none
imported the `StateSnippet`/`StateSnippetFolder` types via the facade.
- Symbol names keep their `V2` suffix for now — renaming
`useSqlEditorV2StateSnapshot` etc. is a separate, larger churn best done
on its own.
- 25 files: 23 one-line import changes + 2 deletions (23 insertions / 39
deletions).
## Validation
- `pnpm --filter studio typecheck` ✅ (confirms no dangling facade/barrel
imports anywhere)
- `pnpm exec vitest --run state/sql-editor/` ✅ (113 passed)
- lint ✅ (0 errors; no ratcheted-rule regressions — a path swap can't
add `any`/deps/nested-component violations, and no import-order rule is
enforced)
- grep confirms zero remaining `sql-editor-v2` references
---------
Co-authored-by: supabase-autofix-bot <noreply@supabase.com>
* Bump Nextjs to v16.
* Fix studio issues.
* move docs graphiql css import to layout
* update sentry
* add missing docs package and fix imports
* only update studio
* ignore next-env.d.ts
* update bundle analyzer
* middleware to proxy
* update lockfile
* remove --turbopack dev flag as it's the default
* Import only types from the monaco editor.
---------
Co-authored-by: Alaister Young <a@alaisteryoung.com>
* Replace all usage of useProjectContext with useSelectedProjectQuery
* Replace all usage of useSelectedProject with useSelectedProjectQuery
* Replace all usage of useProjectByRef with useProjectByRefQuery
* Replace all usage of useSelectedOrganization with useSelectedOrganizationQuery
* Deprecate useSelectedProject, useSelectedOrganization, and useProjectByRef hooks
* Deprecate ProjecContext
* docs: user nav dropdown
* www: user dropdown nav
* update menus
* chore: add complete local storage allowlist
* move all local-storage to common
* reload after logOut
* add local storage key changes from #35175
* fix errors
* add more keys
* fix merge bugs
---------
Co-authored-by: Alaister Young <a@alaisteryoung.com>
Joshen Lim