mirror of
https://github.com/supabase/supabase.git
synced 2026-10-06 01:45:10 +03:00
support-policy-changes
373
Commits
| Author | SHA1 | Message | Date | |
|---|---|---|---|---|
 Danny White
|
6143441493 |
fix(pipelines): clarify DuckLake destination setup (#51013)
## Problem The DuckLake setup form makes it hard to choose between Supabase projects and external connection details. Bucket creation, catalog settings, and the guide do not clearly follow the setup flow. ## Solution - Show **Configuration method** as two clear choices: **Select Supabase projects** and **Enter connection details**. - Group catalog and storage fields, move **Pool size** to **Advanced settings**, and add **New bucket** to the bucket selector. - Clarify the custom Postgres and S3 fields, including the metadata schema, connection URL, and storage options. - Update the [DuckLake destination guide](https://docs-git-dnywh-ducklake-pipelines-setup-supabase.vercel.app/docs/guides/database/replication/pipelines/ducklake) to follow the form and explain resource preparation and validation. | Before | After | | --- | --- | | <img width="1280" height="1323" alt="50587" src="https://github.com/user-attachments/assets/bf5997cf-9fc4-48a8-ad4f-13fa991d56f9" /> | <img width="1280" height="1323" alt="61914" src="https://github.com/user-attachments/assets/2c1dd7ef-797f-4302-9e2e-93a5f1e6e515" /> | ## Review instructions 1. Open **Database > Pipelines > Add pipeline** and select **DuckLake**. 2. Select **Select Supabase projects**. Check the catalog and storage fields, create a bucket from the bucket selector, and find **Pool size** under **Advanced settings**. 3. Select **Enter connection details**. Check the Catalog URL, S3 URL style, and Use SSL guidance. 4. Compare both routes with the [DuckLake destination guide](https://docs-git-dnywh-ducklake-pipelines-setup-supabase.vercel.app/docs/guides/database/replication/pipelines/ducklake). ## Checklist - [x] I have read [CONTRIBUTING.md](https://github.com/supabase/supabase/blob/master/CONTRIBUTING.md) - [x] I used the `/edit-the-docs` skill and the docs [style guide](https://github.com/supabase/supabase/tree/master/apps/docs/style-guide) <!-- This is an auto-generated comment: release notes by coderabbit.ai --> ## Summary by CodeRabbit * **New Features** * DuckLake destinations support Supabase-managed projects or an existing Postgres catalog with S3-compatible storage. * Select a storage bucket using search, configure a metadata schema, and access clearer guidance for catalog and storage settings. * Advanced settings provide a connection pool size from 1 to 6, with a default of 4. Credential fields include show and hide controls. * **Documentation** * Updated setup steps, configuration guidance, query credential details, and troubleshooting instructions for both configuration modes. <!-- end of auto-generated comment: release notes by coderabbit.ai --> |
||
|
Miranda Limonczenko
|
e29f4e0736 |
docs(database): style pass on the database functions guide (#50820)
Inline rewording only. Nothing moves and no claim changes. Addresses reader-facing "we", UI labels in quotes rather than bold, "allows you to", "e.g.", future tense, and title-case common nouns in body prose. |
||
|
samroseandArtur Zakirov
|
9946747579 |
docs(orioledb): update OrioleDB docs for public beta (#50813)
> [!IMPORTANT] > Don't merge until the OrioleDB public beta launches. Docs deploy on merge. ## What Updates the OrioleDB guide (`guides/database/orioledb`) for the public beta: - States that OrioleDB is in public beta and that OrioleDB projects have access to the same paid features as other Supabase projects. - Replaces the outdated "choose `OrioleDB Public Alpha` Postgres version" instruction and its screenshot with text steps that match the current project creation form (**Advanced Configuration** → **Postgres Type** → **Postgres with OrioleDB**). It also notes that OrioleDB can't be added to or removed from an existing project. A new screenshot will follow once the dashboard shows the beta labels. - Corrects the `orioledb.default_compress` range to `-1` to `22`. Values outside that range are rejected. - Updates the `EXPLAIN` output for the primary key lookup to match what OrioleDB returns (`Custom Scan (o_scan)`). - Replaces the benchmark chart's alt text with a description of the chart. Headings, frontmatter, and navigation are unchanged, so existing links to this page and its sections still work. ## Checked against upstream OrioleDB Checked the page's claims against the [OrioleDB docs](https://github.com/orioledb/orioledb/tree/main/doc/usage) and codebase on `main`: - The concepts section, the `orioledb.serializable` values, and the compression settings match. - The limitations link still resolves (`#current-limitations`). - Doc changes on `main` since beta17 (collations, sparse files, concurrent unique bridged indexes) don't affect claims on this page. ## Verification (`/test-the-docs`) | Snippet / step | Class | Sandbox | Result | Notes | | --- | --- | --- | --- | --- | | `create table blog_post …` | runnable-local | DinD + runner, `supabase/postgres:17.9.0.028-orioledb` | pass | Table created with the `orioledb` access method (default) | | `create index …` (2 indexes) | runnable-with-setup | same | pass | | | `insert …` + `select …` | runnable-with-setup | same | pass | Timestamp differs, as expected | | `explain` (3 statements) | runnable-with-setup | same | pass | Primary key lookup output updated in this PR to match | | `select … from pg_settings where name like 'orioledb.%'` | runnable-local | same | pass | All 10 automatically tuned settings present | | `alter database … default_compress to 1` | runnable-local | same | pass | | | Compression range `-1`–`22` | claim check | same | pass | `23` rejected: "outside the valid range (-1 .. 22)" | | User-configurable settings have `user` context | claim check | same | pass | `serializable` values match the page | | Hidden `ctid` key when no primary key is defined | claim check | same | pass | | | HNSW index via index bridging | claim check | same | fail (product bug) | Index misses rows inserted after it's created. Known upstream as orioledb/orioledb#1118, fixed after beta17. The tested image bundles an earlier OrioleDB release. Re-test on an image with beta18 before merging. | | Dashboard project creation steps | deferred | — | deferred | Needs a hosted project; labels checked against Studio source | **Tier A path:** every SQL block on the page, run in page order against the Supabase OrioleDB image. **Environment:** Docker 29.4.0 (linux/aarch64); compose sandbox from `test-the-docs`; all SQL run inside the runner container. **Build:** `pnpm build:guides-markdown` passes; the generated markdown for this page includes all changes. ## Self-review **Blockers:** none. **Before merging:** - [ ] Re-run the HNSW check on an image with OrioleDB beta18. - [ ] Re-check the page against the `beta18` tag once it's published. **Nits left for a follow-up (existing text, outside this PR's scope):** - The page spells `pg_vector`; the extension is `pgvector`. - Index support is described twice, in the top note and again under "Creating indexes". - The markdown export (`internals/markdown-schema/Admonition.ts`) drops admonition titles on every page. This PR avoids relying on a title for the beta status. Linear: DOCS-1399 🤖 Generated with [Claude Code](https://claude.com/claude-code) <!-- This is an auto-generated comment: release notes by coderabbit.ai --> ## Summary by CodeRabbit * **Documentation** * Updated the OrioleDB guide with benchmark results for an 8xlarge instance, including a 1.8x speedup and throughput data across 32–256 connections. * Clarified that OrioleDB projects have access to the same paid features as other Supabase projects, and added guidance to review its limitations. * Updated project setup instructions, noting that OrioleDB must be selected when creating a project and cannot be added later or removed. * Revised the query plan example and documented compression levels from `0` through `22`. * **Product Updates** * Updated OrioleDB’s availability stage to public beta. <!-- end of auto-generated comment: release notes by coderabbit.ai --> --------- Co-authored-by: Artur Zakirov <zaartur@gmail.com> |
||
|
Danny White
|
6b7c91a773 |
docs(pipelines): clarify ClickHouse setup and form copy (#51009)
## Problem The ClickHouse destination guide leaves parts of resource setup unclear. The pipeline form suggests the `default` ClickHouse user and database even when a dedicated user and database are prepared. ## Solution - Clarify the ClickHouse setup path, connection details, engine choice, and query example in the guide. - Align the pipeline form's labels, examples, and help text with that setup path. - Include **Start pipeline** in the BigQuery guide before the cost confirmation and **Create and start pipeline**. ## Review instructions 1. Open **Database → Pipelines**, add a pipeline, and choose **ClickHouse**. Check the endpoint label, user and database examples, and table engine help. 2. Read the [ClickHouse destination guide](https://supabase.com/docs/guides/database/replication/pipelines/clickhouse), especially **Prepare ClickHouse resources** and **Configure ClickHouse as a destination**. <!-- This is an auto-generated comment: release notes by coderabbit.ai --> ## Summary by CodeRabbit * **Documentation** * Updated the BigQuery guide to explain the pipeline validation, cost review, and start steps. * Expanded the ClickHouse guide with destination setup requirements, engine behavior, and querying guidance for current-state views and append-only history. * **User Experience** * Clarified ClickHouse connection field labels and descriptions, password visibility controls, and table-engine options in the setup form. <!-- end of auto-generated comment: release notes by coderabbit.ai --> |
||
|
Kody Jacksonandkodster28-happy-hour
|
708bfa7ad1 |
[docs] Fix broken links to '/guides/' paths (#50870)
## Problem There are several broken links within docs that reference `/guides/...`. These need to be updated to `/docs/guides/` to resolve correctly. ## Solution Updated links to resolve correctly ## Preview links If relevant, include links to changed pages for easy review access. TBD, waiting on build (unclear if this happens for external contributions). ## Review instructions 1. Navigate to the pages in the live/preview. 2. Click the links that were updated. ## Checklist Check all before review: - [x ] I have read [CONTRIBUTING.md](https://github.com/supabase/supabase/blob/master/CONTRIBUTING.md) <!-- This is an auto-generated comment: release notes by coderabbit.ai --> ## Summary by CodeRabbit * **Documentation** * Updated internal documentation links across API, Auth, Database, Functions, and troubleshooting guides to use the `/docs` paths. <!-- end of auto-generated comment: release notes by coderabbit.ai --> Co-authored-by: kodster28-happy-hour <kody@catholicestateplanning.com> |
||
|
Danny White
|
b03448ec59 |
docs(pipelines): improve Snowflake setup guidance (#50715)
## Problem The Snowflake guide leaves several setup details open to interpretation, particularly how roles are used and which RSA key content belongs in Snowflake versus the Dashboard. This PR is stacked on #50751 so the documented role location, private-key upload, and **Start pipeline** action match the updated creation sheet. The full stack starts with #50708, which moves the guide to its nested Pipelines path. ## Solution Clarifies the setup sequence, explains the default and optional role behaviour, distinguishes `rsa_key.pub` from `rsa_key.p8`, and makes the destination field guidance more direct. ## To test - [Snowflake guide](https://docs-git-dnywh-docsimprove-snowflake-setup-supabase.vercel.app/docs/guides/database/replication/pipelines/snowflake) ## Review instructions 1. Read the setup path from **Prepare Snowflake resources** through **Configure Snowflake as a destination**. 2. Confirm the role guidance explains what happens when the Dashboard field is empty. 3. Confirm it is clear which key file is registered in Snowflake and which file is pasted or uploaded in the Dashboard. ## Checklist - [x] I have read [CONTRIBUTING.md](https://github.com/supabase/supabase/blob/master/CONTRIBUTING.md) - [x] If I wrote a new docs topic or edited an existing topic, I used the `/write-the-docs` or `/edit-the-docs` skill, which references [WORD_LIST](https://github.com/supabase/supabase/blob/master/apps/docs/WORD_LIST.md) and the docs [CONTRIBUTING](https://github.com/supabase/supabase/blob/master/apps/docs/CONTRIBUTING.md) guide <!-- This is an auto-generated comment: release notes by coderabbit.ai --> ## Summary by CodeRabbit * **Documentation** * Updated the Snowflake guide with clearer setup steps and requirements for roles, ownership, key handling, account IDs, and Dashboard settings. * Expanded guidance on append-only history, current-state queries, dynamic-table freshness and costs, stream and task recovery, type serialization, and the effects of schema changes on historical data. * Renamed the pipeline setup button to **Start pipeline**. <!-- end of auto-generated comment: release notes by coderabbit.ai --> |
||
|
|
c3c741c20e |
docs: warn about postgres.js pipelining on Supavisor transaction mode (#50712)
Re-does #50082 against the redesigned `connecting-to-postgres.mdx` (see [Slack discussion](https://supabase.slack.com/archives/C04JR9DBNQL/p1789991651381399?thread_ts=1788980733.712609&cid=C04JR9DBNQL)). What changed vs. #50082: - `connecting-to-postgres.mdx`: the pipelining caution now lives in the new **Transaction mode limitations** section (the old "Pooler transaction mode" prose it was in got redesigned), and is a short redirect to the Postgres.js guide rather than a full explanation. - `postgres-js.mdx`: keeps the full warning, the `{ prepare: false }` workaround, and now explains *why* pipelining can't just be turned off (`max_pipeline: 0` breaks `sql.begin()`, tracked in porsager/postgres#1189), plus a "contact support" prompt for anyone still stuck, and a note that Supavisor v2.10 will add native pipelining support. - Drops the standalone troubleshooting page from #50082 — the team wasn't confident enough yet to officially point everyone at the `postgres.js` patch, so support is the escalation path for now instead. - Re-adds the `Rule003Spelling.toml` allow-list entry for "pipelining" (not present on `master`). 🤖 Generated with [Claude Code](https://claude.com/claude-code) <!-- This is an auto-generated comment: release notes by coderabbit.ai --> ## Summary by CodeRabbit * **Documentation** * Clarified that query pipelining is unsupported in transaction mode and may cause hangs or mismatched results. * Documented Postgres.js pipeline behavior, recommended workarounds, and planned native support in a future Supavisor release. * Updated the Postgres.js connection example to disable prepared statements for improved compatibility. * Added a support contact link for assistance with transaction-mode pipeline issues. <!-- end of auto-generated comment: release notes by coderabbit.ai --> ## Preview * pipelining mentioned in the Supavisor TX mode: https://docs-git-docs-postgres-js-pipelining-warning-supabase.vercel.app/docs/guides/database/connecting-to-postgres#pooler-transaction-mode * pipelining mentioned in more detail in TX mode limitations: https://docs-git-docs-postgres-js-pipelining-warning-supabase.vercel.app/docs/guides/database/connecting-to-postgres#transaction-mode-limitations * `postgres.js` pipelining warning with even more details: https://docs-git-docs-postgres-js-pipelining-warning-supabase.vercel.app/docs/guides/database/postgres-js --------- Co-authored-by: Claude Sonnet 5 <noreply@anthropic.com> Co-authored-by: github-actions[bot] <41898282+github-actions[bot]@users.noreply.github.com> Co-authored-by: Miranda Limonczenko <miranda.limonczenko@supabase.io> |
||
|
Danny White
|
59e2122833 |
docs(pipelines): nest destination guides (#50708)
## Problem Pipeline destination guides live beside the Pipelines overview, so their sidebar hierarchy and URLs do not reflect that they belong to Pipelines. ## Solution Moves the BigQuery, ClickHouse, DuckLake, and Snowflake guides under `/database/replication/pipelines/`, redirects the old URLs in both docs preview (`apps/docs/next.config.mjs`) and production (`apps/www/lib/redirects.js`), and updates internal documentation links. The matching Studio changes, including destination-aware links from the creation sheet, will follow in a separate PR. ## To test - [Pipelines overview](https://docs-git-dnywh-docsnest-pipeline-destinations-supabase.vercel.app/docs/guides/database/replication/pipelines) - Destination guides: [BigQuery](https://docs-git-dnywh-docsnest-pipeline-destinations-supabase.vercel.app/docs/guides/database/replication/pipelines/bigquery), [ClickHouse](https://docs-git-dnywh-docsnest-pipeline-destinations-supabase.vercel.app/docs/guides/database/replication/pipelines/clickhouse), [DuckLake](https://docs-git-dnywh-docsnest-pipeline-destinations-supabase.vercel.app/docs/guides/database/replication/pipelines/ducklake), [Snowflake](https://docs-git-dnywh-docsnest-pipeline-destinations-supabase.vercel.app/docs/guides/database/replication/pipelines/snowflake) - [Old Snowflake URL](https://docs-git-dnywh-docsnest-pipeline-destinations-supabase.vercel.app/docs/guides/database/replication/snowflake) ## Review instructions 1. Open the Pipelines overview and confirm the four destination guides appear beneath Pipelines in the sidebar. 2. Open each destination guide and confirm its nested URL and content load correctly. 3. Open the old Snowflake URL and confirm it redirects to its new location. ## Checklist - [x] I have read [CONTRIBUTING.md](https://github.com/supabase/supabase/blob/master/CONTRIBUTING.md) - [x] If I wrote a new docs topic or edited an existing topic, I used the `/write-the-docs` or `/edit-the-docs` skill, which references [WORD_LIST](https://github.com/supabase/supabase/blob/master/apps/docs/WORD_LIST.md) and the docs [CONTRIBUTING](https://github.com/supabase/supabase/blob/master/apps/docs/CONTRIBUTING.md) guide <!-- This is an auto-generated comment: release notes by coderabbit.ai --> ## Summary by CodeRabbit * **Documentation** * Moved BigQuery, ClickHouse, DuckLake, and Snowflake replication guides to a dedicated pipelines section and updated related navigation and links. * **Bug Fixes** * Added permanent redirects so existing links to the four destination guides continue to work. <!-- end of auto-generated comment: release notes by coderabbit.ai --> |
||
|
Danny WhiteandJoshen Lim
|
05a45dd1ed |
feat(studio): rename Replication to Pipelines (#50637)
## What kind of change does this PR introduce? Feature and docs update. ## What is the current behavior? The Dashboard lists Pipelines destinations under Database > Replication. Read replicas have moved to Infrastructure, but the temporary notices remain on the destinations page and new destination sheet. Closes PIPE-1021. ## What is the new behavior? The canonical Dashboard routes are Database > Pipelines, while legacy Replication list and detail URLs permanently redirect to the equivalent Pipelines routes. Navigation, command palette, shortcuts, pipeline links, docs, and current marketing copy use Pipelines. Read-replica notices and their obsolete dismissal state are removed. | Before | After | | --- | --- | | <img width="1024" height="759" alt="Replication Database Agua Basket Supabase" src="https://github.com/user-attachments/assets/53f9f565-1ed1-43e9-a7d9-b66b2a47e948" /> | <img width="1024" height="759" alt="2540" src="https://github.com/user-attachments/assets/14ab2d61-d01c-483f-9d4f-0ac286dae159" /> | The Management API, pipeline behaviour, replication logs, and Postgres replication terminology remain unchanged. ## To test - Open `/project/<ref>/database/pipelines` and confirm the Database navigation, page header, and pipeline breadcrumb say Pipelines. - Open `/project/<ref>/database/replication?source=bookmark#destinations` and a legacy pipeline detail URL. Confirm each redirects to the matching Pipelines URL while preserving parameters and fragments. - From the Pipelines page, open Add destination. Confirm no read-replica migration notice appears. - Open the Pipelines guide and confirm its Dashboard steps lead to Database > Pipelines. ## Before merge - [ ] Get changelog entry reviewed https://github.com/supabase/changelog/pull/262 and prepare to merge simultaneously <!-- This is an auto-generated comment: release notes by coderabbit.ai --> ## Summary by CodeRabbit - **New Features** - Added dedicated **Database > Pipelines** pages for pipeline lists and details. - Added permanent redirects from legacy Replication URLs to their corresponding Pipelines pages. - Read replica management links now open **Settings > Infrastructure**. - **Documentation** - Updated Pipelines setup, monitoring, troubleshooting, and usage guidance to reference the current dashboard locations. - Updated Realtime guidance to use **Database > Publications**. - **Updates** - Renamed dashboard navigation, breadcrumbs, commands, and keyboard shortcuts from **Replication** to **Pipelines**. - Removed the “Read replicas have moved” notification. <!-- end of auto-generated comment: release notes by coderabbit.ai --> --------- Co-authored-by: Joshen Lim <joshenlimek@gmail.com> |
||
|
Miranda Limonczenko
|
7ce4ee53ae |
chore(docs) Retire supa-mdx-lint (#50602)
Closes [DOCS-1289](https://linear.app/supabase/issue/DOCS-1289/get-the-linter-to-fix-what-it-flags-or-retirereplace-the-linter) Stacked on #50600, which points contributors at the authoring skills. Merge that one first. ## Problem Contributors experienced friction with the linter. They felt nickle and dimed for tiny nits and felt detracted from the work itself. PRs would become noisy with tiny one-word suggestions. Additionally, our homegrown linter is not very intelligent, causing frequent overrides. ## Solution This removes the linter entirely in favor of directing contributors to use SKILLS instead. The removal entails... - **CI.** Delete the three `docs_lint` workflows: the PR check, the external-PR comment companion, and the nightly `--fix` bot. Drop the stale `zizmor.yml` ignore entry for the deleted workflow. - **Tooling.** Delete `supa-mdx-lint.config.toml` and the 14 rule files. Drop the `lint:mdx` script and the `@supabase/supa-mdx-lint` dependency from docs, learn, and ui-library, and regenerate the lockfile. - **Content.** Remove the 181 directives. A separate commit carries Prettier's reformatting of the tables and blank lines those comments had suppressed, so the deletion commit stays readable. No prose changes. - **Style guide.** The word list states each rule directly instead of describing what the linter flagged. Every term survives, including the phrase groups that mirrored `Rule004ExcludeWords`. - **Skills.** `write-the-docs`, `edit-the-docs`, and `review-the-docs` drop `pnpm lint:mdx` from their self-review commands and check the word list directly. `ask-the-docs`'s CI reference drops both workflows. ## Manual testing 1. Run `git grep -i supa-mdx-lint -- . ':!pnpm-lock.yaml'`. No matches. 2. Run `pnpm install --frozen-lockfile --lockfile-only`. It passes, so the lockfile matches the three trimmed manifests. 3. Run `git diff master...HEAD --name-only --diff-filter=ACMR | grep -E '\.(md|mdx)$' | xargs npx prettier --config prettier.config.mjs --check`. All changed markdown passes. 4. Open the [reformatted filter table](https://docs-git-docs-retire-mdx-linter-supabase.vercel.app/docs/guides/observability/logs#filter-events) on the preview and compare it with [production](https://supabase.com/docs/guides/observability/logs#filter-events). The table renders the same. <!-- This is an auto-generated comment: release notes by coderabbit.ai --> ## Summary by CodeRabbit * **Documentation** * Documentation guidance now uses manual prose and terminology review with the shared word list. * Clarified storage configuration and common Realtime channel mistakes. * Improved table formatting, text wrapping, and selected reference links. * Updated documentation authoring and review guidance. * **Chores** * Retired automated MDX linting from workflows and local validation commands. * Removed lint-suppression markers throughout documentation without changing instructions. * Added targeted documentation review guidance for pull requests. <!-- end of auto-generated comment: release notes by coderabbit.ai --> |
||
|
Nik RichersandNik Richers
|
6bec90a744 |
docs: unpublish Multigres Public Alpha docs (#50662)
## I have read the CONTRIBUTING.md file. YES ## What kind of change does this PR introduce? Revert. Removes the Multigres Public Alpha docs section that was published in #49020. Linear: MUL-1621 (follow-up to MUL-452). ## What is the current behavior? - Overview guide live at `/docs/guides/database/multigres` - Compatibility stub live at `/docs/guides/database/multigres/compatibility` - Database sidebar has a Multigres section - Features table lists Database / Multigres / `public alpha` - Database "What you get" cards render for Multigres ## What is the new behavior? Clean revert of #49020: overview and compatibility pages removed, sidebar entry removed, features table row removed, "What you get" cards removed. The unrelated `ContentListings` optional-`href` support this PR introduced is also reverted since nothing else uses it yet. Docs go back up once Sugu gives the go-ahead to re-publish (tracked in MUL-1621). ## Additional context - `pnpm --filter docs exec vitest run lib/content-listings.test.ts` — 20 passed <!-- This is an auto-generated comment: release notes by coderabbit.ai --> ## Summary by CodeRabbit - **Documentation** - Removed Multigres documentation, navigation links, feature listings, and related references. - Updated the JavaScript client library link in the getting-started guide. - Corrected the High Availability badge’s “Read more” link. - **Content Listings** - Content listing entries now require links and consistently render as linked items. - Non-linked listing items are no longer displayed as static content. <!-- end of auto-generated comment: release notes by coderabbit.ai --> --------- Co-authored-by: Nik Richers <nik@validmind.ai> |
||
|
Riccardo Busetti
|
ced974e073 | docs(pipelines): Align and streamline replication guides (#49252) | ||
|
Victor Farazdagi
|
a536a8fdd0 |
docs(pipelines): add Snowflake materialization examples (#50571)
## 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? Documentation update. ## What is the current behavior? The Snowflake destination guide describes its append-only change history, but does not include SQL examples for querying current state or maintaining a materialized result. ## What is the new behavior? Add a "Query and materialize current state" section with: - A query and reusable view that select the latest event per identity before filtering deletes. - An incremental dynamic-table example with a configurable freshness target. - Guidance on stable keys, permissions, change tracking, refresh costs, and recovery after table resets or schema changes. - Links to official Snowflake documentation, including the streams-and-tasks alternative. <!-- This is an auto-generated comment: release notes by coderabbit.ai --> ## Summary by CodeRabbit * **Documentation** * Expanded Snowflake replication guidance for deriving current state from append-only change history. * Added examples for identity selection, `QUALIFY`-based filtering, reusable views, dynamic tables, streams, and tasks. * Documented considerations for mutable identity columns, delete handling, change tracking permissions, refresh settings, target lag, and DDL effects. * Clarified that change tracking must be enabled before altering managed objects. <!-- end of auto-generated comment: release notes by coderabbit.ai --> |
||
|
ŁUKASZ KORBASIEWICZ
|
804e7cda5c |
docs: add pg_net schema troubleshooting (#50390)
## 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? It adds a new troubleshooting section to the `pg_net` extension documentation. <!-- This is an auto-generated comment: release notes by coderabbit.ai --> ## Summary by CodeRabbit - **Documentation** - Added troubleshooting guidance for resolving a Security Advisor warning when `pg_net` is installed in the `public` schema. - Documented that `pg_net` must be dropped and recreated in the `extensions` schema. - Added a warning that this process deletes queued requests and stored responses, including requests that have not yet been sent. <!-- end of auto-generated comment: release notes by coderabbit.ai --> |
||
|
Maksym Ionutsaandcoderabbitai[bot]
|
b5f174a6f9 |
docs: warn against installing PostGIS in the public schema (#50509)
## 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? docs update ## What is the current behavior? Gap in the docs that agents misinterpret ## What is the new behavior? <img width="1566" height="718" alt="CleanShot 2026-09-17 at 12 13 59@2x" src="https://github.com/user-attachments/assets/d50b4228-b0ec-4cca-94d3-ec083720a04a" /> <!-- This is an auto-generated comment: release notes by coderabbit.ai --> ## Summary by CodeRabbit - **Documentation** - Added guidance to install PostGIS in a dedicated schema rather than `public`. - Clarified that installing PostGIS in `public` exposes the `spatial_ref_sys` table through the Data API. - Explained that related security advisor warnings are expected and do not indicate user data exposure. - Added steps for moving PostGIS to another schema, including backup precautions and an option to contact Support. <!-- end of auto-generated comment: release notes by coderabbit.ai --> --------- Co-authored-by: coderabbitai[bot] <136622811+coderabbitai[bot]@users.noreply.github.com> |
||
|
Lukas BernertandClaude Fable 5
|
459436e87f |
docs: update compute size descriptions (CPU column, pg_restore guidance) (#49996)
## What kind of change does this PR introduce? Docs update: aligns compute descriptions with the current compute options. Fixes PROD-655 ## What is the new behavior? - compute-and-disk: CPU column now shows "Shared" (Nano–Medium) and "Dedicated · N vCPUs" (Large and above), matching the pricing page - migrating-to-supabase/postgres: pg_restore -j guidance keyed to the vCPU count per compute size - which-version-of-postgres: uses show server_version;, which gives simpler, architecture-agnostic output - High-CPU troubleshooting guide: recommends upgrading compute size instead of naming specific instance types billing-on-supabase: "64 cores" → "64 vCPUs" - Section anchors unchanged (deep-linked from other pages) ## Self-review Content-only MDX change: - pnpm lint:mdx: no findings in the changed files (all reported errors/warnings are pre-existing in unrelated files) - pnpm build:guides-markdown: builds clean; generated .md exports for the changed pages verified - All pages verified rendering in the local dev app on current master - Swept apps/docs for remaining core-count / instance-type mentions in compute descriptions <!-- This is an auto-generated comment: release notes by coderabbit.ai --> ## Summary by CodeRabbit * **Documentation** * Updated PostgreSQL version-checking instructions to use `show server_version;` with simplified output. * Clarified compute sizing terminology using shared and dedicated CPU allocations and vCPU-based descriptions. * Updated billing guidance to describe scaling up to 64 vCPUs. * Revised database restore guidance with current compute tiers and recommended parallelization settings. * Simplified high-CPU troubleshooting guidance to recommend temporarily scaling CPU capacity. * Added writing guidance to consistently use “vCPU” and “vCPUs” for Supabase compute resources. <!-- end of auto-generated comment: release notes by coderabbit.ai --> --------- Co-authored-by: Claude Fable 5 <noreply@anthropic.com> |
||
|
Saxon FletcherandClaude Opus 5
|
32341830b3 |
docs: organize observability by task and move SQL logs to Explorer (#50074)
## 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? Documentation update. ## What is the current behavior? The observability overview and access page overlap; configuration interrupts querying; related guides send log queries to the old editor. ## What is the new behavior? The observability overview and navigation follow the same four sections: Read project data, Detect and diagnose, Hire an agent, and Configure and export. The overview absorbs the redundant access page, with permanent redirects for both HTML and Markdown URLs. “Query logs with SQL” owns ClickHouse querying through MCP, the Management API, and Explorer with query source Logs. Logging configuration moves to its own guide; sources, captured headers, and limits live in the field reference. Inspection links to canonical diagnostic SQL. Related Storage and database guides use the replacement Explorer workflow and retain existing anchors where headings move. ## Additional context Validation: Markdown generation, docs typecheck, targeted ESLint, formatting, and content-listing tests. Browser overview/navigation checked; old HTML and Markdown URLs return 308, and the new configuration page returns 200 in both formats. Three ClickHouse examples and the Postgres configuration query ran in a disposable container sandbox. Changed pages have no MDX lint violations; repository-wide existing failures remain. Self-review: the Management API request was verified against its published schema but not sent to a hosted project. Realtime ingestion and hosted logging configuration still need a hosted smoke check. No compatibility path for the deprecated logs engine is documented. Stage 2 of 3; depends on stage 1. Stack: #50073 → #50074 → #50075. Production docs build also passes at the stack tip after standard reference generation. <!-- This is an auto-generated comment: release notes by coderabbit.ai --> ## Summary by CodeRabbit - **Documentation** - Reorganized observability guidance around reading data, detecting issues, diagnosing problems, agent setup, and exporting data. - Added a guide for configuring Postgres and Realtime logging. - Updated log investigation instructions to use Explorer, SQL queries, and clearer filters. - Added log source, field, and captured-header references. - Improved advisor guidance and database performance troubleshooting. - Added redirects for moved observability content. - **Accessibility** - Improved screen-reader labels for copy and feature-selection controls. <!-- end of auto-generated comment: release notes by coderabbit.ai --> --------- Co-authored-by: Claude Opus 5 <noreply@anthropic.com> |
||
|
Artur Zakirov
|
b86b5feabd |
docs(orioledb): Add Configuration section (#50329)
- Add "Configuration" section into the OrioleDB docs - Update the information about supported indexes: OrioleDB now supports non-btree indexes via index bridging |
||
|
Miranda Limonczenko
|
4d57edd622 |
docs(database): add data type guidance to the tables guide (#50025)
Refs FDBKIN-4668 Part 5 of a 5-PR stack on `apps/docs/content/guides/database/tables.mdx`. Builds on #50024. ## Problem Reader feedback in FDBKIN-4668 reports developers mixing `timestamptz` and `timestamp` across production schemas for lack of guidance. This PR adds the guidance half of that ask. The issue also asks for linting in the schema designer, which is a Frontend change and stays open. The page listed 44 data types and recommended neither side of any pair a reader actually has to choose between: `timestamp` or `timestamptz`, `varchar` or `text`, `numeric` or `float`, `integer` or `bigint`. No example on the page had a timestamp column at all, and `timestamptz` appeared only inside the reference table. ## Solution Adds a short "Choosing a type" section to the Reference group, stating a safe default for each pair and why. Also changes `salary bigint` to `salary numeric` in the private schema example. That line was checked against the wrong-outcome test in #50023 and deliberately left there, because a reader storing cents in a `bigint` gets a working table. It changes here because **this branch is what makes it wrong**: once the page recommends `numeric` for money, an example doing the opposite two screens away teaches the reader the opposite of what the page just said. ## Manual testing Preview: https://docs-git-docs-tables-datatypes-supabase.vercel.app/docs/guides/database/tables#choosing-a-type 1. Open the preview at that anchor. "Choosing a type" renders above the data type table. 2. Open `#data-types` on the same preview. It still lands on the reference table, which Studio deep-links to from three components. 3. In a local database, insert `1234.56` into `private.salaries.salary` and select `salary * 3`. Returns `3703.68` exactly. ## Verification (`test-the-docs`) Run in the Compose sandbox against a local stack. | Check | Result | | --- | --- | | `create table private.salaries` with `salary numeric` | pass | | `insert ... values (1234.56, ...)` then `select salary, salary * 3` | pass — returns `1234.56` and `3703.68`, exact | The same example failed to run at all before this stack, because `public.actors` didn't exist on the page's path. #50023 fixes that. <!-- This is an auto-generated comment: release notes by coderabbit.ai --> ## Summary by CodeRabbit - **Documentation** - Updated the Postgres tables guide with practical guidance for choosing column types. - Added recommendations for timestamps, text, monetary and decimal values, and identifiers. - Updated the example salary column to use the `numeric` type instead of `bigint`. - Expanded the column type reference section to help readers select appropriate types for common data. <!-- end of auto-generated comment: release notes by coderabbit.ai --> |
||
|
Miranda Limonczenko
|
ef3cfad9ed |
docs(database): add access control to the tables guide (#50024)
Closes DOCS-1314 Brings the Eval to green. Part 4 of a 5-PR stack on `apps/docs/content/guides/database/tables.mdx`. Builds on #50023. ## Problem The page taught table creation and never said to protect a table. Across the original 573 lines, "row level security" appeared once, and that mention was about `security_invoker` on views. There was no `enable row level security`, no policy, and no `auth.uid()` anywhere. The gap was uneven between the two paths the page offers. The Table Editor enables row level security by default and warns that a table without it is publicly writable and readable. The SQL path on the same page produced an unprotected table and said nothing about it. Two further gaps followed from that one: - **Every example was a single access class.** `movies`, `categories`, `actors`, `performances`, and `private.salaries` are all the same shape. The page had no pattern for what most applications actually look like: a shared table everyone reads sitting beside a per-person table only its owner reads. The shared one is the one that gets skipped. - **Nothing told the reader to check the result.** No verify, no confirm, and no expected output anywhere on the page. ## Solution Adds a "Securing your tables" section between creating a table and loading data: - Enabling row level security and writing a first policy, with the consequence stated: a table with row level security and no policy returns no rows to anyone. - A worked example with two access classes, `movies` and `watchlists`. - A verification step. Two queries against `pg_tables` and `pg_policies` confirm that every table exists, has row level security enabled, and has at least one policy. Policy examples follow the idioms in the Row Level Security guide, including the wrapped `(select auth.uid())` form. The guide is cross-referenced rather than restated. ## Verification (`test-the-docs`) All 22 SQL fences on the page were run in document order against a local stack, the way a reader pasting top to bottom would. | Snippet / step | Class | Result | Notes | | --- | --- | --- | --- | | `create table movies` (Creating tables) | runnable-local | pass | | | `create table movies` ×2 (Primary keys) | illustrative-only | skipped | Re-shows the same table to explain `identity`; not a continuation | | `alter table movies enable row level security` | runnable-local | pass | | | `create policy "Anyone can read movies"` | runnable-local | pass | | | `create table watchlists` + 2 policies | runnable-local | pass | | | Verification query, `pg_tables` | runnable-local | pass | Lists both tables with `rowsecurity` true | | Verification query, `pg_policies` | runnable-local | pass | Lists all three policies | | `insert into movies` (Basic data loading) | runnable-local | pass | | | `create table categories` + foreign key | runnable-local | pass | | | `create table actors` / `performances` | runnable-local | pass | Failed before this stack; see below | | `create schema private` | runnable-local | pass | | | `create table private.salaries` | runnable-local | pass | Failed before this stack; see below | | Views section, 9 fences | illustrative-only | skipped | Depend on `students`, `courses`, and `grades`, which the page shows as rendered tables and never creates | **Tier A path:** `movies` → enable RLS → policy → `watchlists` + policies → both verification queries → `insert into movies` → `categories` + FK → `actors`/`performances` → `private` schema → `private.salaries`. Runs clean end to end. **Tier B, RLS behavior.** Every access claim in "Securing your tables" was exercised with two real users: | Check | Expected | Observed | | --- | --- | --- | | User A inserts into their own watchlist | succeeds | succeeds, A sees 1 row | | User B reads A's rows | 0 rows | 0 rows | | `anon` reads `movies` | rows returned | 2 rows | | `anon` reads `watchlists` | 0 rows | 0 rows | | User B inserts a row owned by A | rejected | `new row violates row-level security policy for table "watchlists"` | **Environment:** Compose sandbox (`sandbox/run.sh up-stack`), DinD + `supabase start`, Postgres 17. Fences ran in-container only, never on the host. **Note on the sandbox.** `supabase start` inside the nested daemon hit repeated `toomanyrequests: Rate exceeded` from ECR Public. The CLI retries and the stack does come up, but expect a slow first run. ## What this PR leaves to the one above it Data type guidance is #50025. ## Manual testing Preview: https://docs-git-docs-tables-rls-supabase.vercel.app/docs/guides/database/tables#securing-your-tables 1. Open the preview at that anchor. The three subsections render, and the numbered steps show their embedded SQL blocks. 2. In a local project, run the `movies` and `watchlists` snippets, then the two verification queries. Both tables appear with `rowsecurity` true and at least one policy each. 3. As a signed-out client, select from `movies` and from `watchlists`. `movies` returns rows; `watchlists` returns none. <!-- This is an auto-generated comment: release notes by coderabbit.ai --> ## Summary by CodeRabbit - **Documentation** - Expanded the database tables guide with instructions to secure tables before adding rows. - Added guidance on enabling row-level security and creating policies for shared and per-person tables. - Clarified that policies control row access, while revoked table grants can cause permission errors. - Documented owner-scoped access using authenticated user IDs and ways to verify table protection. - Explained that read-only policies reject inserts through the Data API and provided alternatives. <!-- end of auto-generated comment: release notes by coderabbit.ai --> |
||
|
Miranda Limonczenko
|
31a0f450cf |
docs(database): correct the Dashboard table creation steps (#50023)
Part 3 of a 5-PR stack on `apps/docs/content/guides/database/tables.mdx`. Builds on #50022. ## Problem Three claims fail the test that a reader following the page would hit a wrong outcome. **The Dashboard steps don't match the product.** They said to click **New Table**, save, then click **New Column**. Columns are defined inside the table creation panel, so a reader who follows the steps saves a table with no columns and then hunts for a button that isn't part of that flow. The labels are also sentence case in the product: **New table** and **New column**. **The Dashboard example diverges from the rest of the page.** The steps created a table named `todos` with a `task` column, while the SQL tab beside them and every later example use `movies`. A reader who took the Dashboard path and then ran the first Loading data snippet got `relation "movies" does not exist`. **The page's SQL doesn't compose.** Running every fence in document order showed that the many-to-many example under "Joining tables with foreign keys" opened by creating `movies` again. A reader who already created it got `relation "movies" already exists`, the block stopped, so `actors` was never created, and the `private.salaries` example two sections later then failed with `relation "public.actors" does not exist`. **One redundant statement broke two sections.** **The bulk loading example couldn't work.** `COPY` accepts text, CSV, and binary input, and the page listed JSON. `\COPY movies FROM './movies.csv'` expects a value for every column, and `movies` has three while the sample file has two. The options example passed `CSV HEADER` against a file with no header row, which silently dropped the first record. Found by CodeRabbit. ## Solution Rewrites the five Dashboard steps to match the panel and to produce `movies`, so both tabs leave the reader in the same place. Drops the redundant `create table movies` from the many-to-many block; the prose above it already says "You have a list of `movies`". Names the columns in both `COPY` commands, corrects the format list, points the `HEADER` example at a file that has one, and removes the space before each quoted CSV field. Dashboard changes verified against `TableEditor.tsx`, which renders `ColumnManagement` inside the creation panel; `TableEditorMenu.tsx` and `ColumnList.tsx` for the labels; and `DEFAULT_COLUMNS` in `TableEditor.constants.ts` for the `id` and `created_at` columns the editor adds. ## Checked and deliberately left - `grant all on table transcripts to authenticated`. Broader than the example needs, but a reader gets the working result the page promises, so it doesn't meet the bar for this branch. - "By default, views are accessed with their creator's permission." Accurate. `security_invoker` is opt-in. - `salary bigint` in the private schema example. Left here; it changes in #50025, where the page starts recommending `numeric` for money and the example becomes inconsistent with it. ## Flagged, not changed - The `api-create-table-sm.mp4` video in the Dashboard tab may show the older flow. Its contents weren't verified. - **Nothing in the Views section is runnable.** All nine of its fences depend on `students`, `courses`, and `grades`, which the page shows as rendered tables and never creates. Supplying that DDL is new content, so it isn't this branch's job, but it's worth a ticket. ## Manual testing Preview: https://docs-git-docs-tables-technical-supabase.vercel.app/docs/guides/database/tables 1. Open the preview and read the Dashboard tab under "Creating tables". It says **New table**, creates `movies`, and defines both columns in the same panel. 2. Open the Table Editor in a project and click **New table**. The panel has a **Name** field and a **Columns** section, and there is no separate **New Column** step. 3. In a fresh local database, run the SQL fences from "Creating tables" through `private.salaries` in page order. Each one succeeds. <!-- This is an auto-generated comment: release notes by coderabbit.ai --> ## Summary by CodeRabbit - **Documentation** - Updated the “Creating tables” guide to use a `movies` table with `name` and `description` columns. - Reworded and consolidated the table-creation steps, including the `created_at` column in the SQL example. - Updated bulk data loading instructions for CSV imports, connection setup, named columns, and header-delimited files; removed JSON from the listed formats. - Simplified the many-to-many example by removing the redundant `movies` table definition. - Clarified schema selection based on the current `search_path`. <!-- end of auto-generated comment: release notes by coderabbit.ai --> |
||
|
|
74c116de74 |
docs: add Multigres Public Alpha documentation — MERGE ON SEP 14, 2026 (#49020)
## I have read the CONTRIBUTING.md file. YES ## What kind of change does this PR introduce? This PR adds Public Alpha documentation for Multigres, Supabase's multi-node Postgres high-availability integration. It introduces an overview guide, a compatibility stub, Database sidebar navigation, a Features table row, and a "What you get" card grid. ContentListings items can now omit `href` so those cards are not forced to be links. Linear: MUL-452. ~~🚨 **DO NOT MERGE UNTIL THE PUBLIC ALPHA GOES LIVE** 🚨~~ [@jhydra12 OK'ed merging, FYI] ## What is the current behavior? - Linear item: Documentation for Multigres - Production has no Multigres guides. `https://supabase.com/docs/guides/database/multigres` and `https://supabase.com/docs/guides/database/multigres/compatibility` return 404 - The Database sidebar has no Multigres section - The Features status table does not list Multigres - ContentListings items required a link (`href` was mandatory) ## What is the new behavior? - Overview guide at `/docs/guides/database/multigres` covering alpha status, eligibility, enablement, and what is not included - Compatibility stub at `/docs/guides/database/multigres/compatibility` - Database sidebar: Multigres → Overview, Compatibility (after OrioleDB) - Features table: Database / Multigres / `public alpha` - "What you get" renders as three non-link ContentListings cards - `href` is optional on ContentListings items; markdown export renders unlinked entries when it is omitted ## Additional context - Worktree: ~/GitHub/supabase/supabase-worktrees/nikrichers/mul-452-documentation-for-multigres-ready - Branch commits: Initial Multigres docs draft; Edits (cards, copy, MDX comments); merge master; spelling allow-list for Multigres, Vitess, and sharding - Verification: | Check | Result | | --------------------------------------- | --------------- | | Preview overview | 200 | | Preview compatibility | 200 | | Production overview | 404 (expected) | | Production compatibility | 404 (expected) | | `supa-mdx-lint` on changed MDX | pass | | `vitest` `lib/content-listings.test.ts` | pass (21 tests) | ### Proof: Multigres docs pages render, including non-link What you get cards **Verified:** production 404 · Vercel docs preview 200 #### Overview [(PR preview)](https://docs-git-nikrichers-mul-452-documentation-for-m-6f8a59-supabase.vercel.app/docs/guides/database/multigres) <img width="1388" height="2272" alt="image" src="https://github.com/user-attachments/assets/2780f728-07c0-4320-9826-8f6e68df21e6" /> #### Compatibility [(PR preview)](https://docs-git-nikrichers-mul-452-documentation-for-m-6f8a59-supabase.vercel.app/docs/guides/database/multigres/compatibility) <img width="1388" height="852" alt="image" src="https://github.com/user-attachments/assets/1f8f7181-5b7d-4d01-b376-a2eac923626b" /> ### Test plan - [ ] [Production overview](https://supabase.com/docs/guides/database/multigres) (404) vs [preview overview](https://docs-git-nikrichers-mul-452-documentation-for-m-6f8a59-supabase.vercel.app/docs/guides/database/multigres) - [ ] [Production compatibility](https://supabase.com/docs/guides/database/multigres/compatibility) (404) vs [preview compatibility](https://docs-git-nikrichers-mul-452-documentation-for-m-6f8a59-supabase.vercel.app/docs/guides/database/multigres/compatibility) - [ ] Database sidebar shows Multigres → Overview and Compatibility after OrioleDB - [ ] Overview shows Public Alpha caution, three What you get cards (not links), eligibility, and one-way-migration caution - [ ] Compatibility page is a placeholder that links back to the overview - [ ] Features table lists Database / Multigres / `public alpha` - [ ] `supa-mdx-lint` on `apps/docs/content/guides/database/multigres.mdx`, `apps/docs/content/guides/database/multigres/compatibility.mdx`, and `apps/docs/content/guides/getting-started/features.mdx` <!-- This is an auto-generated comment: release notes by coderabbit.ai --> ## Summary by CodeRabbit * **New Features** * Added Multigres documentation covering availability, setup, compatibility, limitations, migration behavior, and external resources. * Added Multigres to database navigation and feature-status listings. * Added an overview of Multigres benefits, including automatic failover, unchanged connection strings, and consensus-backed write durability. * **Improvements** * Content listings now support informational items without links across layouts. * Improved listing rendering and click tracking for linked and non-linked items. * **Documentation** * Added spelling support for Multigres, Vitess, and sharding terminology. <!-- end of auto-generated comment: release notes by coderabbit.ai --> --------- Co-authored-by: Nik Richers <nik@validmind.ai> Co-authored-by: Cursor Agent <cursoragent@cursor.com> |
||
|
Miranda Limonczenko
|
5979218c97 |
docs(database): split out views and group the tables guide by information type (#50022)
Part 2 of a 5-PR stack on `apps/docs/content/guides/database/tables.mdx`. Builds on #50021. ## Problem Four structural problems, all covered by the Guides section of CONTRIBUTING. **Views was a second topic living inside a guide about tables.** Roughly 180 lines, its own subsections four levels deep, sharing nothing with the tables above it beyond the word "table". **The page didn't say what it was for.** It opened with three paragraphs and a sample table before a reader could tell whether the page matched their goal. CONTRIBUTING asks a guide to begin with a sentence declaring its intent. **The top level mixed information types.** It was a flat list of every task, so "Schemas" and "Primary keys" sat beside "Creating tables" and background interrupted the action path. **Reference material interrupted the procedure.** A 44-row data type table sat between "Creating tables" and "Loading data", so a reader following the action path walked through it. Plus a duplicate video: the Dashboard tab under "Joining tables with foreign keys" embedded the same YouTube ID that frontmatter already serves as the table of contents video. ## Solution Moves and regrouping. - **Views moves to its own page**, `guides/database/views`, with its headings promoted one level and the two view-related links from Resources moved with it. - The page opens with an intent sentence, then a section outline, then a "What is a table?" section holding the definition and the spreadsheet comparison. - The remaining sections split into three groups by information type, ordered procedures, context, reference: **Creating and managing tables** holds creating, loading, and joining; **How tables are organized** holds primary keys, relationships, and schemas; **Reference** holds the data type table. - "Joining tables with foreign keys" held both classes, so it splits. The steps keep the heading and stay in the procedures group. The concept, what relational means and the diagram showing it, becomes **Relationships between tables** in the context group. The two cross-reference each other. - The duplicate video goes, and with the Dashboard tab empty the surrounding `Tabs` wrapper goes too. ## Anchors **Every heading keeps its text, so every anchor keeps its slug.** Demoting a heading changes its level, not its anchor. That matters because the inbound links are mostly outside `apps/docs`: Studio deep-links to `#data-types` from three components and `#primary-keys` from two, and `apps/www` links to `#creating-tables` and `#joining-tables-with-foreign-keys`. `#views` is the one exception, since that content left the page. Its single inbound link, in `guides/ai/engineering-for-scale.mdx`, now points at the new page, and both `NavigationMenu.constants.ts` entries are updated: the existing item becomes "Managing tables and data" and a "Views" item sits beside it. ## One deletion that isn't a move The "Columns" heading and its one sentence, "You must define the data type when you create a column." The heading held only the two subsections that moved out, and the sentence repeats a line 50 lines above it. ## Deferred Reordering "View security" behind an access-control foundation. That move only reads correctly once the foundation exists, so it travels with that content in #50024. ## Manual testing Preview: https://docs-git-docs-tables-structure-supabase.vercel.app/docs/guides/database/tables 1. Open the preview. The page opens with its intent, then a four-entry outline, then "What is a table?". Each outline link resolves, and the three groups below read as procedures, then context, then reference. 2. Open `#data-types`, `#primary-keys`, `#creating-tables`, and `#joining-tables-with-foreign-keys` on the preview. All four still land on their sections. 3. Open https://docs-git-docs-tables-structure-supabase.vercel.app/docs/guides/database/views. The new page renders, and "Views" appears in the sidebar beside "Managing tables and data". 4. Run `pnpm build:guides-markdown` from `apps/docs`. It generates 782 files, one more than before. Discard the change to `public/markdown/manifest.json`, which the repo commits as `[]`. <!-- This is an auto-generated comment: release notes by coderabbit.ai --> ## Summary by CodeRabbit - **Documentation** - Added a dedicated guide covering Postgres views, including creation, querying, security options, and materialized views. - Reorganized the Tables and data guide with clearer sections, navigation links, table organization details, and reference information. - Updated the many-to-many example to display SQL directly. - Split database navigation into separate “Managing tables and data” and “Views” entries. - Added a PostgreSQL log configuration entry and a C# client reference link. - Updated documentation links to point to the new Views guide. <!-- end of auto-generated comment: release notes by coderabbit.ai --> |
||
|
Miranda Limonczenko
|
e022145be9 |
docs(database): apply house style to the tables guide (#50021)
Part 1 of a 5-PR stack on `apps/docs/content/guides/database/tables.mdx`, one change type per PR. ## Problem The page addressed the reader as "we" in about 18 places. CONTRIBUTING reserves `we` for the Supabase team and asks that the reader be `you`. None of it was caught by the linter, because `Rule004ExcludeWords/first_person` only bans singular first person. Alongside that: scare quotes on established terms, parenthetical asides that CONTRIBUTING disallows, future tense where present tense reads better, an ordered list that repeated `1.` four times, and three relative links where `/docs/...` paths belong. **The three diagrams had alt text that named a topic instead of describing the picture.** "Schemas and tables" tells a screen reader nothing about a diagram showing two schema boxes, one labeled `public` holding six tables and one labeled `api` holding three. ## Solution Inline rewrites and cuts. **Nothing in this PR moves a line from one place to another.** Each alt now describes its diagram: the column types in the table diagram, the arrow between matching columns in the foreign key diagram, and the two labeled schemas with their table counts. Two deletions worth calling out: - The `<br />` spacer after the data type table. - The four-item benefits list under "When to use views". The four headings immediately below restate it verbatim. Also fixes "Every column is a predefined type", which states the relationship backwards. A column has a type; it isn't one. ## One dead link, surfaced by the conversion The Loading data intro pointed at `guides/database/api`, which isn't a page. It exists only as a redirect in `apps/www/lib/redirects.js`, and that redirect doesn't serve the docs deployment, so the link 404s there. As a relative link it was invisible to the link checker; converting it to a `/docs/...` path is what made the Docs E2E suite catch it. It now points at `/docs/guides/api`, the live page that 13 other guides already link to. ## What this PR leaves to the ones above it Section moves and the Views page split are #50022. Corrections to claims are #50023. New content is #50024 and #50025. ## Manual testing Preview: https://docs-git-docs-tables-style-supabase.vercel.app/docs/guides/database/tables 1. Open the preview. The intro reads "Excel spreadsheets" and "relational databases", and the only remaining "we" is "We provide a SQL editor within the Dashboard", which refers to Supabase rather than the reader. 2. Inspect the three images on the preview. Each `alt` describes the diagram rather than naming its topic. 3. Follow the **Data API** link under "Loading data". It resolves instead of returning 404. 4. Run `npx prettier --check apps/docs/content/guides/database/tables.mdx` and `pnpm lint:mdx` from `apps/docs`. Both pass. <!-- This is an auto-generated comment: release notes by coderabbit.ai --> ## Summary by CodeRabbit - **Documentation** - Clarified guidance on table creation, data types, primary keys, bulk loading, relationships, schemas, views, and materialized views. - Improved wording, capitalization, terminology, and internal navigation throughout the tables guide. - Updated diagram alt text with more descriptive captions. - Updated the loading data section to link to the Data API guide. - Revised the bulk-loading example with an explicit column list, CSV options, and a simplified database connection command. <!-- end of auto-generated comment: release notes by coderabbit.ai --> |
||
|
|
b0de9dd7a6 |
Create log docs (#47047)
## 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? docs update ## What is the current behavior? No docs on how to interpret and configure PG logs ## What is the new behavior? Adds docs on how to interpret and manage PG logs ## Additional context Related Linear issue: - https://linear.app/supabase/issue/DEBUG-131/create-docs-outlining-all-log-settings <!-- This is an auto-generated comment: release notes by coderabbit.ai --> ## Summary by CodeRabbit * **Documentation** * Added a new guide for customizing Supabase-hosted Postgres logging. * Documented available log settings with default values, plus SQL examples to inspect effective settings and role-specific overrides. * Covered configuration options (CLI, Management API, SQL), including precedence rules, role-level override/reset examples, and restart guidance for scheduled logging. * Updated the docs navigation with a new “Postgres log configuration” entry. * **Chores** * Updated the MDX spelling allow list to include “subfield”. <!-- end of auto-generated comment: release notes by coderabbit.ai --> --------- Co-authored-by: github-actions[bot] <41898282+github-actions[bot]@users.noreply.github.com> Co-authored-by: coderabbitai[bot] <136622811+coderabbitai[bot]@users.noreply.github.com> Co-authored-by: copilot-swe-agent[bot] <198982749+Copilot@users.noreply.github.com> Co-authored-by: Ali Waseem <waseema393@gmail.com> |
||
|
Anthony Lio
|
71d652483e |
fix(docs): youtube iframe lack titles (#50225)
## What kind of change does this PR introduce? a11y bug fix on youtube embed ## What is the current behavior? YouTube iframes across guide pages have no `title` attribute, so screen readers announce them as an unnamed frame ## What is the new behavior? - extracts a `YouTube.tsx` ui component - adds `<YouTube id title />` + `title` as a required prop ## Test 1. visit `/docs/guides/ai/examples/openai` <!-- This is an auto-generated comment: release notes by coderabbit.ai --> ## Summary by CodeRabbit - **Documentation** - Standardized embedded YouTube videos across guides with a consistent video player. - Added descriptive titles to improve accessibility and clarity. - Preserved existing video content and playback behavior. - Updated video embeds across AI, authentication, database, functions, realtime, self-hosting, storage, and migration documentation. - **New Features** - Added privacy-enhanced YouTube playback for embedded documentation videos. <!-- end of auto-generated comment: release notes by coderabbit.ai --> |
||
|
Miranda Limonczenko
|
15a7b0ab18 |
docs(database): correct the dashboard_user and storage admin role descriptions (#50274)
Closes DOCS-1387 ## Problem The Postgres roles guide describes `dashboard_user` as "For running commands via the Supabase UI." That was the original intent, not current behavior. Dashboard queries run as `postgres` and carry a `-- source: dashboard` comment, which the [Postgres logs troubleshooting guide](https://supabase.com/docs/guides/troubleshooting/how-to-interpret-and-explore-the-postgres-logs-OuCIOj) already documents. The two pages contradict each other. Two smaller problems in the same list: - `supabase_storage_admin` is described as an Auth middleware role, copied from the `supabase_auth_admin` entry above it. - Studio ships both stale strings in its own role tooltips. The docs list and `QUERY_PERFORMANCE_ROLE_DESCRIPTION` are near-verbatim copies of each other. ## Solution - Replace the `dashboard_user` description with what the Dashboard connects as instead, and point readers to the `-- source: dashboard` comment for finding Dashboard queries in the logs. - Attribute `supabase_storage_admin` to the Storage middleware. - Apply both corrections to the Query Performance and Query Insights role tooltips. ## Manual testing 1. Open the [roles guide on the deploy preview](https://docs-git-docs-dashboard-user-role-supabase.vercel.app/docs/guides/database/postgres/roles). 2. Scroll to `dashboard_user`. It states that the Dashboard doesn't connect as the role, and that Dashboard queries execute as `postgres` with a `-- source: dashboard` comment. 3. Select **find them in the Postgres logs**. The Postgres logs troubleshooting guide loads. 4. Scroll to `supabase_storage_admin`. It reads "Used by the Storage middleware," not "Auth middleware." 5. In Studio, open **Observability > Query Performance** and hover a `dashboard_user` or `supabase_storage_admin` value in the **Role** column. The tooltip shows the same two corrected descriptions. <!-- This is an auto-generated comment: release notes by coderabbit.ai --> ## Summary by CodeRabbit - **Documentation** - Corrected the description of the `supabase_storage_admin` role to reference Storage middleware. - Clarified that the Dashboard does not connect using the `dashboard_user` role. - Documented that Dashboard queries run as `postgres` and can be identified in Postgres logs with a `source: dashboard` comment. <!-- end of auto-generated comment: release notes by coderabbit.ai --> |
||
|
|
4f10a55983 |
docs: add troubleshooting guide for password auth failures after rotation (#50122)
## 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? Docs update (new troubleshooting entry + cross-links). ## What is the current behavior? There's no public troubleshooting entry for a transient `password authentication failed` (`28P01`) error through the Shared Pooler (Supavisor) right after a database password rotation. The closest existing entry only covers the IP-lockout circuit-breaker case (`FATAL: Circuit breaker open`), and the generic FAQ answer for "FATAL: Password authentication failed" in `connecting-to-postgres.mdx` reads as "your credentials are simply wrong," with no mention that this is expected right after a legitimate rotation. ## What is the new behavior? - New entry: `supavisor-error-password-authentication-failed-after-password-rotation.mdx` — explains this is expected, by-design pooler-cache behavior (not a bug), scopes it to SCRAM/password auth (not JIT), and walks through confirming the new password via a direct connection before contacting support. - Cross-links added from the existing circuit-breaker entry, the "How do I reset my Supabase database password?" entry, and the FAQ in `connecting-to-postgres.mdx`. ## Additional context Prettier check passes on all 4 touched files. `lint:mdx` (`supa-mdx-lint`) could not be run locally due to a pre-existing, unrelated native-module issue (`node-pty` missing its compiled binary for this platform) — expected to run in CI. <!-- This is an auto-generated comment: release notes by coderabbit.ai --> ## Summary by CodeRabbit ## Documentation * Added troubleshooting guidance for `28P01` password authentication failures after database password rotation. * Clarified Shared Pooler credential-refresh behavior, affected connection patterns, the built-in `postgres` role, and unaffected JIT access-token connections. * Added steps to verify credentials, retry connections, handle rate limits, and avoid repeated rotations. * Added guidance for updating credentials across live application instances and cross-references between related troubleshooting guides. <!-- end of auto-generated comment: release notes by coderabbit.ai --> ## Changed docs * the new guide: [docs-git-docs-supavisor-password-rotation-troub-026280-supab/…/supavisor-error-password-authentication-failed-after-password-rotation](https://docs-git-docs-supavisor-password-rotation-troub-026280-supabase.vercel.app/docs/guides/troubleshooting/supavisor-error-password-authentication-failed-after-password-rotation) * mention the new guide + info on auth_error Circuit Breaker [docs-git-docs-supavisor-password-rotation-troub-026280-supabase.vercel.app/docs/…/fatal-password-authentication-failed](https://docs-git-docs-supavisor-password-rotation-troub-026280-supabase.vercel.app/docs/guides/troubleshooting/fatal-password-authentication-failed) * mention the new guide: [docs-git-docs-supavisor-password-rotation-troub-026280-supabase.vercel.app/docs/…/how-do-i-reset-my-supabase-database-password…](https://docs-git-docs-supavisor-password-rotation-troub-026280-supabase.vercel.app/docs/guides/troubleshooting/how-do-i-reset-my-supabase-database-password-oTs5sB) * mention of the new guide: [docs-git-docs-supavisor-password-rotation-troub-026280-supabase.ver/…/supavisor-error-circuit-breaker-open-after-password-rotation…](https://docs-git-docs-supavisor-password-rotation-troub-026280-supabase.vercel.app/docs/guides/troubleshooting/supavisor-error-circuit-breaker-open-after-password-rotation-0fdb72) --------- Co-authored-by: Claude Sonnet 5 <noreply@anthropic.com> Co-authored-by: coderabbitai[bot] <136622811+coderabbitai[bot]@users.noreply.github.com> Co-authored-by: Nik Richers <nrichers@gmail.com> Co-authored-by: felipe stival <14948182+v0idpwn@users.noreply.github.com> Co-authored-by: Codesmith <codesmith-bot@users.noreply.github.com> |
||
|
Anthony Lio
|
de2f8bbd03 |
fix(docs): prima guide yarn panel display npx (#50186)
## What kind of change does this PR introduce? bug fix in prisma guide page code example ## What is the current behavior? yarn panel display `npx` command in code example ## What is the new behavior? favor `yarn` command in yarn panel code example | state | preview | | -------|------| | before | <img width="760" height="315" alt="image" src="https://github.com/user-attachments/assets/d7dc9004-9618-48ff-9b6c-4b7da4e8c44e" /> | | after | <img width="760" height="315" alt="image" src="https://github.com/user-attachments/assets/a7cee65f-2038-4f5a-81e3-1cb627cb73b9" /> | ## Test 1. visit `/docs/guides/database/prisma` <!-- This is an auto-generated comment: release notes by coderabbit.ai --> ## Summary by CodeRabbit * **Documentation** * Updated Yarn Prisma command examples to use Yarn-specific syntax for project initialization, migrations, database pulls, migration diffs, migration resolution, and client generation. * npm, pnpm, and Bun examples remain unchanged. <!-- end of auto-generated comment: release notes by coderabbit.ai --> |
||
|
Miranda Limonczenko
|
bc102876bb |
docs: apply the rest of the connecting to Postgres feedback (#49928)
Closes FDBKIN-31335 Closes FDBKIN-13040 Closes FDBKIN-8653 Closes FDBKIN-19912 Closes DOCS-740 ## 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? Docs update. While we are revising this document, this PR gathers docs feedback via AI magic and applies that feedback. ## What is the current behavior? These findings stand on feedback intake rather than on the baseline. Worth doing, and the eval won't show a score change for any of them. - **Nothing explains the pooler host.** #49868 switched the strings to `[POOLER-HOST]`, but the page never says why you can't compose the host, and agents that recite `aws-0` get `Tenant or user not found`. agent-skills#92. - **The page gives the instruction to turn prepared statements off, but not the flag.** It also links the GitHub discussion rather than the troubleshooting entry that mirrors it. FDBKIN-8248, FDBKIN-7883. - **SSL goes undiscussed.** Four of six eval runs set `ssl: 'require'` unprompted. - **The pooled username format only appears inside example strings**, never as a rule. DOCS-740, FDBKIN-19912. - **Third-party tools have no answer.** Session mode is the right one, and the decision table had no row for a BI client or database GUI at all. FDBKIN-8653. - **Only one of transaction mode's three limitations is documented.** FDBKIN-13040 names prepared statements, cursors, and session-level settings. The page covered prepared statements. ## What is the new behavior? - Tell the reader to copy the host, port, and username rather than typing the placeholders, and explain the pooler cluster index next to the reference table. The placeholders themselves changed in #49868. - State the username rule: direct connections and the dedicated pooler use `postgres`, shared pooler connections use `postgres.<project-ref>`. - Add a per-driver prepared statements table for Postgres.js, Drizzle, Prisma, asyncpg, and JDBC, and link [Disabling prepared statements](https://supabase.com/docs/guides/troubleshooting/disabling-prepared-statements-qL8lEL) for the rest. Add JDBC's `prepareThreshold=0` to that entry too, so the two pages agree. - Document SSL: `require` rather than the `prefer` default, which falls back to plaintext. - Link the `CONNECT_TIMEOUT` entry for stale sockets in frozen serverless runtimes. - Add a decision table row for a third-party tool, and point at Quickstarts for named tools. - Cover all three transaction mode limitations. Cursors work inside a single transaction only, and session-level state is lost between transactions: `set` and `reset`, session-level advisory locks, `listen` and `notify`, and temporary tables. Renamed the section from "Prepared statements", since it now covers the cause rather than one symptom. - Promote Configure your client to an H2 and fold the SSL certificate section into it. The table of contents only renders H2 and H3, so the client settings were invisible as H4s. ## Manual testing 1. Open [Connect to your database](https://docs-git-docs-connecting-to-postgres-technical-supabase.vercel.app/docs/guides/database/connecting-to-postgres) on the deploy preview. 2. Read the Get your connection string lead-in. It tells you to copy the host, port, and username rather than typing the placeholders. 3. Check the table of contents. Configure your client is an H2 with Application-side pool size, Prepared statements, SSL, and Stale connections under it. 4. Follow the prepared statements link. It lands on the in-docs troubleshooting entry, not GitHub. 5. Open the [endpoint reference](https://docs-git-docs-connecting-to-postgres-technical-supabase.vercel.app/docs/guides/database/connecting-to-postgres#endpoints-and-ip-versions). The table shows `aws-[INDEX]-[REGION]`, and the prose below explains the index and the username rule. 6. Read the decision table. It has a row for a third-party BI client or database GUI, pointing at session mode. 7. Read [Transaction mode limitations](https://docs-git-docs-connecting-to-postgres-technical-supabase.vercel.app/docs/guides/database/connecting-to-postgres#transaction-mode-limitations). It covers prepared statements, cursors, and session-level state. <!-- This is an auto-generated comment: release notes by coderabbit.ai --> ## Summary by CodeRabbit ## Documentation - Expanded the Postgres connection guide with clearer client configuration guidance, including pool sizing, SSL, stale connections, and transaction mode limitations. - Added recommendations for BI tools and database GUIs using the shared pooler. - Clarified connection strings, pooler hosts, usernames, ports, and IP version behavior. - Updated serverless driver guidance for transaction mode configuration. - Added JDBC troubleshooting instructions for disabling prepared statements with `prepareThreshold=0`. <!-- end of auto-generated comment: release notes by coderabbit.ai --> |
||
|
Miranda Limonczenko
|
15484a0e75 |
docs: add application-side pool sizing to the connecting to Postgres guide (#49927)
Closes DOCS-1312 ## 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? Docs update. One technical addition, isolated so the eval can attribute a score change to it. I re-ran the preview link on a scratch Eval branch and found that this PR will resolve the Eval. ## What is the current behavior? The eval baseline for `build-docs-004-postgres-connection` fails one check, 3 of 6 runs: the application-side pool cap for a serverless invocation. - Two failing runs left `max` unset, which is 10 on the Postgres.js default. - One set `max: 5`. The page says nothing about the application-side pool, so there was nothing for an agent to read. Every other check passes 6/6, including the connection string, port, username, and prepared statements. The mode choice already transmits from the page. Baseline notes are on [DOCS-1312](https://linear.app/supabase/issue/DOCS-1312). ## What is the new behavior? Add a **Configure your client** section to the procedure group. Pool sizing is its only subject. - Set the application-side pool to 1 connection per serverless invocation, and raise it only on evidence. - Name the trap concretely. Library defaults assume a persistent backend, and 10 connections is 10 per warm instance, with the instance count outside your control. - One Postgres.js sample setting `max` and `prepare`, created at module scope. - Cite the [Supavisor FAQ](https://supabase.com/docs/guides/troubleshooting/supavisor-faq-YyP5tI) and [Prisma troubleshooting](https://supabase.com/docs/guides/database/prisma/prisma-troubleshooting), which already carries the equivalent `connection_limit` guidance for one ORM. The gap is that the connection guide didn't carry it for readers not using Prisma. `prepare: false` is in the sample because a transaction mode sample is wrong without it, and the page already instructs it. It isn't new guidance. `ssl: 'require'` is, so it waits for #49928. ## Additional context PR 3 of 4. Base is #49869. This ships alone on purpose. It's the only change with baseline evidence behind it, so a score change after this PR is attributable to one edit. #49928 carries the rest of the eval feedback and is not expected to move the score. **Run the eval against this preview before #49928 lands.** ## Manual testing 1. Open [Connect to your database](https://docs-git-docs-connecting-to-postgres-pool-size-supabase.vercel.app/docs/guides/database/connecting-to-postgres) on the deploy preview. 2. Check the table of contents. "Configure your client" appears under Get your connection string. 3. Read the section. It states 1 connection per invocation and names the Postgres.js default of 10. 4. Read the sample. It sets `max: 1` and `prepare: false`, and says the client is created once at module scope. <!-- This is an auto-generated comment: release notes by coderabbit.ai --> ## Summary by CodeRabbit - **Documentation** - Added guidance for configuring application-side Postgres clients when connecting through Supabase poolers. - Documented recommended serverless settings, including creating the client once, limiting connections per invocation, and disabling prepared statements in transaction mode. - Added a Postgres.js configuration example and links to relevant Supavisor FAQ and Prisma troubleshooting resources. <!-- end of auto-generated comment: release notes by coderabbit.ai --> |
||
|
Miranda Limonczenko
|
976e7338bc |
docs: restructure the connecting to Postgres guide by information type (#49869)
## 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? Docs update. Restructure, mostly moved lines, plus inbound anchor fixes. ## What is the current behavior? The page states the same routing decision four times and never states an answer: - Intro bullets - A matrix table - A "How to choose the right connection method?" section - A Mermaid flowchart An agent asked "I'm deploying to Vercel serverless functions, set up the database connection" has to synthesize an answer from four partial, inconsistent restatements. Context, procedure, and reference material are interleaved throughout, so background reading interrupts the action path. The page is also too long at 2,883 words, and grouping alone doesn't fix that. Explainer and reference material need their own page, and the troubleshooting group belongs in troubleshooting entries. 16 of the 19 inbound anchor links to this page are already broken on `master`, before any restructure: `#direct-connections`, `#shared-pooler`, `#connection-pooler`, `#how-connection-pooling-works`, `#quick-summary`, `#connection-pool`, and `#connecting-with-drizzle`. Groundwork for [DOCS-1312](https://linear.app/supabase/issue/DOCS-1312). The issue stays open until the paired eval is re-run. ## What is the new behavior? Group the guide into a decision, a procedure, context, reference, and troubleshooting, per CONTRIBUTING § Guides on mixed information types. Review with `git diff --color-moved=zebra`. - Lead with "Which connection method do you use?", a decision table keyed on where your code runs. Section navigation sits directly below the intro. - Collect every connection string under "Get your connection string", with the shared Connect dialog steps stated once as a procedure. - Move the endpoint, port, pool size, and connection limit material into "Connection reference". These were FAQ questions. - Split the page. The guide keeps the decision, the connection strings, and the quickstarts, at 1,180 words and three paths. A new child page, Connection pooling and limits, carries how pooling works, pool size, connection limits, and monitoring. - Move the endpoint and IP version table up beside the connection strings it explains. - Replace the troubleshooting group with two new troubleshooting entries, `tenant-or-user-not-found` and `fatal-password-authentication-failed`, plus links to the existing entries. The existing connection-refused entry is stronger than what was here: it names the IP ban and gives the unban procedure. - Cut the pool size worked example. It said a pool size of 30 is a shared ceiling across session and transaction mode, while the Supavisor FAQ and the terminology entry both say pool size is per user, database, and mode combination. That text came from `master`, so the contradiction is pre-existing. Link the FAQ as the authority rather than picking a side. - Drop the duplicate `pg_stat_ssl` query, which already exists in `connection-management.mdx` and `monitor-supavisor-postgres-connections.mdx`, both with column tables this page lacked. - Add the subsection to the navigation, which also adopts `connecting-to-postgres/serverless-drivers`. That page existed on disk and was referenced nowhere in the navigation constants. - Delete the decision flowchart. It was the fourth restatement of the decision table, and its logic was broken: `Persistent Backend` had two unconditional edges into decision nodes that each had one unlabeled output, so neither node decided anything. - Fix every broken inbound anchor, and pin stable anchors on the headings they target. This now includes six files in `apps/www` that no earlier pass in this stack checked, most of which were already broken on `master`. - Repoint the Studio Connect sheet's Drizzle link at the Drizzle guide. It pointed at a heading this page hasn't had for some time. - Serverless drivers: state the guide's intent, give the three runtimes parallel structure, and link the transaction mode prepared statements constraint. That page never mentioned the constraint that most affects serverless connections. ## Additional context PR 2 of 2. Base is #49868, rebased on its review feedback commit. Three of the 13 files are in `apps/studio`, so this runs the Studio unit tests, build, and lint ratchet. They are link string changes only. The ESLint warning count is unchanged at 1 on the touched files, so the ratchet holds. ## Manual testing 1. Open [Connect to your database](https://docs-git-docs-connecting-to-postgres-structure-supabase.vercel.app/docs/guides/database/connecting-to-postgres) on the deploy preview. 2. Check the table of contents. The top level reads: Which connection method do you use?, Get your connection string, Quickstarts, Related. The intro lists three paths. 3. Open [Reports](https://docs-git-docs-connecting-to-postgres-structure-supabase.vercel.app/docs/guides/monitoring-and-debugging/reports) and follow "Implement connection pooling" under Disk IO. It lands on the decision table. 4. Open [Serverless drivers](https://docs-git-docs-connecting-to-postgres-structure-supabase.vercel.app/docs/guides/database/connecting-to-postgres/serverless-drivers). The intro links the transaction mode prepared statements constraint. 5. Check the sidebar. Connecting to your database expands to Connection pooling and limits and Serverless drivers. 6. Open [Connection pooling and limits](https://docs-git-docs-connecting-to-postgres-structure-supabase.vercel.app/docs/guides/database/connecting-to-postgres/pooling-and-limits). Pool size states the setting and links the Supavisor FAQ, with no worked example. 7. Open [Tenant or user not found](https://docs-git-docs-connecting-to-postgres-structure-supabase.vercel.app/docs/guides/troubleshooting/tenant-or-user-not-found). <!-- This is an auto-generated comment: release notes by coderabbit.ai --> ## Summary by CodeRabbit * **New Features** * Added a dedicated guide covering connection pooling, limits, configuration, and monitoring. * Added troubleshooting guides for password authentication failures and shared pooler tenant or user errors. * Expanded connection guidance with method selection, endpoints, IP versions, and serverless driver configuration. * **Documentation** * Reorganized database connection documentation and navigation. * Updated related links throughout the documentation to current connection and pooling guidance. * Improved guidance for pooler modes, connection strings, and supported deployment environments. <!-- end of auto-generated comment: release notes by coderabbit.ai --> |
||
|
Miranda Limonczenko
|
7fbaeb3dcd |
docs: style edit for the connecting to Postgres guide (#49868)
## 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? Docs update. Style only. ## What is the current behavior? The connecting to Postgres guide and its serverless drivers child page have drifted from `WORD_LIST.md` and `CONTRIBUTING.md`. They also carry six defects: - The connection pooling diagram's alt text describes migrations on a preview instance. - The SSL screenshot's alt text and the sentence above it both promise connection info. The image shows the SSL Configuration panel: a toggle and a Download Certificate button. - "Where can you see current connection usage?" lists three Observability reports, then says the Roles page is not real-time. The Roles page appears nowhere else in that answer. - The serverless drivers manual configuration step has no main clause. - "For example, If you set the pool size to 30". - One of the two monitoring queries uses uppercase SQL keywords. Three of the four connection strings use `postgres://` and two carry literal project refs. The Connect dialog emits `postgresql://` with placeholders. The pooler host is templated as `aws-[region]`, which reads as composable and isn't. Hosts are `aws-<index>-<region>.pooler.supabase.com`, and the index is a pooler cluster index, not part of the region. Both `aws-0-us-west-1` and `aws-1-us-west-1` appear in this repo, so a reader can't derive it. Studio doesn't compose the host either; it comes from the API. Groundwork for [DOCS-1312](https://linear.app/supabase/issue/DOCS-1312). The issue stays open until the paired eval is re-run. ## What is the new behavior? Word-level edit. No section is added, moved, or reordered, so the restructure in the next PR of this stack lands as a readable set of moved lines. Headings are untouched; PR 2 owns all heading changes. - Fix the six defects above. - Align the connection strings with what the Connect dialog emits: `postgresql://` on all four, and `[PROJECT-REF]` in place of two literal project refs. - Use `[POOLER-HOST]` in the copyable pooler strings, the convention the newer quickstarts already use. Keep the full `aws-[INDEX]-[REGION]` shape in the summary table, where showing the shape is the point. - Settle on one name per concept: shared and dedicated pooler in sentence case, persistent backend, serverless and edge functions, and paid plans. - Drop bold used for plain emphasis, parenthetical asides, and claims the page doesn't support: "ideal for", "ensures best performance and latency", "satisfactory on their own". - Format the two literal error strings as code, not quotes. - Split the pool size answer into one paragraph per subject, and turn the two pooler limits into a table. - Serverless drivers: sentence case title, an intent sentence, and a four-step procedure in place of the sentence fragment. ## Additional context PR 1 of 2. Base is `master`. Second commit applies review feedback. Third fixes the pooler host placeholder, which belongs here rather than later in the stack: the evidence is in the repo, not in the eval. ## Manual testing 1. Open [Connect to your database](https://docs-git-docs-connecting-to-postgres-style-supabase.vercel.app/docs/guides/database/connecting-to-postgres) on the deploy preview. 2. Read the four connection strings. All four use `postgresql://`, and the two pooler strings use `[POOLER-HOST]` rather than a composable region template. 3. Inspect the two images. The pooling diagram's alt text describes pooling, and the SSL screenshot's describes the SSL Configuration panel. 4. Read "Where can you see current connection usage?". The paragraph after the report list refers to the reports, not the Roles page. 5. Read "What is the difference between client connections and backend connections?". The two limits are a table. 6. Open [Serverless drivers](https://docs-git-docs-connecting-to-postgres-style-supabase.vercel.app/docs/guides/database/connecting-to-postgres/serverless-drivers). Manual configuration is four numbered steps. <!-- This is an auto-generated comment: release notes by coderabbit.ai --> ## Summary by CodeRabbit - **Documentation** - Clarified the PostgreSQL connection guide with updated connection examples, pooling guidance, connection-mode tables, SSL information, FAQs, and SQL formatting. - Replaced sample connection values with generic placeholders in documentation examples. - Added clearer guidance that frontend Data API access requires appropriate RLS policies. - Updated explanations of client/backend connections and long-lived PostgreSQL sessions. - Updated serverless driver documentation with clearer setup guidance for Vercel, Cloudflare, and Supabase Edge Functions. - Reorganized manual configuration into numbered steps and standardized connection string examples. - Improved descriptions of runtime behavior and supported connection methods. <!-- end of auto-generated comment: release notes by coderabbit.ai --> |
||
|
Anthony Lio
|
45199443c8 |
fix(ui): admonition component parity (#49925)
## what is the current behavior? admonition icon <> text not optically aligned + rendered differently in docs and the design system _ docs showed admonition text at 15px/28px because the page's prose styles reached inside the component, while the same callout was 13px in the design system _ lists ## what is the new behavior? - the title offset is now conditional. a title and body copy have different line heights, so they need different nudges to sit level with the icon. - fixes list markers and the ordered-list chip alignment inside callouts. - removes `.admonition-content` css that nothing referenced - fixes 5 admonition titles that were not capitalized. | state | preview | | -------|------| | before | <img width="902" height="279" alt="image" src="https://github.com/user-attachments/assets/2fffb183-81e2-4eff-8f0d-8a07649390e8" /> | | after | <img width="902" height="279" alt="image" src="https://github.com/user-attachments/assets/22abe3ed-fd6d-49ac-aa37-4292bca5850a" /> | ## follow ups - better composition: title, description and actions are still props _ a compound api (`Admonition.Title`, `Admonition.Actions`) would remove the `childProps` escape hatch <!-- This is an auto-generated comment: release notes by coderabbit.ai --> ## Summary by CodeRabbit * **Documentation** * Improved capitalization of note and warning titles in the Metabase and Prisma guides for consistency. * Updated the contributing guide’s table of contents to exclude feedback headings. * Improved heading structure for the documentation feedback section. * **UI Improvements** * Refined admonition and alert typography, spacing, list formatting, and ordered-list alignment. * Improved content spacing when titles, descriptions, or icons are present. * Updated action links and buttons for more consistent sizing. * Adjusted alert content styling for a clearer presentation. <!-- end of auto-generated comment: release notes by coderabbit.ai --> |
||
|
|
e0280cb650 |
docs: restructure observability navigation and overview (#49505)
<!-- CURSOR_AGENT_PR_BODY_BEGIN --> ## Stack Draft stack extracted from `docs/monitoring`. Merge bottom-up. The troubleshooting *catalog* rewrite (`content/troubleshooting` and the Diagnosing UI) stays out of scope. 1. #49503 move inspect and advisors 2. #49501 split Studio logs from ClickHouse queries 3. #49500 treat reports as signal dashboards 4. #49502 add Observe the data hub 5. #49506 add agent setup components 6. #49504 add hire-an-agent templates 7. **#49505** restructure observability nav, overview, Detecting, and flatten Observe the data ← **this PR** ## 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? Docs update. Top layer in the observability stack. ## What is the current behavior? The section is still titled Monitoring and Debugging, with a Debugging / Monitoring split that does not match the new pages. The debugging guide is still the master layer-isolation + symptom table. Observe the data is split into “what data” vs “where to observe it,” which duplicates the source pages. ## What is the new behavior? - Section title is Observability - Overview groups Observe the data, Detect and resolve, Hire an agent, and Export - **Observe the data is flattened by source.** Logs, Metrics API, Database, Advisors, and Reports each list where to read that source. There is no separate MCP/API/CLI/Studio nav group. - **Observe vs Detecting:** Observe is the catalog (what exists, how to access it). Detecting is how to *use* those sources to pick up a Health / Security / Performance / Usage signal. Named errors skip to Diagnosing. - Studio Logs sits under Logs. Reports sits beside the other sources. - Troubleshooting stays in the global menu and also appears as Diagnosing under Detect and resolve ## Additional context This is the last PR in the stack. Together the seven PRs reconstruct the `docs/monitoring` observability IA and guide content, without shipping the troubleshooting catalog overhaul. <!-- CURSOR_AGENT_PR_BODY_END --> <div><a href="https://cursor.com/agents/bc-a3cb5ece-925b-4046-b58a-5d69e9a9d794?cursor_ref=pr_footer&cursor_cta=open_in_web"><picture><source media="(prefers-color-scheme: dark)" srcset="https://cursor.com/assets/images/open-in-web-dark.png"><source media="(prefers-color-scheme: light)" srcset="https://cursor.com/assets/images/open-in-web-light.png"><img alt="Open in Web" width="114" height="28" src="https://cursor.com/assets/images/open-in-web-dark.png"></picture></a> <a href="https://cursor.com/background-agent?bcId=bc-a3cb5ece-925b-4046-b58a-5d69e9a9d794&cursor_ref=pr_footer&cursor_cta=open_in_cursor"><picture><source media="(prefers-color-scheme: dark)" srcset="https://cursor.com/assets/images/open-in-cursor-dark.png"><source media="(prefers-color-scheme: light)" srcset="https://cursor.com/assets/images/open-in-cursor-light.png"><img alt="Open in Cursor" width="131" height="28" src="https://cursor.com/assets/images/open-in-cursor-dark.png"></picture></a> </div> --------- Co-authored-by: Cursor Agent <cursoragent@cursor.com> Co-authored-by: Saxon Fletcher <SaxonF@users.noreply.github.com> Co-authored-by: Nik Richers <nik@validmind.ai> |
||
|
|
0bbd64743c |
docs: move inspect and advisors into observability (#49503)
<!-- CURSOR_AGENT_PR_BODY_BEGIN --> ## Stack Draft stack extracted from `docs/monitoring`. Merge bottom-up. Troubleshooting / debugging-guide rewrite is out of scope. 1. **#49503** move inspect and advisors ← **this PR** 2. #49501 split Studio logs from ClickHouse queries 3. #49500 treat reports as signal dashboards 4. #49502 add Observe the data hub 5. #49506 add agent setup components 6. #49504 add hire-an-agent templates 7. #49505 restructure observability nav and overview ## 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? Docs update. First layer in the observability stack. ## What is the current behavior? Inspect and advisors live under Database (`/guides/database/inspect`, `/guides/database/database-advisors`). Observability readers have to leave the monitoring section to find them. ## What is the new behavior? - Moves inspect into `/guides/monitoring-and-debugging/inspect` - Adds `/guides/monitoring-and-debugging/advisors` (replaces the Database Advisors page) - Adds redirects and updates Studio/docs links so old URLs keep working - Adds both pages to the existing Monitoring nav so they are discoverable before the later IA PR ## Additional context Inspect and advisors pages render as standard MDX. Redirects cover `/docs/guides/database/inspect`, `/docs/guides/database/database-advisors`, and `/docs/guides/database/database-linter`. Debugging-guide content is unchanged except the inspect URL. ## Self-review - No leftover `/guides/database/inspect` or `/guides/database/database-advisors` links in docs guides or Studio linter/AI surfaces (historical blog posts left as-is) - Smoke test path updated to `/docs/guides/monitoring-and-debugging/advisors` <!-- CURSOR_AGENT_PR_BODY_END --> <div><a href="https://cursor.com/agents/bc-a3cb5ece-925b-4046-b58a-5d69e9a9d794?cursor_ref=pr_footer&cursor_cta=open_in_web"><picture><source media="(prefers-color-scheme: dark)" srcset="https://cursor.com/assets/images/open-in-web-dark.png"><source media="(prefers-color-scheme: light)" srcset="https://cursor.com/assets/images/open-in-web-light.png"><img alt="Open in Web" width="114" height="28" src="https://cursor.com/assets/images/open-in-web-dark.png"></picture></a> <a href="https://cursor.com/background-agent?bcId=bc-a3cb5ece-925b-4046-b58a-5d69e9a9d794&cursor_ref=pr_footer&cursor_cta=open_in_cursor"><picture><source media="(prefers-color-scheme: dark)" srcset="https://cursor.com/assets/images/open-in-cursor-dark.png"><source media="(prefers-color-scheme: light)" srcset="https://cursor.com/assets/images/open-in-cursor-light.png"><img alt="Open in Cursor" width="131" height="28" src="https://cursor.com/assets/images/open-in-cursor-dark.png"></picture></a> </div> <!-- This is an auto-generated comment: release notes by coderabbit.ai --> ## Summary by CodeRabbit - **New Features** - Added a centralized Advisors guide for security and performance checks. - Updated database inspection guidance with live Postgres statistics, cache hit-rate context, and query-analysis resources. - **Documentation** - Reorganized Advisors and database inspection content under Monitoring and Debugging. - Updated navigation, cross-references, in-product help links, and CLI documentation links. - Added permanent redirects from previous documentation URLs to preserve access. <!-- end of auto-generated comment: release notes by coderabbit.ai --> --------- Co-authored-by: Cursor Agent <cursoragent@cursor.com> Co-authored-by: Saxon Fletcher <SaxonF@users.noreply.github.com> Co-authored-by: Nik Richers <nik@validmind.ai> |
||
|
Danny White
|
24be387cdb |
docs: use sign in terminology across guides and style guides (#49877)
## What kind of change does this PR introduce? Docs update. Aligns documentation and style guides with the **Sign in / Sign out / Sign up** platform standard. Closes DOCS-1328. Related to [#49874](https://github.com/supabase/supabase/pull/49874). ## What is the current behavior? Docs style guides prefer _login_ / _log in_. Guide prose uses mixed login and sign in wording. ## What is the new behavior? - [WORD_LIST.md](apps/docs/WORD_LIST.md) and [copywriting.mdx](apps/design-system/content/docs/copywriting.mdx) document the sign in standard - Design-system auth examples updated - Guide prose and API reference spec descriptions updated ### Terminology **Standard:** Use _sign in_, _sign out_, and _sign up_ as verbs. Use _sign-in_, _sign-out_, and _sign-up_ as nouns and adjectives. Match Studio UI labels (**Sign in**, **Sign out**, **Sign up**). **Preserved intentionally:** | Category | Keep as-is | Example | | -------- | ---------- | ------- | | Feature name | social login | `/social-login`, `features.mdx` heading, OAuth provider section | | URL slugs | `login` in paths | `/phone-login`, `/login-flows`, `choosing-login-flow` | | CLI | `supabase login` / `supabase logout` | Reference ids `supabase-login` / `supabase-logout`; executable commands unchanged | | SDK methods | `logout()` | Kotlin/Swift method names in API reference titles and examples | | Third-party UI | Provider product labels | Facebook Login, Kakao Login, portal **Login** buttons | | Postgres | Database terminology | login privileges, login credentials, login via role | | Audit/logging | Log prose | "Generates the following **log** in the Postgres Logs" | | Code and routes | Paths and filenames | `app/login/`, `Login.tsx`, `demos/android-login` | | External URLs | Third-party login pages | `dash.cloudflare.com/login`, `console.neon.tech/login`, `vercel.com/login` | | API identifiers | Event and field names | Audit actions `login`/`logout`, `should_logout_user` | ## To test - Run `pnpm lint:mdx` in `apps/docs` - Spot-check `features.mdx`, `social-login.mdx`, and a provider guide (e.g. Facebook, Kakao) <!-- This is an auto-generated comment: release notes by coderabbit.ai --> ## Summary by CodeRabbit * **Documentation** * Standardized authentication terminology across guides, reference material, CLI documentation, and copywriting guidance using “sign in,” “sign out,” and “sign up.” * Updated authentication instructions, headings, link text, examples, and SSO guidance for clearer, more consistent wording. * Corrected related grammar, spelling, hyphenation, and documentation links while preserving established product names and implementation commands. * **Style** * Refined code examples with consistent import ordering and spacing. * **Examples** * Updated authentication button and menu labels to “Sign in” and “Sign out.” <!-- end of auto-generated comment: release notes by coderabbit.ai --> |
||
|
Miranda LimonczenkoandClaude Opus 5
|
21265b2e59 |
docs(database): make writing and running the tests part of the procedure (#49276)
Ref DOCS-1274 Follow-up to #49017, now merged. This is the go-to-green piece: everything aimed at the three failing eval checks, and nothing else. Technical corrections follow in the PR stacked on this one. ## Problem `build-docs-002-rls-guide` points an agent at this guide with a vibe-coder prompt that never says RLS, policy, role, or test. Grants, policies, access probes, indexes, and security-definer placement all pass. Three checks fail, and have failed on every recorded run: | Check | What it measures | Why it failed | | --- | --- | --- | | `pgTAP test file(s) written under supabase/tests/` | Any `.sql` file exists | The agent never wrote one. | | `supabase test db runs at least 8 assertions and all pass` | Suite runs, ≥8 assertions, none failing | Nothing to run. The only example was `plan(4)`, under the floor even if copied perfectly. | | `tests assert allow and deny per operation … for anon and authenticated` | LLM judge on coverage | Never reached the judge: "no test files to review". | The guide already had a `Test your policies` section, so this isn't a strength problem. Agents don't read the page. They fetch it through an LLM extraction guided by their own query, and that query asked for enabling RLS, policy syntax, `auth.uid()`, indexes, and security definer functions. It never mentioned tests. A section about testing never enters the extract, so more testing prose cannot reach the agent. There was also a plain documentation bug underneath it: `Secure a table with RLS` said a table isn't secured until the suite passes, but the procedure beneath it ran 1–3 and ended on `grant`. A reader following the numbered steps finished without ever being told to write a test. ## Solution Put the tests where the procedure and the examples already are. - **`Secure a table with RLS`** opens with the four steps that finish a table, ending on `supabase test db`. Until the suite passes, you don't know whether the policies do what you intended. - **`Enable RLS and set the grants` gains step 4** — `supabase test new <table>_rls.test`, then `supabase test db`. The procedure ends on a passing suite instead of a grant. - **The public-read example** gains its policy and `announcements_rls.test.sql`, so a test file rides along in the enable-RLS extract. - **The four policy examples** are followed immediately by `profiles_rls.test.sql`, so one rides along in the `create policy` extract too. - **`Run the test suite` shrinks** to creating and running the files. It no longer carries content that has to survive extraction. - Each file leads with its own path as a comment, so it survives if the fence metadata is dropped. ### How that maps to the three checks | Check | Addressed by | | --- | --- | | Test files written | A complete test file now sits inside both extracts an agent's own query pulls, and step 4 of the procedure names the command that creates one. | | ≥8 assertions, all passing | `announcements_rls.test.sql` is `plan(10)`, `profiles_rls.test.sql` is `plan(14)`. Either alone clears the floor; together, 24. | | Coverage judge | `profiles` asserts allow **and** deny for all four operations. Allowed writes use `returning` + `results_eq`, proving state changed rather than that nothing raised. `using`-filtered denials use `is_empty`, asserting the row is unchanged rather than that an error was raised — the case the rubric explicitly fails suites for getting wrong. Both files switch role with `set local role` and identity with `set local request.jwt.claim.sub`, and cover `anon` as well as `authenticated`. | ## Manual testing 1. Open the [Row Level Security guide](https://docs-git-docs-rls-tests-in-procedure-supabase.vercel.app/docs/guides/database/postgres/row-level-security) on the preview. `Secure a table with RLS` opens with a four-step definition of done ending on `supabase test db`. 2. Read `Enable RLS and set the grants`. The procedure runs 1–4 and ends on writing and running the test, not on the grant. 3. Scroll to `DELETE policies`. The four policies are followed immediately by `profiles_rls.test.sql`, not a pointer to a later section. 4. Open the [markdown version](https://docs-git-docs-rls-tests-in-procedure-supabase.vercel.app/docs/guides/database/postgres/row-level-security.md), which is what agents fetch. Both test files are present, each leading with its path. <!-- This is an auto-generated comment: release notes by coderabbit.ai --> ## Summary by CodeRabbit ## Documentation - Updated database security guidance for enabling row-level security and configuring grants. - Added per-table pgTAP testing requirements and revised `supabase test db` examples. - Expanded examples for permitted and denied access across public and authenticated roles. - Added dedicated guidance for profile testing and security-definer member/non-member cases. - Documented recursive-policy `42P17` failures and the security-definer workaround. - Clarified indexing, denial diagnosis, returned-row verification, and table-hardening links. - Streamlined the general policy-testing guidance. <!-- end of auto-generated comment: release notes by coderabbit.ai --> --------- Co-authored-by: Claude Opus 5 <noreply@anthropic.com> |
||
|
Arshdeep Singh
|
166cab8dee |
docs: fix api link path in pg_net.mdx (#49478)
## 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? fix: Updates the Data API link in current permission section ## What is the current behavior? The link currently points to the wrong path, resulting in a 404 error. <!-- This is an auto-generated comment: release notes by coderabbit.ai --> ## Summary by CodeRabbit * **Documentation** * Updated the Data API permissions documentation link to point to the current API guide. <!-- end of auto-generated comment: release notes by coderabbit.ai --> |
||
|
Arshdeep SinghandJeremias Menichelli
|
e478aabb80 |
Clarify pg_net net schema grants (#49472)
## 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? Documentation update — adds a new "Permissions" section to the pg_net guide. ## What is the current behavior? The pg_net docs don't explain the default permission model for the net schema. Customers running security reviews flag that net schema objects (net.http_request_queue, net._http_response) are readable by anon/authenticated via inherited PUBLIC grants, and some have run their own REVOKE scripts to lock this down. This breaks the pg_net background worker, since postgres (the role the worker runs as) inherits its own access through that same PUBLIC grant. ## What is the new behavior? Adds a "Permissions" section clarifying that the default grants are safe as-is, net isn't exposed through the Data API, and anon/authenticated are NOLOGIN roles with no direct database connection. ## Additional context For background and reviewer discussion on the accuracy of this, see the https://supabase.slack.com/archives/C02FHG9QQAF/p1787299415288589. <!-- This is an auto-generated comment: release notes by coderabbit.ai --> ## Summary by CodeRabbit * **Documentation** * Added permissions guidance for the `net` schema. * Clarified access available to `anon` and `authenticated` roles. * Explained why these permissions do not expose request data through the Data API or direct database connections. <!-- end of auto-generated comment: release notes by coderabbit.ai --> --------- Co-authored-by: Jeremias Menichelli <jmenichelli@gmail.com> |
||
|
Victor Farazdagi
|
3bc52101ee |
(docs/pipelines): early access destinations (#49304)
## What kind of change does this PR introduce? Docs update ## Summary - Add Early Access setup and reference guides for ClickHouse, DuckLake, and Snowflake. - Update Pipelines navigation and shared documentation with destination-specific data models, source requirements, schema-change support, and recovery behavior. - Keep all three destinations organization-gated. DuckLake is documented only as a Pipelines replication destination i.e. query compute remains external and this is not a Warehouse launch. <!-- This is an auto-generated comment: release notes by coderabbit.ai --> ## Summary by CodeRabbit * **New Features** * Added ClickHouse, DuckLake, and Snowflake as Early Access Pipelines destinations. * Added BigQuery as a managed destination. * Added destination navigation and setup guides covering configuration, replication behavior, schema changes, type mappings, troubleshooting, and monitoring. * **Documentation** * Clarified destination availability, regional guidance, requirements, limitations, and processing behavior. * Documented destination-specific schema-change support, table identity requirements, reset behavior, and CDC replication modes. <!-- end of auto-generated comment: release notes by coderabbit.ai --> |
||
|
Ali WaseemandJordi Enric
|
01d12e83c1 |
docs: migrate logs queries to ClickHouse and link to the SQL Editor (#49273)
The 47 BigQuery-era logs queries across these 20 pages error on the
ClickHouse-backed logs engine ("Backend error! Retry your query."). This
converts them per the rules in `apps/studio/lib/ai/clickhouse-logs.ts`
and repoints every Logs Explorer link at the SQL Editor with the query
source set to **Logs**, since the Logs Explorer is being retired. Also
fixes two stale PostgreSQL 12 links in the tables guide.
Each of the 14 prefilled links was verified to decode back to exactly
the SQL shown on its page. One caveat for review:
`response.headers.proxy_status` in `postgrest-error-codes.mdx` is
unverified — it isn't in the published field reference, and the test
project had no `edge_logs` traffic to confirm against.
Fixes DOCS-1331
<!-- This is an auto-generated comment: release notes by coderabbit.ai
-->
## Summary by CodeRabbit
- **Documentation**
- Updated database, storage, API, and Edge Function logging guides to
use the SQL Editor and current Logs interface.
- Replaced legacy Log Explorer and BigQuery examples with current query
syntax and structured log fields.
- Refreshed troubleshooting queries for error diagnosis, filtering,
aggregation, and performance analysis.
- Improved examples with clearer source filters, status handling,
request details, joins, and result limits.
- Updated PostgreSQL documentation links and clarified how API error
codes appear in responses.
<!-- end of auto-generated comment: release notes by coderabbit.ai -->
---------
Co-authored-by: Jordi Enric <jordi.err@gmail.com>
|
||
|
Ali Waseem
|
e5f12b4252 |
fix(docs): fix step code block spacing and Prisma guide tabs (#49263)
Two fixes for the [Prisma guide](https://supabase.com/docs/guides/database/prisma): - `StepHikeCompact.Code` marked its whole subtree `not-prose`, so the labels and admonitions that steps interleave with their code samples rendered at 16px with zero margins, flush against the samples and tab bars. Dropping `not-prose` restores body typography and spacing; back-to-back samples now get a gap too, since they have no prose between them. - The guide's three outer tab groups omitted `type`, so they fell back to pill styling — the only pills among 395 `<Tabs>` in the content tree. Fixes DOCS-1327 <!-- This is an auto-generated comment: release notes by coderabbit.ai --> ## Summary by CodeRabbit * **Style** * Improved spacing and prose behavior for code samples in the documentation. * Preserved existing code margin customizations. * Updated Prisma guide tabs with a consistent compact, underlined appearance. <!-- end of auto-generated comment: release notes by coderabbit.ai --> |
||
|
Miranda LimonczenkoandClaude Opus 5
|
6368f00ca0 |
docs(database): restructure the RLS guide by information type (#49017)
## Problem The guide alternated between context, procedure, and reference on almost every heading. A reader who wanted to write a policy passed through four context or reference sections to reach one. A reader who wanted the model had to skip three procedures. ## Solution - Group into three sections by information type: `Understand Row Level Security`, `Secure a table with RLS`, and `RLS reference`, with a navigation intro. - Merge the four policy sections. They repeated the same setup block, burying the clause that differed. One setup block now precedes four short policy examples. - Move the auto-enable recipe into `event-triggers.mdx`, whose stub section's entire body was a link back here. - Relocate the stranded `auth.uid()` caution into the `auth.uid()` reference. - Lift the revoke-and-grant procedure out of the danger admonition and merge it with the two other places that taught `enable row level security`. - Point the Grafana IO chart entry at the performance guide. Its `#rls-performance-recommendations` anchor went away when tuning split out in #49016. 765 lines to 582. 30 headings to 25. Headings are demoted rather than renamed wherever anything links to them. Every inbound anchor in the repo still resolves; the only one removed, `#auto-enable-rls-for-new-tables`, was referenced solely by the `event-triggers.mdx` stub this PR replaces. ## Note on the history Rebuilt from `master` after #49011, #49015, and #49016 merged. The branch previously carried those 10 commits plus rebase churn against them. Rebasing naively would have reverted review feedback from #49016 (`70fa812`), which removed the benchmarks table and the "This guide" opener from the performance guide. Those are deliberately not restored here. The only changes to that file are two missing `await`s and a join predicate that was a tautology while unqualified. The three PRs stacked on this one (#49268, #49269, #49270) have been rebased onto the new base. ## Manual testing 1. Open the [Row Level Security guide](https://docs-git-docs-rls-restructure-supabase.vercel.app/docs/guides/database/postgres/row-level-security) on the preview. Three top-level sections appear in the table of contents. 2. Select each link in the intro. All three jump to their section. 3. Open [Event triggers](https://docs-git-docs-rls-restructure-supabase.vercel.app/docs/guides/database/postgres/event-triggers). The auto-enable section holds the full recipe instead of a link. 4. Open the [performance guide](https://docs-git-docs-rls-restructure-supabase.vercel.app/docs/guides/database/postgres/row-level-security-performance). No benchmarks table, and the three bullets at the top link into the RLS guide. <!-- This is an auto-generated comment: release notes by coderabbit.ai --> ## Summary by CodeRabbit * **Documentation** * Reworked the Row Level Security guide with clearer guidance on grants, policies, permissions, performance, testing, views, and secure functions. * Added a complete example for automatically enabling RLS on newly created public tables. * Improved SQL examples and clarified table references in RLS performance guidance. * Corrected grammar in the Grafana chart troubleshooting documentation. <!-- end of auto-generated comment: release notes by coderabbit.ai --> --------- Co-authored-by: Claude Opus 5 <noreply@anthropic.com> |
||
|
Miranda LimonczenkoandClaude Opus 5
|
edf50668aa |
docs(database): split RLS tuning into its own guide (#49016)
Stacked on #49015, which is stacked on #49011. Review those first. ## Problem The Row Level Security guide spent 225 lines and 5 benchmark tables on performance, 29% of the page. The `RLS Performance and Best Practices` troubleshooting entry already covers the same six tips with the same numbers, from the same source. Neither page tells you how to check whether RLS is your bottleneck in the first place. Four of the six tips are not tuning advice. Indexes, `select`-wrapping, role scoping, and `security definer` safety change whether a policy is correct and safe, not just fast. ## Solution - Add `guides/database/postgres/row-level-security-performance`. It carries the client-filter rule, the join-rewrite rule, all 5 benchmark tables merged into one, and a new `Diagnose whether RLS is the bottleneck` section: toggle RLS off to confirm it's the cost, then read the plan under an impersonated role. That diagnostic exists in the troubleshooting entry and has never been in the guide. - Keep every rule that affects correctness on the RLS guide, grouped under `Write policies that scale`. These are also the four the `build-docs-002-rls-guide` eval grades, and an agent reads the guide top-down. - Repoint the Grafana IO troubleshooting entry at the new page. - Rewrite `More resources` as `Related content`. Every link now says what it is and when to use it. Adds `Advanced pgTAP testing`, the deepest RLS testing content in the docs, which nothing here linked. Drops discussion 14576: locked, mislabeled here as "RLS Guide and Best Practices" when it is "RLS **Performance** and Best Practices", and superseded by the troubleshooting entry and this new page. **Ownership rule** so the two pages don't drift: the RLS guide owns the rule and the correct form. The performance page owns the measurement and the optimizer explanation. If a sentence on the performance page tells you what to write, it belongs on the guide. Scoped out of this PR: `More resources` was assigned to the restructure PR in the plan, but the 14576 link is what this PR supersedes, so leaving it would ship a stale pointer. ## Manual testing 1. Open the [RLS performance guide](https://docs-git-docs-rls-performance-split-supabase.vercel.app/docs/guides/database/postgres/row-level-security-performance) on the preview. It appears in the left nav under Database, Access and security, directly below Row Level Security. 2. Select the three rule links in its intro. Each lands on the matching section of the RLS guide. 3. Open the [Row Level Security guide](https://docs-git-docs-rls-performance-split-supabase.vercel.app/docs/guides/database/postgres/row-level-security) and go to `Write policies that scale`. It holds indexes, `select`-wrapping, and role scoping, with one link out to the performance page. 4. Open the [Grafana IO troubleshooting entry](https://docs-git-docs-rls-performance-split-supabase.vercel.app/docs/guides/troubleshooting/interpreting-supabase-grafana-io-charts-MUynDR) and select the RLS performance guide link. It lands on the new page. <!-- This is an auto-generated comment: release notes by coderabbit.ai --> ## Summary by CodeRabbit * **Documentation** * Added a dedicated guide for diagnosing and improving PostgreSQL Row Level Security performance. * Expanded guidance on indexing, query filters, role targeting, function usage, and avoiding costly policy joins. * Updated the Row Level Security guide with streamlined, scalable policy recommendations and links to related resources. * Added the new performance guide to the Database documentation navigation. * Updated troubleshooting guidance to reference the dedicated performance guide. <!-- end of auto-generated comment: release notes by coderabbit.ai --> --------- Co-authored-by: Claude Opus 5 <noreply@anthropic.com> |
||
|
|
45bb7c30ce |
docs(database): fix RLS guide copy and two SQL examples (#49015)
Stacked on #49011. Base is `docs/rls-revision`, so review that one first. ## Problem An audit of the Row Level Security guide against `apps/docs/CONTRIBUTING.md` and `WORD_LIST.md` turned up 4 lint warnings and 3 things that are wrong rather than just untidy. - Two SQL examples contradict the guide's own advice. The own-profile `SELECT` policy has no `TO` clause. The `security definer` example has no `set search_path`. - `## Bypassing Row Level Security` says Service Keys bypass RLS, then a note says Supabase adheres to the signed-in user's policy anyway. The condition that separates the two is never stated. - `#using-functions` is linked twice from the RBAC guide and has never existed on the RLS page. ## Solution Copy and correctness only. No section moves, no heading renames. - Replace the italic emphasis on `never` with bold. CONTRIBUTING permits **bold** for a term the reader must not miss, not italics for general emphasis. The matching fix for `must` lives in #49011, which rewrites that line anyway. - Drop marketing language from the opener, the Supabase intro, and the policies and performance leads. Removes the idiom "get the hang of them" and the filler `just`. - Replace `we` with second person in two places. - Scope the own-profile `SELECT` example with `to authenticated`. - Pin `search_path = ''` on the `security definer` example, schema-qualify its body to match, and state the requirement in prose. - State when a Service Key actually bypasses RLS. - Repoint the two RBAC links to `#use-security-definer-functions` and `#helper-functions`. `supa-mdx-lint` on the RLS guide goes from 4 warnings to 0. ## Manual testing 1. Open the [Row Level Security guide](https://docs-git-docs-rls-copy-fixes-supabase.vercel.app/docs/guides/database/postgres/row-level-security) on the preview. The own-profile SELECT example shows `to authenticated`, and the security definer example shows `set search_path = ''`. 2. Open the [RBAC guide](https://docs-git-docs-rls-copy-fixes-supabase.vercel.app/docs/guides/api/custom-claims-and-role-based-access-control-rbac) and select the "RLS helper functions" link near the end. It lands on the Helper functions section instead of the top of the page. 3. From `apps/docs`, run `pnpm lint:mdx`. The RLS guide reports no warnings. <!-- This is an auto-generated comment: release notes by coderabbit.ai --> ## Summary by CodeRabbit - **Documentation** - Updated access-control guidance with clearer links for security-definer functions and RLS helper functions. - Clarified that exposed tables require Row Level Security (RLS), while table grants and row policies provide separate controls. - Added least-privilege and grant-revocation examples, plus explanations for authorization errors. - Expanded testing guidance for CRUD policies, identity switching, and denied operations. - Improved recommendations for service keys, policy performance, indexing, and secure function configuration. <!-- end of auto-generated comment: release notes by coderabbit.ai --> --------- Co-authored-by: Claude Opus 5 <noreply@anthropic.com> Co-authored-by: Cursor <cursoragent@cursor.com> |
||
|
Miranda LimonczenkoandClaude Opus 5
|
d2ccbe5d46 |
docs(database): close the RLS guide gaps the eval flagged (#49011)
Closes DOCS-1274 ## Problem The `build-docs-002-rls-guide` eval points an agent at the Row Level Security guide with a vibe-coder prompt that never says RLS, policy, role, or test. It failed 6 of 35 checks. Each failure traces to something the guide doesn't say. - **Grants.** `anon` kept insert, update, and delete on all four to-do tables. Both client roles kept writes on the weather feed. 24 privileges untouched. - **Indexes.** Missing on `list_members.user_id`. The agent indexed the other three, so it missed the composite-primary-key case specifically. - **Tests.** No pgTAP files. `Result: NOTESTS`, so the coverage judge never ran. ## Solution - **Add a `Grants and policies` section.** - **Rewrite the opening danger admonition around revoke-then-grant.** It previously showed `grant` only, which reads as though privileges start from nothing. - **Drop the `(or primary keys)` carve-out from `Add indexes`.** A column counts as indexed only when it leads a `btree` index, shown with a composite-primary-key example. - **Add a `Test your policies` section.** Covers file location under `supabase/tests/`, `supabase test db`, role and identity switching, which assertion matches which denial, and an 11-assertion example spanning allow and deny for all four operations across `anon` and `authenticated`. Used the supacademy RLS course as a second reference. Its framing of grants running before RLS shaped the new section. ## Manual testing 1. Open the [Row Level Security guide](https://docs-git-docs-rls-revision-supabase.vercel.app/docs/guides/database/postgres/row-level-security) on the preview. `Grants and policies` and `Test your policies` appear in the table of contents. 2. Select the `Grants and policies` link at the end of the first admonition. It jumps to the new section. 3. Open the [markdown version](https://docs-git-docs-rls-revision-supabase.vercel.app/docs/guides/database/postgres/row-level-security.md), which is what agents fetch. Both new sections and the revised `Add indexes` text are present. 4. From `apps/docs`, run `pnpm lint:mdx`. The 4 warnings on this file match `master`, with no new ones. <!-- This is an auto-generated comment: release notes by coderabbit.ai --> ## Summary by CodeRabbit ## Documentation * Clarified that exposed tables must enable row-level security. * Explained the distinction between database grants and row-level security policies. * Added least-privilege examples for client roles, including read-only access. * Added pgTAP testing guidance with a complete `profiles` example. * Clarified that composite indexes support policy filters only on their leading columns. <!-- end of auto-generated comment: release notes by coderabbit.ai --> --------- Co-authored-by: Claude Opus 5 <noreply@anthropic.com> |
||
|
Kostas Botsas
|
7bfc45cc7b |
Update pg_net schema (#48694)
## 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? Docs update ## What is the current behavior? The create extension snippet defaults to public which trips the Security Advisor check "0014_extension_in_public". The extension either way creates its own "net" schema. ## What is the new behavior? Register pg_net in the extensions schema. This is also the default when installing the extension from the dashboard. <img width="425" height="224" alt="image" src="https://github.com/user-attachments/assets/160309c0-9d35-4de7-b583-32f5db310a96" /> ## Additional context When no schema is specified, defaults to public which trips the Security Advisor check: <img width="1084" height="250" alt="image" src="https://github.com/user-attachments/assets/ac5f2859-17bf-4763-9880-453b0f414b4f" /> <!-- This is an auto-generated comment: release notes by coderabbit.ai --> ## Summary by CodeRabbit * **Documentation** * Updated the pg_net installation example to place the extension in the `extensions` schema. * Clarified that this configuration keeps pg_net out of `public` and satisfies the Security Advisor check. <!-- end of auto-generated comment: release notes by coderabbit.ai --> |
||
|
Maksym Ionutsa
|
4d492db5eb |
docs: update settings links after upgrade UI move to General (#49053)
## 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? docs update - Upgrade project button and Postgres/PostgREST version checks moved from Infrastructure to General settings - Updated links across 13 docs pages to match <!-- This is an auto-generated comment: release notes by coderabbit.ai --> ## Summary by CodeRabbit - **Documentation** - Updated dashboard links throughout the documentation to direct users to **General Settings** instead of **Infrastructure Settings**. - Corrected guidance for Postgres, pgvector, pg_net, and PostgREST upgrades, configuration, and version checks. - Updated monitoring, Grafana, and Log Drains links to current documentation paths. - Fixed troubleshooting links, CLI project path examples, pg_cron terminology, and Markdown formatting. <!-- end of auto-generated comment: release notes by coderabbit.ai --> |
||
|
Tobias Pfeiffer
|
0c2b8d77b2 |
fix: Update supabase test docs to use _test.sql (#48993)
## 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? The database testing docs currently show test files using the `.test.sql` suffix, but `supabase test new` generates `_test.sql` files. Both formats work, but the generator behavior matches the previous Go CLI implementation and existing test fixtures. Update the docs for consistency with the actual generated file naming. Relevant context: [database testing docs](<https://supabase.com/docs/guides/database/testing>) and [CLI-1318](<https://linear.app/supabase/issue/CLI-1318/port-supabase-test-db-supabase-test-new>). We might want to add `supabase test new` to the docs, but that's a separate change. ## What is the current behavior? It reports `.test.sql` ## What is the new behavior? it reports `_test.sql` inline with the generator ## Additional context [slack thread](https://supabase.slack.com/archives/C07E5GFAHTM/p1786373594478619) - we can also add the test generator to the docs but I think that's a separate issue. |
