mirror of
https://github.com/supabase/supabase.git
synced 2026-09-22 13:37:53 +08:00
master
2230 Commits
| Author | SHA1 | Message | Date | |
|---|---|---|---|---|
 supabase-supabase-autofixer[bot]
|
b0bb496977 |
[bot] Sync from supabase/troubleshooting (#50656)
This PR syncs the latest troubleshooting guides from the supabase/troubleshooting repository. --------- Co-authored-by: github-docs-bot <github-docs-bot@supabase.com> Co-authored-by: Miranda Limonczenko <miranda.limonczenko@supabase.io> Co-authored-by: github-actions[bot] <41898282+github-actions[bot]@users.noreply.github.com> |
||
|
Yorvi
|
7f0f3c32b5 |
docs(troubleshooting): add realtime messages not arriving guide (#49618)
## 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? ## What is the new behavior? Realtime messages not arriving troubleshooting. ## Additional context Just a guide for customers to see why their message could not be arriving when using Realtime. <!-- This is an auto-generated comment: release notes by coderabbit.ai --> ## Summary by CodeRabbit * **Documentation** * Added a comprehensive Realtime troubleshooting guide for messages that do not arrive. * Covers connection failures, Broadcast messages, `postgres_changes`, Presence, subscription status, project settings, permissions, authentication, filters, proxies, rate limits, topics, publications, triggers, and configuration checks. * Includes diagnostic guidance for client- and database-originated events, WebSocket connections, database partitions, and Presence authorization and timing. <!-- end of auto-generated comment: release notes by coderabbit.ai --> --------- Co-authored-by: Claude Sonnet 5 <noreply@anthropic.com> Co-authored-by: Ali Waseem <waseema393@gmail.com> |
||
|
Nik 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> |
||
|
Andrew Valleteau
|
e357ec8f9f |
docs(cli): update local development workflow docs for pg-delta default diffing (#49280)
## 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? Linear: [CLI-1618](https://linear.app/supabase/issue/CLI-1618/update-cli-workflow-docs-for-pg-delta-default-diffing) Four docs pages lag the shipped CLI behavior now that `pg-delta` is the default diff engine for projects created by a recent `supabase init`: - **CLI workflows** claims `db diff` compares `supabase/schemas/` against migrations. Under `pg-delta`, declarative files are never the `db diff` baseline (and `[db.migrations].schema_paths` no longer changes it) — the declarative flow goes through `supabase db schema declarative sync`. The cleanup guidance describes `migra`-era output. - **Declarative database schemas** teaches the old `db diff -f` + `schema_paths` flow throughout, and its known-caveats list is the `migra` issue list. - **Managing environments** still presents `--use-migra` as an "experimental flag" for a "more concise" diff — inverted now. - **Backup and restore (migrating within Supabase)** and the CLI workflows guide both steer users to `db diff`/`db pull` with `--schema auth,storage`. Under `pg-delta`, `--schema` layers an extra exclude policy on top of the Supabase profile: it can only narrow a diff, never re-include managed schemas, and managed-schema selections can even fail closed (e.g. `--schema auth` when a trigger function lives in `public`). Unfiltered diffs are the supported path. ## What is the new behavior? All claims verified against the CLI source at current `develop` — including supabase/cli#6300, which upgraded the engine to `@supabase/pg-delta` 1.0.0-alpha.46 — against the pinned pg-delta package source (profile rules, format defaults, coverage doc), and against a live dogfood run of the documented workflows on `develop` `38f31b4` (two OSS corpus projects, warm shadow cache). - **`cli-workflows.mdx`**: adds a "Which diff engine you're on" note (`pg-delta` for new `supabase init` projects, `migra` for existing ones until they opt in by adding `[experimental.pgdelta] enabled = true`; per-run fallbacks `--use-migra` on `db diff` / `--diff-engine migra` on `db pull`); corrects `db pull` and `db diff` mechanics (shadow built from migrations vs. live database; the baseline history record is offered, not unconditional); switches the declarative flow to `supabase db schema declarative sync`; reworks the cleanup section around pg-delta output (uppercase keywords at max width 180, `format_options`, per-unit migration files with numeric segment suffixes, the `-- pg-delta: transaction=false` directive on genuinely non-transactional files, engine-neutral grant/revoke review guidance, coverage warnings + `--strict-coverage`); documents what pg-delta captures in managed schemas (user triggers, RLS policies on `auth` tables and on `storage.objects`/`storage.buckets`/`realtime.messages`) versus what it doesn't; adds key-command rows for the declarative commands and troubleshooting entries (`db pull` non-zero exit when in sync, the `schema_paths` warning, `PGDELTA_DEBUG=1` bundles under `supabase/.temp/pgdelta/v2/debug/`). - **`declarative-database-schemas.mdx`**: swaps `db diff -f` for `db schema declarative sync -f` throughout; replaces lexicographic/`schema_paths` ordering guidance with automatic dependency ordering and the `generate` export layout (`_cluster/`, reserved `_custom/`); bootstraps from production via `db schema declarative generate --linked` (explicit target + `--overwrite` in scripts) and refreshes via `db pull --declarative`; rewrites known caveats for pg-delta (DML including storage buckets, untracked object kinds + the `_custom/` escape hatch, managed schemas, extension-managed objects, and the two gates when adopting an existing schema tree: `[experimental.webhooks]` for `pg_net` migrations and declaring the tree's extensions) keeping the `migra` workflow and issue list under a legacy section for projects that haven't enabled it. - **`managing-environments.mdx`**: frames the verbose grant sample as legacy-engine output, notes that generated migrations can include grant statements on any engine, describes `--use-migra` as a single-run fallback, and adds a `db diff --strict-coverage` CI step. - **`backup-restore.mdx`**: replaces `db diff --linked --schema auth,storage` with a plain `db diff --linked` on `pg-delta` (keeping the `--schema auth,storage` form for the legacy engine) and explains what the engine includes (user triggers on managed tables, user RLS policies on `auth`, `storage.objects`/`storage.buckets`/`realtime.messages`) and what must be recreated manually. - **New `diff-engines.mdx` page** (from #49889): the single home for how the engine is selected, a behavior matrix for `pg-delta` versus `migra`, the per-command fallback flags, a procedure for switching an existing project (the first `db pull` after enabling may write a catch-up migration), and how to go back with `enabled = false`. Registered in navigation. A shared `diff_engine_check` partial replaces the inline engine parentheticals across seven pages, and a `managed_schemas_diff_capture` partial carries the managed-schema capture rules. - **CLI reference (`cli_v1_commands.yaml`, `cli_v1_config.yaml`)**: `db pull`, `db schema declarative sync`/`generate` flags and descriptions, `experimental.pgdelta.*` and `db.migrations.schema_paths` config keys, and the `db diff` description updated to describe both engines. Note that `cli_v1_commands.yaml` is generated from the CLI repo; [supabase/cli#6557](https://github.com/supabase/cli/pull/6557) carries the matching `db pull` example and overlay text so the next publish keeps it. - **`examples/prompts/declarative-database-schema.md`**: rewritten for the `db schema declarative sync` flow, with the `[experimental.pgdelta]` prerequisite. ## Additional context The first draft was written against pg-delta 1.0.0-alpha.42. supabase/cli#6300 (engine upgrade to alpha.46) then changed two documented behaviors, both reflected here: generated SQL now defaults to uppercase pretty-printed keywords, and user RLS policies on `storage.objects`/`storage.buckets`/`realtime.messages` are included via the engine's `SUPABASE_USER_POLICY_SURFACES` allowlist. A follow-up dogfood run on `develop` `38f31b4` then falsified three more claims (pg-delta emits no grant noise, `_schema_changes`/`_after_enum_values` multi-file names, directive on every split file), all corrected in the last commit. **Update (Sep 14 to 17):** [#49889](https://github.com/supabase/supabase/pull/49889) and [#50220](https://github.com/supabase/supabase/pull/50220) were merged into this branch, so this PR now carries the full stack. #50220 corrected the `schema_paths` warning wording (the CLI warns only when the setting lists paths), added `auth` RLS policies to the managed-schema partial, and described the migra initial pull accurately (the `pg_dump` skips managed schemas and the migra diff pass that follows appends the trigger and policy changes). It also reframed `pg-delta` as the default for every project ahead of supabase/cli#6391. That plan changed: no breaking default flip before Select, so [#50332](https://github.com/supabase/supabase/pull/50332) restores the opt-in framing (`pg-delta` requires `[experimental.pgdelta] enabled = true`, which `supabase init` writes for new projects) and also resolves the four CodeRabbit findings from the latest review round. Two claims are pending confirmation from the owning teams: that branching runs every migration in a transaction and ignores the `-- pg-delta: transaction=false` directive, and the `--db-url` pooler-versus-direct connection advice, which currently disagrees with the CLI's own `db pull` docs. Stale spots found in the CLI repo's own docs while verifying (out of scope here, worth follow-ups): four `SIDE_EFFECTS.md` files still claim lowercase output, `docs/supabase/db/diff.md` still lists `migra`-era "known failure cases" that alpha.46 fully models, the `supabase init` template's commented `format_options` example shows `maxWidth: 80` against an actual default of 180, and the CLI upgrade recipe appends `--experimental` even when the config already enables pg-delta. 🤖 Generated with [Claude Code](https://claude.com/claude-code) https://claude.ai/code/session_01SUuaVmXLRbV6tZjzhka3cp <!-- This is an auto-generated comment: release notes by coderabbit.ai --> ## Summary by CodeRabbit * **Documentation** * Clarified `pg-delta` and legacy `migra` behavior, configuration, and switching guidance. * Expanded declarative schema workflows, including synchronization, migration generation, baselines, deployment, and legacy-engine support. * Documented managed schemas, permissions, extensions, transaction handling, dependency ordering, and troubleshooting. * Added guidance for strict coverage checks, output directories, non-interactive workflows, and declarative pull modes. * Added a dedicated diff engines guide and updated CLI navigation, backup and restore, branching, deployment, and CI documentation. <!-- end of auto-generated comment: release notes by coderabbit.ai --> --------- Co-authored-by: Claude <noreply@anthropic.com> Co-authored-by: Wen Bo Xie <wenbox323@gmail.com> |
||
|
Riccardo Busetti
|
ced974e073 | docs(pipelines): Align and streamline replication guides (#49252) | ||
|
Miranda Limonczenko
|
36749659e6 |
docs(functions): answer the recurring secrets questions from reader feedback (#50422)
Five reports on this page, four of them the same confusion: which .env file does what. Where local values come from is a new section listing the files that feed a local environment: supabase/functions/.env, a file you name yourself, the root .env that config.toml reads through env(), and [edge_runtime.secrets]. It says a value in one is not a value in the other. That is what CLI-818 asked for in as many words, the duplication FDBKIN-11884 complains about, and the config route FDBKIN-12716 raises. It sits with the other reference section rather than inside the local procedure, because it answers what the parts are rather than how to do something. Accessing environment variables splits into an Edge Function and a Deno script you run yourself, where neither env file applies. Deno.env.get needs --allow-env, so both commands pass it; without the flag the script prompts, and fails outright when nothing is there to answer. FDBKIN-7937. Production secrets now states who can set one, and the reserved prefix. Also calls Deno.env.get a method rather than a handler, which is what it is. The wording came in with the style pass at the bottom of the stack; fixing it here avoids restacking four branches for one word. Two claims from the source reports are deliberately not here. FDBKIN-34962 reports that adding a secret requires OWNER. The access control matrix in guides/platform/access-control.mdx says Owner or Administrator can create and delete, and Developer can view. The reporter found their version by external searching, so the page states what our own matrix says. supabase/agent-skills#452 reports that a secret value cannot be recovered after saving. SecretResponse_Output in the Management API spec returns value as a required field, and the Dashboard renders it, so that does not hold up from what I can check here. Left out rather than guessed at; the issue stays open. The reserved prefix is not a third-party host restriction as supabase/agent-skills#553 frames it. CreateSecretBody carries pattern ^(?!SUPABASE_).*, AddNewSecretForm.tsx:42 rejects the same, and the CLI filters SUPABASE_-prefixed names out of the local function environment. It is ours, and the page says so. |
||
|
Miranda Limonczenko
|
06aafbae4b |
docs(functions): give local secrets a procedure that produces a working key (#50420)
The Managing secrets guide is the only place that tells you where a local secret has to sit for the Edge Function runtime to load it. Neither the supabase agent skill nor Supacademy covers it. The page named supabase/functions/.env once, in prose, and never had the reader create it. The eval in supabase/evals#285 reproduces what that produces: across three runs on codex-gpt-5.6-luna-no-skills, every run built a function reading its key from the environment, started the stack, and answered missing_api_key. Two of the three wrote supabase/functions/.env.example and stopped, which is a template with the variable name in it rather than the file the runtime reads. Local secrets is now a five-step procedure that creates the file with a working value, ignores it, creates the function that reads the key, starts the stack, and calls the function to confirm. That last step is the one that tells the reader whether it worked. The function is created before the stack starts, so a reader following the steps literally from a fresh project has something to call. The gitignore instruction moved out of its admonition and into step 2, carrying its consequence with it. It's an instruction the reader has to follow, so it belongs in the procedure rather than beside it. Recovery for a variable the function can't see gets its own section rather than trailing the procedure. "I set it and the function cannot read it" is the most repeated shape in the feedback on this page, and as loose sentences mid-section it had no entry in the table of contents. |
||
|
Miranda Limonczenko
|
7012ba4a55 |
docs(functions): regroup the secrets guide by information type (#50419)
Moves and heading levels only. No claims changed. Studio renders a Docs button at apps/studio/pages/project/[ref]/functions/secrets.tsx:43 pointing at #using-the-cli, but "Using the CLI" was bold text rather than a heading, so the anchor had no target and the button dropped the reader at the top of the page. It and "Using the Dashboard" are now real headings, which repairs it. Local secrets and Production secrets were h3 under "Accessing environment variables", but neither is about accessing one. Both are now h2 siblings, and the reference list moved to the end, so the page runs procedures first and facts last. Sections are ordered by what the reader is doing, not by subject: set a secret locally, read it in code, then set it in production. "Accessing environment variables" sat after production, which put the reading step after the shipping step. Local secrets held a two-item list of the loading mechanisms, which is a fact sitting inside a procedure. It is now the section's opening sentence, where a one-line fact can qualify the procedure without interrupting it. Every existing heading text is unchanged, so #default-secrets, #local-secrets, #production-secrets and #accessing-environment-variables all still resolve. Added a value statement opener, and an outcome after the production procedure. No intro outline: the page is short and its headings already scan. The frontmatter title was title case. Renaming it to sentence case moves a navigation label and a search entry, so the nav entry and the three pages that used the old title as link text change with it. The slug is untouched. |
||
|
Miranda Limonczenko
|
82e9f6fb0e |
docs(functions): tighten the voice in the secrets guide (#50418)
Style only. No heading moves and no claim changes. The page carried the same caution admonition twice, word for word, and explained the local .env loading rules twice more: once as a list of the two mechanisms, then again as a pair of serve commands with the same prose around them. Both copies are gone, along with the trailing line about managing different environments that restated the --env-file bullet. The rest is voice. First person became second, future tense became present, and "allows you to" became a sentence with the reader as its subject. SB_REGION and SB_EXECUTION_ID had lost words. The two NEVER shouts became bold, per the emphasis rule. The alt text named the topic the heading already names. It now describes the Key and Value fields, the reveal and remove controls, and the Add another and Save buttons, which is what a reader who can't see the screenshot needs. Dropped the item count ahead of the local loading list, and made that list unordered, because the two mechanisms are alternatives rather than steps. |
||
|
Tina Ha
|
f69195f9df |
docs: fix numbered list rendering in secrets-limit troubleshooting doc (#50479)
## Summary - #50366 added a numbered "How to fix" list, but the fenced code blocks and follow-up paragraphs between items 1/2/3 weren't indented under their list markers, so each numbered item parses as its own single-item list per CommonMark's list-continuation rules — the rendered doc shows "1, 1, 1" instead of "1, 2, 3". - Indents the code fences and paragraphs so they attach to their list item, keeping the whole "How to fix" section as one ordered list. No content changes — purely a list-structure/indentation fix so the doc renders correctly. ## Test plan - [ ] Preview the docs page and confirm "How to fix" renders as 1, 2, 3 <!-- This is an auto-generated comment: release notes by coderabbit.ai --> ## Summary by CodeRabbit - **Documentation** - Updated the troubleshooting guide with clearer Markdown and TypeScript code formatting for secret configuration and retrieval examples. - Clarified how to set grouped credentials, handle missing secret values, and access parsed keys individually. - Documented behavior remains unchanged: grouped credentials count as one secret, and missing `API_KEYS` values produce an error. <!-- end of auto-generated comment: release notes by coderabbit.ai --> |
||
|
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 --> |
||
|
krishnasaivandavasi
|
51b6908236 |
tsguide(realtime): add guide to isolate client vs server issues (#49933)
## 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? Troubleshooting docs addition. ## What is the current behavior? This is troubleshooting documentation on how to diagnose missing real-time messages and isolate whether it is a client-side or server-side issue. ## What is the new behavior? Adds a step-by-step troubleshooting guide for Realtime. This helps check isolate connection and message delivery issues using:? Realtime Inspector: to confirm server-side dispatch. Browser DevTools: to confirm client-side receipt via WebSockets. <!-- This is an auto-generated comment: release notes by coderabbit.ai --> ## Summary by CodeRabbit * **Documentation** * Added a Supabase Realtime troubleshooting guide for isolating server-side, client-side, and network-related subscription issues. * Covers Realtime Inspector checks for subscriptions, broadcasts, and presence; authorization and RLS validation; client configuration; WebSocket traffic in browser developer tools; network connection verification; and preparing diagnostic details for Support. <!-- end of auto-generated comment: release notes by coderabbit.ai --> --------- Co-authored-by: Ali Waseem <waseema393@gmail.com> Co-authored-by: copilot-swe-agent[bot] <198982749+Copilot@users.noreply.github.com> Co-authored-by: krishnasaivandavasi <241076000+krishnasaivandavasi@users.noreply.github.com> |
||
|
Ł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 Ionutsa
|
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> |
||
|
Maksym Ionutsa
|
fe0afd66b8 |
docs(cron): document how to clean up cron.job_run_details (#50211)
cron.job_run_details grows unbounded and is never pruned automatically, even after a job is unscheduled. Add an example that schedules a daily cleanup job, and link it from the existing disk-usage caution. ## 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 mention of the _necessary_ regular cleanups ## What is the new behavior? This is now explicitly called out with a weekly clean-up example <img width="1620" height="654" alt="CleanShot 2026-09-10 at 11 41 25@2x" src="https://github.com/user-attachments/assets/2f78a051-5994-4f8a-95c2-c96c64679bed" /> <!-- This is an auto-generated comment: release notes by coderabbit.ai --> ## Summary by CodeRabbit - **Documentation** - Updated the cron quickstart guide with guidance on cleaning up job run history. - Added an example showing how to schedule a daily cleanup job that removes records older than seven days. <!-- end of auto-generated comment: release notes by coderabbit.ai --> |
||
|
Lukas Bernert
|
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> |
||
|
Lukas Bernert
|
055cc7b956 |
docs: state disk limits as per-size minimums, align burst copy (#50016)
## What kind of change does this PR introduce? Docs update: states disk limits as per-size minimums and aligns burst copy across pages. Follow-up to #49996 (compute descriptions). Fixes PROD-658 ## What is the current behavior? - The disk limits table and surrounding prose describe a narrower set of configurations than a compute size can run on - Burst thresholds are inconsistent across pages (three different variants), and one section contradicts itself - Burst is described as CPU behavior, when the burst users observe is disk IO ## What is the new behavior? - `shared-data/compute-disk-limits.ts`: Medium baseline throughput adjusted to 39 MB/s: the lowest value across configurations - `compute-and-disk`: disk limits presented as minimums ("at least"); burst described as disk IO drawing on a disk IO budget; consistent thresholds: burst available up to 2XL, baseline equals maximum from 8XL - Troubleshooting guides (`exhaust-disk-io`, `failed-to-retrieve-tables`, `interpreting-supabase-grafana-io-charts`) aligned to the same threshold; `failed-to-retrieve-tables` keeps the ~30-minutes-per-day burst window with the corrected size range - Section anchors unchanged ## Self-review - Values verified against the AWS EBS-optimized performance data (`describe-instance-types`) for every configuration per size; content cross-checked with the internal runbooks (linked in PROD-658) - `supa-mdx-lint`: no findings in changed files - `pnpm build:guides-markdown` clean; generated `.md` exports show the new values and prose - All changed pages verified rendering in the local dev app - `pnpm typecheck` passes (shared-data + docs) - Note: `compute-disk-limits.ts` also feeds Studio (disk validation, IO budget tooltips). The only value change (Medium 43 → 39 MB/s) surfaces there as one chart tooltip label; conservative direction. <!-- This is an auto-generated comment: release notes by coderabbit.ai --> ## Summary by CodeRabbit - **Documentation** - Clarified the differences between shared and dedicated CPU resources. - Updated disk I/O guidance to explain baseline and burst limits as minimums. - Documented disk I/O bursting for compute sizes up to 2XL, including expected duration and limitations. - Clarified that 8XL and larger compute sizes have consistent performance without burst capacity. - Updated the documented baseline throughput for medium compute resources. <!-- end of auto-generated comment: release notes by coderabbit.ai --> |
||
|
Wen Bo Xie
|
20d09b4a72 |
docs(auth): clarify OAuth 2.1 server pricing is included in Auth MAUs (#49753)
OAuth 2.1 server had a single pricing statement anywhere, and it said the feature is free during beta. This states the actual model everywhere the feature is documented or sold: there is no separate charge, and users who sign in through the OAuth server count toward Auth MAUs. - docs getting started: replace the "free during beta" sentence with the MAU-based pricing statement - docs overview: add a Pricing section linking to the MAU usage guide and the pricing page - docs MCP authentication: note that agents authenticate as existing users, and MAUs count per distinct user, so multiple agents for one user count once - www pricing comparison table: add an "OAuth 2.1 Server" row (included on all plans) with a tooltip, and extend the MAU tooltip to cover OAuth server sign-ins <!-- This is an auto-generated comment: release notes by coderabbit.ai --> ## Summary by CodeRabbit * **Documentation** * Clarified that OAuth 2.1 Server is available on all plans without a separate charge. * Explained that OAuth sign-ins count toward Monthly Active Users (MAUs), with multiple agents for one user counted once. * Added links to MAU and pricing guidance. * **Pricing** * Added OAuth 2.1 Server as a plan feature and updated billing descriptions for greater clarity. <!-- end of auto-generated comment: release notes by coderabbit.ai --> |
||
|
Saxon Fletcher
|
91e23a0f2d |
docs: define detection checks and specialist monitoring prompts (#50075)
## 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? Specialist monitoring prompts leave some comparison windows, baselines, thresholds, and missing-data behavior undefined. This can produce reports or forecasts without sufficient evidence. ## What is the new behavior? Detection checks define inputs, comparison windows, thresholds, units, missing-data behavior, and next investigation steps. Query regressions require comparable snapshots and reset history; capacity forecasts require saved measurements and a matching confirmed limit. Health, Security, Performance, and Capacity prompts fetch and follow the shared detection checks automatically. They record finding, clear, or unable to assess, preserve alert state, and suppress unchanged repeats. Missing history or failed access cannot become a healthy result. Specialist pages retain their diagrams and the sections What it watches, When it watches, What it will output, and Set up the agent. Setup explains the necessary documentation access and saved state; optional links explain report triggers. Prompt and provider setup tabs remain available in HTML and Markdown. The Hire an agent overview and Generalist page and prompt remain unchanged. Prompt Markdown exports use the Markdown serializer to safely contain nested code fences, preserving the full Generalist prompt and its SQL examples. Both prompt exporters have parser-based round-trip coverage. ## Additional context Full docs suite: 215 passed, 2 skipped against a freshly reset disposable Supabase stack. Typecheck, targeted ESLint, formatting, and guides Markdown generation also pass after the export fix. Earlier validation: production docs build, docs typecheck, targeted ESLint, formatting, and guides Markdown generation pass. All four specialist exports contain their diagrams, setup sections, enhanced prompts, and provider instructions. The Health page diagram and setup tab were checked in the browser. Changed pages have no MDX lint violations; existing repository-wide violations remain. The unchanged detection SQL was previously smoke-tested in a disposable sandbox. Hosted MCP runs, scheduler persistence, notifications, and agent evals are outside this validation. Evals remain outside this change. Stage 3 of 3; depends on stage 2. Stack: #50073 → #50074 → #50075. <!-- This is an auto-generated comment: release notes by coderabbit.ai --> ## Summary by CodeRabbit - **Documentation** - Reworked observability guidance around hourly, read-only monitoring checks. - Updated health, security, performance, and usage monitors to identify new findings, data gaps, regressions, and resource growth. - Added clearer setup instructions for linked documentation, saved measurements, and alert state. - Replaced the issue-detection guide with standardized outcomes: finding, clear, or unable to assess. - Added explicit thresholds, evidence details, investigation links, and verification steps for turning detections into diagnoses. - **Improvements** - Standardized monitoring prompts and presentation across supported agent types. <!-- end of auto-generated comment: release notes by coderabbit.ai --> --------- Co-authored-by: Claude Opus 5 <noreply@anthropic.com> |
||
|
Miranda Limonczenko
|
e8547352c5 |
docs(auth): answer the four most repeated SSR auth questions (#50289)
Closes DOCS-1313 Closes FDBKIN-4573 Closes FDBKIN-15214 Closes FDBKIN-10628 ## Problem Four asks come up repeatedly in feedback intake. The Eval is green and this feedback cannot be included in the Eval. Using the Evals work as an excuse to action on the feedback. 😄 Readers can't tell which auth call verifies a token and which only reads stored state. They don't know that the response the cookies were written to is the response they have to return, because that only ever existed as a code comment. Nobody is warned that refreshing in two places burns a single-use refresh token, which surfaces as users being signed out at random. And nothing in `apps/docs` says `proxy.ts` is Next.js 16 and later, so a reader on 15 writes a file the framework never calls. ## Solution - Add the fact that `getClaims()` refreshes a session close to expiring before it verifies. It was only in the typedoc remarks, and it is what makes the double refresh warning make sense. - Say that `setAll` rebuilds `supabaseResponse` on every write, so a response built earlier is stale, and show how to copy the cookies onto a different one. - Warn that a second refresh outside the reuse window revokes the session, linking refresh token reuse detection. - Note that `proxy.ts` is Next.js 16 and later, and that the file is `middleware.ts` before that. - Name the file in the proxy fence in `examples/prompts/nextjs-supabase-auth.md`, which gave agents the export name and no path. The auth methods partial is shared by five other pages, so that first change surfaces there too. ## Manual testing 1. Open the [SSR client guide](https://docs-git-docs-ssr-client-feedback-supabase.vercel.app/docs/guides/auth/server-side/creating-a-client) on the deploy preview. The Next.js panel carries the version note, the refresh warning, and the response guidance. 2. Select the refresh token reuse detection link. It resolves to the sessions guide. 3. Open the [Next.js Auth prompt](https://docs-git-docs-ssr-client-feedback-supabase.vercel.app/docs/guides/ai-tools/ai-prompts/nextjs-supabase-auth). The proxy section names the file and says it is `proxy.ts` on Next.js 16 and later. <!-- This is an auto-generated comment: release notes by coderabbit.ai --> ## Summary by CodeRabbit ## Documentation - Clarified that `getClaims` refreshes sessions when access tokens are near expiration, helping server-rendered sessions remain active. - Expanded Next.js SSR guidance for session-refresh setup, including file placement and version-specific naming. - Added warnings about refresh-token reuse and session revocation after repeated refreshes outside the reuse window. - Added guidance for preserving authentication cookies and cache-related headers when returning updated responses. - Clarified that refreshed tokens should be passed to Server Components to keep sessions active. - Clarified the required session-refresh handler export and example filename. <!-- end of auto-generated comment: release notes by coderabbit.ai --> |
||
|
Miranda Limonczenko
|
a4106b01f5 |
docs(auth): correct what getClaims verifies, and fix the Express env setup (#50288)
## Problem These findings came from a technical audit and verification of the claims in the doc. I found two accuracy problems: - **The guide said `getClaims()` is safe to trust** because it "validates the JWT signature against the project's published public keys every time". That only describes projects on asymmetric signing keys. With a symmetric secret it calls the Auth server instead, which the page's own partial already said. The advanced guide then read as a flat contradiction: `getUser()` was "the only way" to know a session is valid. The real distinction is revocation, not verification. - **Running the Express sample verbatim doesn't work.** In the docs sandbox, it printed `SUPABASE_URL = undefined`, so `createServerClient` received undefined for both the URL and the key. The env var tab installed dotenv twice, once inline and once through the package manager tabs, and its "And initialize it" lead-in was followed by the second install rather than any initialization. The route sample then required dotenv without calling `config()`. ## Solution - Say what `getClaims()` verifies against in each signing key mode. - Reframe the advanced guide's `getUser()` answer around session revocation, so the two pages stop contradicting each other. - Switch the advanced guide's two middleware snippets from `getUser()` to `getClaims()`, matching the guide. - Rename its `Next.js middleware` heading and CloudFront bullet, which the proxy rename missed. - Load dotenv on the first line of the Express entry point, and drop the duplicate install. - Tag both Express fences `js`. They are CommonJS, not TypeScript. - Update the stale "middleware refreshing user sessions" comment in the rendered Next.js `server.ts` sample. ## Manual testing 1. Open the [SSR client guide](https://docs-git-docs-ssr-client-accuracy-supabase.vercel.app/docs/guides/auth/server-side/creating-a-client) on the deploy preview, then the Express tab. dotenv is installed once, followed by `require('dotenv').config()`. 2. Open the [advanced guide](https://docs-git-docs-ssr-client-accuracy-supabase.vercel.app/docs/guides/auth/server-side/advanced-guide). The Next.js heading reads `Next.js proxy` and both snippets call `getClaims()`. Part of DOCS-1313. <!-- This is an auto-generated comment: release notes by coderabbit.ai --> ## Summary by CodeRabbit - **Documentation** - Clarified the difference between token validation and detecting revoked server-side sessions. - Updated Next.js guidance and examples to use “proxy” terminology. - Refined CloudFront caching guidance for authenticated routes. - Improved Express setup instructions, including dotenv loading and JavaScript examples. - Expanded explanations of signing-key verification. - Updated Astro and Nuxt examples to forward cache headers correctly. - Updated session-refresh guidance in the Next.js example to reference the proxy. <!-- end of auto-generated comment: release notes by coderabbit.ai --> |
||
|
Miranda Limonczenko
|
7bec687917 |
docs(auth): regroup the SSR client guide and cut repetition (#50287)
## Problem `_partials/auth_methods.mdx` was included six times in this one page. Radix unmounts inactive tab panels, so a browser reader sees it three times on the default Next.js view, and the generated markdown that agents read contained all six. That was about 25% of the 33.5 KB export, and it put the same `Summary of the methods` heading in the table of contents three times over. The page is also 900+ lines with no intro outline, the per-framework recaps were `h2` inside an `h2` section, and six of the nine panels had no step headings at all. ## Solution - Include the auth methods partial once, under a new `Choosing an auth method` section grouped with `Caching considerations`, and point to it from the procedure. This follows the mixed information types rule in `apps/docs/CONTRIBUTING.md`. - Add an intro outline linking the section groups and saying when to read the two reference sections. - Demote the eight in-tab `Congratulations` headings to `h3` so they nest under `Create a client`. - Add a `Create the Supabase clients` heading to Astro, Remix, Nuxt, React Router, Express, and Hono, and the recap Hono was missing. No claims changed here, only placement. ## Manual testing 1. Open the [SSR client guide](https://docs-git-docs-ssr-client-structure-supabase.vercel.app/docs/guides/auth/server-side/creating-a-client) on the deploy preview. The table of contents lists `Summary of the methods` once. 2. Select each of the five links in the intro paragraph. Each one scrolls to its section. 3. Select each framework tab. Every panel has a step heading and a recap. Part of DOCS-1313. <!-- This is an auto-generated comment: release notes by coderabbit.ai --> ## Summary by CodeRabbit - **Documentation** - Added an introductory setup overview covering installation, environment variables, client creation, authentication methods, and caching. - Added dedicated guidance for choosing an authentication method. - Added Astro SSR and client sections, along with a complete Hono recap. - Reorganized framework headings for clearer navigation. - Consolidated authentication guidance by removing duplicate content from individual framework sections. <!-- end of auto-generated comment: release notes by coderabbit.ai --> |
||
|
Miranda Limonczenko
|
cf5bf65361 |
docs(auth): tighten the voice in the SSR client guide (#50286)
## Problem
The SSR client guide, like all guides, have drifted from our style rules
and writing best practices.
This PR is to do an inline edit without re-arranging any sections.
## Solution
- Open with what the guide does, then the SSR context.
- Delete the `{/* TODO: Can this be consolidated? */}` comment.
- Remove the three em dashes and the parenthetical asides in prose.
- Rewrite the Next.js danger callout to lead with the consequence:
anyone can forge the session cookie.
- Give Astro, Remix, Nuxt, React Router, and Express the same bulleted
recap Next.js, SvelteKit, and TanStack already had.
## Manual testing
1. Open the [SSR client
guide](https://docs-git-docs-ssr-client-style-supabase.vercel.app/docs/guides/auth/server-side/creating-a-client)
on the deploy preview. The first sentence says what the guide does.
2. Select each framework tab. Every panel ends with a bulleted recap.
Part of DOCS-1313.
<!-- This is an auto-generated comment: release notes by coderabbit.ai
-->
## Summary by CodeRabbit
- **Documentation**
- Updated server-side authentication guidance across supported
frameworks.
- Clarified cookie-based session storage, SSR package usage, and
cache-header handling.
- Added guidance on protecting against forged cookies and verifying
sessions with `getClaims()`.
- Expanded framework setup and authentication flow summaries for Astro,
Remix, Nuxt, React Router, Express, and TanStack Start.
- Clarified TanStack route protection, redirects, and server-side
authorization requirements.
<!-- end of auto-generated comment: release notes by coderabbit.ai -->
|
||
|
Inder Singh
|
8dc9206f56 | docs(self-hosted): add custom oauth providers guide (#49971) | ||
|
Maksym Ionutsa
|
795b67b611 |
Docs/clone project r2np clarifications (#50471)
## 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? r2np docs clarifications to https://supabase.com/docs/guides/platform/clone-project ## What is the new behavior? <img width="910" height="692" alt="image" src="https://github.com/user-attachments/assets/41026106-48c6-48bf-aca3-d2ff982c938d" /> <!-- This is an auto-generated comment: release notes by coderabbit.ai --> ## Summary by CodeRabbit * **Documentation** * Updated project restore guidance to clarify that binary restores copy the entire database and may immediately run extensions, scheduled jobs, webhooks, and wrappers. * Added guidance for using logical restores when definitions need inspection or removal beforehand. * Documented that manual dead-tuple recovery is unsupported due to potential constraint violations and data corruption. * Added recommended recovery paths for deleted rows using physical backups or point-in-time recovery. <!-- end of auto-generated comment: release notes by coderabbit.ai --> --------- Co-authored-by: github-actions[bot] <41898282+github-actions[bot]@users.noreply.github.com> |
||
|
supabase-supabase-autofixer[bot]
|
127e21b926 |
Changes by create-pull-request action (#44860)
Automated changes by [create-pull-request](https://github.com/peter-evans/create-pull-request) GitHub action Co-authored-by: ivasilov <568291+ivasilov@users.noreply.github.com> |
||
|
Saxon Fletcher
|
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> |
||
|
Saxon Fletcher
|
232ce7e68c |
docs: focus Logs on the unified view and export queryable fields (#50073)
## 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 and a small Studio copy correction. ## What is the current behavior? The Logs guide mixes unified filtering with retired SQL Explorer instructions, and the Markdown field reference loses query semantics. ## What is the new behavior? The Logs guide mixed filtering and event inspection with the retired SQL Logs Explorer workflow. It now documents the unified Logs view: default sources, filter semantics, event details, Live, sharing, bounded exports, and missing results. The log field reference uses one mapping for HTML and Markdown, preserving source IDs, query expressions, and source/query types. The Studio User-filter empty state and comments now match its Auth and API Gateway scope. ## Additional context Validation: shared-field mapping tests, guides Markdown generation, docs typecheck, targeted docs/Studio ESLint, formatting, and browser inspection of the field table. Exported Markdown includes the source IDs and usable ClickHouse expressions. Repository-wide MDX lint has existing failures; changed pages have no reported violations. Self-review: hosted Studio filtering and log ingestion were checked against the implementation, not exercised against a hosted project. The documentation assumes the unified Logs experience is the default. Stage 1 of 3. Review and merge from the bottom of the stack. Stack: #50073 → #50074 → #50075. Production docs build also passes at the stack tip after standard reference generation. Initial CI note: the spelling action failed while building its container because Debian package downloads returned 404, before checking content. The stack has no merge conflicts. <!-- This is an auto-generated comment: release notes by coderabbit.ai --> ## Summary by CodeRabbit * **Documentation** * Expanded the log field reference with ClickHouse fields, nested-field query examples, types, schema references, and capture limits. * Reworked the Logs guide with clearer instructions for filtering, event inspection, live mode, sharing, exports, retention, and missing results. * Clarified service and Postgres log behavior and updated navigation and metadata. * **Bug Fixes** * Corrected user-filtering guidance and empty-state messaging to identify Auth and API Gateway logs as supported sources. <!-- end of auto-generated comment: release notes by coderabbit.ai --> --------- Co-authored-by: Steven Eubank <eubank.steven88@gmail.com> Co-authored-by: Steven Eubank <47563310+smeubank@users.noreply.github.com> |
||
|
Tina Ha
|
86f38f97c8 |
docs: add troubleshooting entry for the Edge Function secrets limit (#50366)
## Summary - No public doc previously covered what to do when a project hits the 100-secret cap for Edge Functions. Adds a troubleshooting entry documenting the JSON-bundling workaround. - Cross-links the new entry from the Secrets section of `functions/limits.mdx`. ## Sourcing / context - Internal Slack (Jul 2): https://supabase.slack.com/archives/C02KMRX22NR/p1783003062600709?thread_ts=1783002978.740289&cid=C02KMRX22NR — workaround first suggested (Kalleby). - Internal Slack (Aug 19): https://supabase.slack.com/archives/C0BMQHEU6N6/p1787139772204509?thread_ts=1787098919.509189&cid=C0BMQHEU6N6 — functions team reconfirms no override path exists; workaround independently recommended again. - The JSON-bundling pattern mirrors how Supabase's own default secrets already work (`SUPABASE_PUBLISHABLE_KEYS` / `SUPABASE_SECRET_KEYS` in `functions/secrets.mdx`), so this isn't a novel pattern for the platform. - Prompted by support ticket SU-473846. ## Test plan - [x] `pnpm --filter docs lint:mdx` passes with no warnings on either changed file - [ ] New page renders correctly under `/docs/guides/troubleshooting` - [ ] Link from `functions/limits.mdx` resolves <!-- This is an auto-generated comment: release notes by coderabbit.ai --> ## Summary by CodeRabbit - **Documentation** - Added guidance for working around the 100-secret Edge Functions limit by bundling related credentials into a single JSON secret. - Documented JSON secret setup, parsing, replacement behavior, shell quoting, environment files, and the 48 KiB per-secret size limit. - Clarified that JSON bundling does not bypass the per-secret size limit. - Explained when to use Supabase Vault for row- or user-specific secrets, including database round trips and potential latency. - Linked the workaround guide from the Edge Functions limits documentation. <!-- end of auto-generated comment: release notes by coderabbit.ai --> --------- Co-authored-by: Claude Sonnet 5 <noreply@anthropic.com> Co-authored-by: Miranda Limonczenko <miranda.limonczenko@supabase.io> |
||
|
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 |
||
|
Raúl Barroso
|
cad51d85fd |
docs: give your app an MCP server (BYO-MCP guide rewrite) (#50218)
## 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? Fixes AI-1009 Updates the BYO-MCP guide so it includes information about the new middleware that will let users authenticate much more easily when building their own MCP server. This one includes a couple of clarifications which are important to document (use of environment variables, etc.) ## What is the new behavior? - Updated the existing guide (and example) for deploying an MCP server to use `@modelcontextprotocol/server` v2 with `createMcpHandler`. - Added new bits related to the new middleware which helps with authentication specifying the required versions of supabase/server and supabase/middleware, and also the auth prerequisites - Includes a table of where each MCP client takes the URL. - Added a new example to `examples/edge-functions/supabase/functions/mcp/` to illustrate the authentication example `authenticated-mcp-server`. ## Publish order > [!IMPORTANT] > There will be a companion PR to include the library components so this PR is blocked until https://github.com/supabase/supabase/pull/49579 ships. <!-- This is an auto-generated comment: release notes by coderabbit.ai --> ## Summary by CodeRabbit * **New Features** * Added comprehensive guidance for deploying authenticated MCP servers with OAuth 2.1, Supabase Auth, and user-scoped data access. * Added an authenticated MCP server example with `list_todos` and `create_todo` tools, protected by row-level security. * Added setup instructions for OAuth configuration, consent screens, local testing, and deployment. * **Documentation** * Updated authentication guidance and MCP security warnings across related guides. * Added links to MCP server and OAuth consent resources. * **Refactor** * Simplified the unauthenticated MCP server example and updated its tooling configuration. <!-- end of auto-generated comment: release notes by coderabbit.ai --> |
||
|
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 --> |
||
|
Nik Richers
|
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 --> |
||
|
TheOtherBrian1
|
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> |
||
|
Guillaume Faas
|
1531eb427d |
docs(csharp): add new C# Reference for v8.0.0 (#50116)
## 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: add a new page for the C# SDK reference v8.0.0 <!-- This is an auto-generated comment: release notes by coderabbit.ai --> ## Summary by CodeRabbit * **New Features** * Added C# client reference documentation for version 8.1.0. * Added navigation for the C# Reference v8 documentation. * Documented authentication, database, Realtime, Storage, filtering, and query APIs with C# examples. * **Documentation** * Added C# SDK 8.0.0 and 8.1.0 release notes, including breaking changes, new capabilities, and bug fixes. * Updated documentation version listings and search coverage for C# v8. <!-- end of auto-generated comment: release notes by coderabbit.ai --> |
||
|
supabase-supabase-autofixer[bot]
|
26585dd4a4 |
[bot] Sync from supabase/troubleshooting (#50284)
This PR syncs the latest troubleshooting guides from the supabase/troubleshooting repository. --------- Co-authored-by: github-docs-bot <github-docs-bot@supabase.com> Co-authored-by: Cursor Agent <cursoragent@cursor.com> Co-authored-by: Miranda Limonczenko <czenko@users.noreply.github.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 --> |
||
|
Anthony Lio
|
3de0e3a614 |
fix(docs): a11y alt text on Colab badge (#50222)
## What kind of change does this PR introduce? a11y fix ## What is the current behavior? Colab badge image is missing alt attribute leaving both image and the link unnamed _ screen reader users have no way to tell what the link does ## What is the new behavior? - adds `alt="Open in Colab"`, matching the text rendered inside the SVG so voice control users can activate it by its visible label ## Test 1. visit [/docs/guides/ai/google-colab](https://supabase.com/docs/guides/ai/google-colab) <!-- This is an auto-generated comment: release notes by coderabbit.ai --> ## Summary by CodeRabbit - **Documentation** - Improved accessibility across AI guides and quickstarts by adding descriptive alternative text to “Open in Colab” badge images. - Updated Google Colab, LlamaIndex, face similarity, hello world, and text deduplication documentation. <!-- end of auto-generated comment: release notes by coderabbit.ai --> |
||
|
Anthony Lio
|
2e861b5415 |
fix(docs): guides table overflow (#50221)
## What kind of change does this PR introduce? bug fix of table usage within guides ## What is the current behavior? table markup is used within the observability guide causing overflow of the content ## What is the new behavior? favors table component usage within mdx guide to fix the overflow and enable scroll | state | preview | | -------|------| | before | <img width="1171" height="668" alt="image" src="https://github.com/user-attachments/assets/bdbb905e-0ea9-4cde-b20b-84b4ef9a4137" /> | | after | <img width="1171" height="668" alt="image" src="https://github.com/user-attachments/assets/9e062222-1dad-49da-bdbe-616d89703301" /> | ## Test 1. visit [/docs/guides/observability/log-field-reference](https://supabase.com/docs/guides/observability/log-field-reference?queryGroups=source&source=edge_logs) <!-- This is an auto-generated comment: release notes by coderabbit.ai --> ## Summary by CodeRabbit - **Documentation** - Improved table rendering in the log field reference documentation. - Updated documentation tables to use the shared table presentation for a more consistent layout. <!-- end of auto-generated comment: release notes by coderabbit.ai --> |
||
|
Han Qiao
|
85573164f4 |
docs: document that branches are secure by default (#50193)
## 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 branching docs don't mention that new branches are created without default privileges on the `public` schema. Linear: BRA-189 ## What is the new behavior? - Working with branches: new "Default privileges on branches" section covering the keep-enabled path (initial migration grants) and the revoke path (new migration). - Troubleshooting: new entry for `42501` permission denied errors on a new branch. ## Additional context None. <!-- This is an auto-generated comment: release notes by coderabbit.ai --> ## Summary by CodeRabbit - **Documentation** - Added troubleshooting guidance for permission-denied errors affecting tables or functions on new branches. - Explained how migrations can restore intended default privileges on the `public` schema. - Added workflows for retaining or revoking default privileges, including dashboard configuration, migration-history repair, and access-management steps. - Added examples for granting or revoking access to sequences, functions, and tables. <!-- end of auto-generated comment: release notes by coderabbit.ai --> --------- Co-authored-by: Claude <noreply@anthropic.com> |
||
|
Szymon Mentel
|
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> |
||
|
Gildas Garcia
|
9b1dddde11 |
Scoped PAT: add api_gateway_keys_secret_read and data_api_config_secret_read permissions (#50134)
## What kind of change does this PR introduce? Surface the new scoped personal access token permissions published in `@supabase/shared-types` 0.1.95 (added by https://github.com/supabase/platform/pull/38060, now deployed). **Stacked on #50234**, which regenerates the Management API types so Studio's scope type includes the new ids. This PR targets that branch and will retarget to `master` when it merges. ## What's in here - Bump `@supabase/shared-types` to 0.1.95 (Studio and shared-data). - Catalog entries in `packages/shared-data/scoped-access-token-permissions.ts`: - **API Key Secrets** (`api_gateway_keys_secret_read`): gates `?reveal=true` on the API keys endpoints. Renamed from "JWT secret", which described the wrong thing. - **Data API JWT Secret** (`data_api_config_secret_read`): gates the `jwt_secret` field on the PostgREST config endpoint. - **Compute** (`workers_read` / `workers_write`): shared-types 0.1.95 also publishes the workers scopes, so they surface in the catalog now. Named to match Studio's product naming (#50208). - Minimum roles for the four new ids in `FGA_SCOPE_MINIMUM_ROLE`, transcribed from the OpenFGA model (secret reads: developer; workers read: readonly; workers write: developer). - Docs generator (`generateAccessControlPartials.mts`): - Drop the workers exclusion now that the scopes are live. - When an endpoint lists alternative permission sets (for example API keys read alone, or read plus secret read for reveal), a row's footnote now only considers the alternatives that include that row's own scope. Previously the API Key Secrets row would have said "Requires API Keys (Read), or API Keys (Read) and API Key Secrets (Read)". - Regenerated PAT guide tables. The committed Management API specs predate the secret scopes, so this also includes the same spec refresh the weekly docs bot performs (`chore(docs): refresh the Management API specs`, kept as its own commit). Besides the new rows it picks up two new upstream endpoints under Advisors and the branch rows. ## Verified - `pnpm --filter studio typecheck` clean on top of #50234. - Access token test suite passes, including the guard that the role table covers exactly the ids shared-types publishes. - Partial regeneration is idempotent, so the Docs Tests stale-table gate passes. ## Follow-ups (not in this PR) - `apps/docs/content/guides/getting-started/api-keys.mdx` says a fine-grained token needs `api_gateway_keys_read` for the `?reveal=true` example. It now also needs `api_gateway_keys_secret_read`. - `project:api_gateway_keys` still says "Read exposes API keys" in its risk reason, which overstates it now that secret values sit behind a separate scope. Rewording may mean revisiting its risk level. - The comment in `ComputeLayout.tsx` about shared-types not exposing `workers_read` is stale. <!-- This is an auto-generated comment: release notes by coderabbit.ai --> ## Summary by CodeRabbit * **New Features** * Added permission support for API key secrets, Data API JWT secrets, and compute workers. * Added API endpoints to run project advisors and create branches. * Added support for additional log-drain destinations, including S3, Last9, and OTLP. * Added storage object versioning information to project configuration responses. * **Documentation** * Updated access-control documentation for new permissions, worker operations, advisor runs, and branch creation. * Clarified Data API configuration and secret descriptions. <!-- end of auto-generated comment: release notes by coderabbit.ai --> --------- Co-authored-by: Alaister Young <10985857+alaister@users.noreply.github.com> |
||
|
Katerina Skroumpelou
|
028e05205b |
docs: warn that default signOut scope revokes all sessions (#50119)
Warn that default signOut scope revokes all sessions. Motivation: https://github.com/supabase/ssr/issues/68 <!-- This is an auto-generated comment: release notes by coderabbit.ai --> ## Summary by CodeRabbit * **Documentation** * Clarified that signing out without a specified scope ends all sessions by default. * Added guidance for using a local sign-out scope to preserve sessions on other devices and browsers. * Documented the invalid refresh token errors that may occur when other sessions are revoked. <!-- end of auto-generated comment: release notes by coderabbit.ai --> |
||
|
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 --> |