## Context
Related to dashboard scalability
Previous PR: https://github.com/supabase/supabase/pull/42856
Note: Changes are all feature flagged still and I'm still not entirely
convinced with the current UX
Will iterate as as go along, and only make this publicly available when
we're satisfied with the behaviour
Adds a "Dashboard preference" section to the project settings
<img width="265" height="740" alt="image"
src="https://github.com/user-attachments/assets/6ce1aa19-26c2-47c6-a9c4-595137266631"
/>
In which users can then select which database they'd like to use for
read queries run from the dashboard
Note: Everything is local storage for now, but we'd need middleware
support if we want to make this setting persist for all users on the
project
<img width="791" height="434" alt="image"
src="https://github.com/user-attachments/assets/e651d6d9-fed4-4da4-b552-c9f93f8d46d3"
/>
Added a dialog as well to further explain what this implies
<img width="610" height="312" alt="image"
src="https://github.com/user-attachments/assets/0aa957af-cb51-476f-aa79-8948a7cbe5ae"
/>
## To test
- Choosing a replica in dashboard preferences will only affect the table
editor as thats the only place that's set up so far to use a replica for
read queries (I'll need to follow up for other parts of the dashboard in
subsequent PRs)
### Changes
- Adds a dismissible banner prompting paid org users to add a Tax ID to
their billing settings
- Only shown to users with billing read permissions on orgs with a paid
plan and no Tax ID set
- Dismissal is persisted per-org via localStorage; banner also
auto-hides when a Tax ID is added
### Testing
- Log in as a user with no billing permissions into a Free Plan Org with
no tax id: no banner is shown
- Log in as a user with billing permissions into a Free Plan Org with no
tax id: no banner is shown
- Log in as a user with billing permissions into a Paid Plan Org with no
tax id
- Assert banner appears at the top
- Head to `/org/_/billing` with a paid Org. Change your billing country
to a not support one (like Paraguay) and click save. Assert that the
banner disappears. Change it back to continue testing.
- Click dismiss: banner disappears and stays dismissed across
navigation/refresh
- Log in as a user with billing permissions into a different Paid Plan
Org with no tax id
- Add a Tax ID via billing settings, assert that the banner disappears
immediately
<img width="1911" height="50" alt="image"
src="https://github.com/user-attachments/assets/d6208d6d-0939-4ff6-9613-5c687e7c622e"
/>
## 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?
- Added tracker when the main ai button was pressed
- Added new event to track "Open in" third party apps
- Added 2 missing telemetry sources
## Problem
While working on the phased PostHog Attribution rollout (GROWTH-625 /
GROWTH-668) — specifically the initial referrer handoff across the app
boundary — we discovered that `parseFirstReferrerCookie` was returning
`null` even when the cookie was visibly present in the browser.
The root cause: `serializeFirstReferrerCookie` calls
`encodeURIComponent(JSON.stringify(data))`, but Next.js `cookies.set()`
encodes the value again, producing a double-encoded cookie. On the read
side, `parseFirstReferrerCookie` only decodes once, so `JSON.parse`
receives a still-encoded string and fails. The `try/catch` swallows the
error and returns `null`.
Confirmed in production: the raw cookie value starts with `%257B%2522`
(double-encoded `%` characters). A single `decodeURIComponent` produces
`%7B%22referrer%22...` — still URL-encoded, not valid JSON. This was
blocking the cross-app attribution handoff that GROWTH-625 depends on.
## Changes
- **Serializer**: Removed `encodeURIComponent` from
`serializeFirstReferrerCookie` — Next.js `cookies.set()` already handles
encoding
- **Parser**: Made `parseFirstReferrerCookie` resilient to both
encodings — tries single decode first, falls back to double decode for
existing cookies in the wild (365-day TTL means legacy cookies persist
up to a year)
- **Test**: Added unit test for the double-encoded legacy cookie format
## Testing
- 35/35 common unit tests pass, 12/12 www middleware tests pass
- Verified locally: Google → www (localhost:3000) → Studio
(localhost:8082). Console logs confirmed `parseFirstReferrerCookie`
returned the full data object instead of null
- Confirmed in production that existing cookies are double-encoded and
the fix correctly handles them
Ref: GROWTH-625 / GROWTH-668
Update reference rendering files to support additional values in tsdoc.
---------
Co-authored-by: Jonathan Summers-Muir <MildTomato@users.noreply.github.com>
## 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?
Right now the new filter bar just does not work on mobile. It fully
collapses and does not appear correctly. This make it stack on smaller
screens and shows it to be visible. Works on smaller tabs
Note: there is a bit of awkwardness on certain screen sizes where its
one long row, will fix that later. This is better than nothing right now
## Problem
The Phase 1 mw_diag monitoring dashboard wasn't showing any data despite
the middleware PR (#43413) being live in production.
Next.js `response.cookies.set()` URL-encodes cookie values, so
`hit=1&would_stamp=0&has_cookie=0` becomes
`hit%3D1%26would_stamp%3D0%26has_cookie%3D0` in `document.cookie`. Our
`parseMwDiagCookie` was passing that encoded string directly to
`URLSearchParams`, which splits on literal `&` and `=` — the encoded
`%26`/`%3D` delimiters were invisible to it. Result: `params.get('hit')`
always returned `null`, so every diagnostic cookie was silently dropped.
## Changes
- Add `decodeURIComponent()` before `URLSearchParams` in
`parseMwDiagCookie`
- Add 3 test cases covering URL-encoded cookie values (matching what
Next.js actually produces in production)
## Testing
- All 34 unit tests pass (31 existing + 3 new)
- Verified locally with Playwright: manually set the URL-encoded cookie
format on localhost:8082, confirmed `parseMwDiagCookie` now returns
`{hit: true, ...}` and the data flows through to `PageTelemetry`
GROWTH-625
## I have read the
[CONTRIBUTING.md](https://github.com/supabase/supabase/blob/master/CONTRIBUTING.md)
file.
YES
## What kind of change does this PR introduce?
Feature — A/B experiment for a new pricing calculator on the `/pricing`
page, gated behind a PostHog feature flag.
## What is the current behavior?
The pricing page shows a single compute pricing section
(`PricingComputeSection`) to all visitors with no experimentation
support.
## What is the new behavior?
- Introduces a **pricing calculator A/B experiment**
(`pricingCalculatorExperiment`) using PostHog feature flags evaluated
client-side.
- **Control variant**: Renders the existing `PricingComputeSection` (no
change).
- **Test variant**: Renders a new `NewPricingComputeSection` with:
- A plan selector toggle (Pro / Team)
- An interactive compute calculator with slider-based instance sizing
- Ability to add/remove multiple project instances
- Live monthly cost estimate breakdown (plan + compute - credits)
- Expandable compute pricing table with detailed specs
- Adds `getFeatureFlag` and `onFeatureFlags` methods to the shared
`PostHogClient` for client-side flag evaluation on www pages (where
server-side evaluation lacks full person context).
## Additional context
- The experiment is scoped to the `/pricing` page only.
- New components (`NewPricingComputeSection`,
`NewComputePricingCalculator`) are created alongside the existing ones —
the control path is completely untouched.
- Feature flag evaluation happens client-side because www pages don't
have full person context on the server.
- Telemetry type `PricingCalculatorExperimentExposedEvent` is added to
`telemetry-constants.ts`.
---------
Co-authored-by: Sean Oliver <882952+seanoliver@users.noreply.github.com>
Co-authored-by: Mert YEREKAPAN <mertyerekapan@gmail.com>
Co-authored-by: Mert YEREKAPAN <33198490+myerekapan@users.noreply.github.com>
## Summary
The `homeNew` PostHog experiment has concluded. This PR graduates it by
making the new homepage (`ProjectHome`, formerly `HomeV2`) the permanent
default for all users, and removes all dead code from the old
experiment.
## Changes
- Remove `homeNew` PostHog feature flag checks and `home_new` experiment
exposure tracking from 3 files
- Rename `HomeNew/` → `ProjectHome/` directory and `HomeV2` →
`ProjectHome` export
- Delete old `Home/Home.tsx` component (shared components like
`ProjectList/` are kept — still used by org pages)
- Delete `pages/project/[ref]/building.tsx` and add a server-side
redirect from `/project/:ref/building` → `/project/:ref` to prevent 404s
during rollout (old cached JS bundles may still route to `/building`)
- Simplify `ContentWrapper` building-state logic in `ProjectLayout` —
always redirect building projects to home, always suppress building
interstitial on home page
- Always route to `/project/{ref}` after project creation (remove
`/building` path)
- Update all Observability imports from `HomeNew` → `ProjectHome`
## Self-hosted behavior change
Self-hosted Studio previously showed the old `Home` component (client
libraries + example projects) since PostHog flags don't load. This PR
changes self-hosted to show `ProjectHome` (TopSection with service
status + instance diagram, advisor, custom reports). All sections query
backend APIs that exist on self-hosted. E2E tests pass against the
self-hosted build.
## Testing
- [x] `pnpm turbo run build --filter=studio` passes
- [x] No remaining references to `homeNew`, `home_new`, or `HomeNew` in
codebase
- [x] No broken imports to deleted files
- [x] Self-hosted E2E tests pass (145 passed, 1 flaky, 4 skipped)
- [x] `/building` redirect added to both platform and self-hosted config
blocks
**Quick test:**
1. Navigate to any project homepage — should render the ProjectHome
component
2. Create a new project — should redirect to `/project/{ref}` (not
`/building`)
3. Visit a project in `COMING_UP` state on a non-home route — should
redirect to home
4. Visit `/project/{ref}/building` directly — should 302 redirect to
`/project/{ref}`
## Linear
- fixes GROWTH-671
## Context
We reached to a consensus that we'll keep manually written queries
within the `pg-meta` package
I'll shift queries over in several PRs but wanted to double check if the
changes here is a good folder structure
## Changes involved
- Am organizing dashboard queries in `pg-meta` based on product
- So folder structure will be `/sql/studio/[product]/*.ts`
- Every constant will be exported directly from `pg-meta`'s index
- So consumption in dashboard will just be `import { xxx } from
'@supabase/pg-meta`
cc @avallete and @soedirgo on this one - lemme know if this is alright,
or if there's a preferred way to do this
PostHog flagged our SDK as outdated — we were on 1.257.2, latest is
1.357.0.
**Changes**
- Bumped `posthog-js` in `packages/common/package.json` from `^1.257.2`
to `^1.333.0` (resolved to 1.357.0)
- Updated lockfile
**Why is the lockfile diff so large?**
posthog-js added several new dependencies between 1.257.2 and 1.357.0: a
full `@opentelemetry/*` stack (for opt-in log exporting),
`@posthog/core` and `@posthog/types` (internal monorepo split),
`dompurify`, and `query-selector-shadow-dom`. None of these affect our
bundle unless explicitly enabled — they're opt-in features. The lockfile
entries are large because pnpm records each package with its full
resolution tree and checksums.
**Testing**
Spun up the full local stack and verified all three PostHog endpoints
return 200 with the new SDK version:
- `/e/` (event capture) — pageviews firing correctly
- `/flags/` (feature flag evaluation) — flags loading correctly
- `/i/v0/e/` (identify) — user identification working
No breaking changes in any of the 16 releases between our old and new
version (all Minor/Patch Changes). TypeScript compilation clean across
all apps.
GROWTH-589
## Problem
The `_sb_first_referrer` cookie isn't working. The www middleware
matcher explicitly excludes `/dashboard` and `/docs`, so the cookie
never gets stamped for Studio or Docs traffic. PostHog confirmed: only 1
event with `first_referrer_cookie_present=true` out of ~46.5M Studio
pageviews in the last 7 days.
## Background: what the matcher does
In Next.js, the `matcher` config controls which incoming requests the
middleware function even runs on. If a path doesn't match, the
middleware is skipped entirely — the request passes through untouched.
If it matches, the middleware runs and can mutate the response (set
cookies, headers, etc.).
This matters because Studio's SPA navigation works via silent
`/_next/data/` JSON fetches. If middleware runs on those requests and
returns `NextResponse.next()` with any mutations, it breaks those
fetches and causes full page reloads instead of client-side transitions.
## What we tried before
| PR | www runs on `/dashboard`? | Studio `proxy.ts` runs on all routes?
| Result |
|---|---|---|---|
| **#42768** (Attempt 1) | ✅ Yes — and also intercepts `_next/data` | ✅
Yes — `matcher` config removed, stamps cookie everywhere | Full page
reloads in Studio |
| **#43129** (Full revert) | ❌ No — www middleware deleted entirely | ❌
No — restored to `matcher: '/api/*'` only | Back to baseline, no cookie
stamping anywhere |
| **#43153** (Attempt 2) | ❌ No — `/dashboard` explicitly excluded | ✅
Yes — `matcher` config removed again, stamps cookie everywhere | Full
page reloads in Studio again |
| **#43189** (Attempt 3) | ❌ No — same as #43153 | ✅ Yes — `matcher`
config still removed, cookie stamping made conditional | Still broken |
| **#43190** (Ivan's fix) | ❌ No — `/dashboard` still excluded | ❌ No —
restored to `matcher: '/api/*'` only | Works — but cookie never stamps
for `/dashboard` traffic |
| **#43413** (this PR) | ✅ Yes — sets diagnostic cookie only, no
attribution stamping yet | ❌ No — unchanged, still `matcher: '/api/*'`
only | ❓ Untested in prod |
The common factor in every failure: Studio's `proxy.ts` ran on all
routes (including `_next/data` requests), which broke SPA navigation.
This PR is the first one that runs www middleware on `/dashboard` while
Studio's `proxy.ts` stays in its original narrow `/api/*` scope.
## What changed
This is Phase 1 of a two-phase rollout. We remove `dashboard|docs` from
the matcher's negative lookahead so www middleware runs on those paths —
but instead of stamping cookies, we set a short-lived (60s) diagnostic
cookie `_sb_mw_diag` on `/dashboard` and `/docs` requests.
The diagnostic cookie encodes
`hit=1&would_stamp={0|1}&has_cookie={0|1}`, which Studio telemetry reads
on the initial pageview and reports to PostHog as `mw_diag_hit`,
`mw_diag_would_stamp`, and `mw_diag_has_existing_cookie` properties.
A cookie rather than a header because response headers aren't readable
by JS. It also tests the actual Set-Cookie mutation path that Phase 2
will use (which is what Next.js issue #41885 is specifically about).
Phase 1 answers two key questions before we commit to Phase 2:
1. Does expanding the matcher break Studio SPA navigation?
2. What % of /dashboard arrivals would get a first-referrer cookie
stamped in Phase 2?
## Phase 2 readiness criteria
**Important caveat**: `mw_diag_*` data reflects consented users only and
may under-represent first-visit anonymous traffic. The Phase 2 decision
should account for this — the actual middleware execution rate is likely
higher than what PostHog reports.
### PostHog query spec
**Middleware execution rate**: Of all Studio initial pageviews on
`/dashboard` or `/docs` paths, what percentage have `mw_diag_hit =
true`? Expected: >= 90%. Below 70% warrants investigation (could
indicate edge caching bypassing middleware, or a matcher configuration
issue).
```
Filter: event = "$pageview" AND (current_url contains "/dashboard" OR current_url contains "/docs")
Breakdown: mw_diag_hit (true vs null/missing)
Metric: count(mw_diag_hit = true) / count(all) * 100
```
**Would-stamp rate**: Of events with `mw_diag_hit = true`, what
percentage have `mw_diag_would_stamp = true`? This tells us what
percentage of Phase 2 traffic would actually get a cookie stamped. No
hard threshold — unexpected values (< 5% or > 95%) suggest a logic bug
worth investigating before Phase 2.
```
Filter: event = "$pageview" AND mw_diag_hit = true
Breakdown: mw_diag_would_stamp (true vs false)
Metric: count(mw_diag_would_stamp = true) / count(all) * 100
```
**Existing cookie rate**: Of events with `mw_diag_hit = true`, what
percentage have `mw_diag_has_existing_cookie = true`? This tells us how
many users already have the cookie from a prior www visit.
```
Filter: event = "$pageview" AND mw_diag_hit = true
Breakdown: mw_diag_has_existing_cookie (true vs false)
Metric: count(mw_diag_has_existing_cookie = true) / count(all) * 100
```
### Go / no-go threshold table
| Signal | Go | Investigate | No-Go |
|---|---|---|---|
| `mw_diag_hit` rate (% of /dashboard+/docs pageviews) | >= 90% | 70-90%
| < 70% |
| SPA navigation errors (Sentry / Vercel logs) | No increase | < 0.1%
increase | > 0.5% increase |
| Middleware p99 latency (Vercel function logs) | < 50ms added |
50-100ms | > 100ms |
| Sample volume in first 24h | > 1,000 events | 100-1,000 (extend
window) | < 100 (insufficient data) |
## Changes
- `apps/www/middleware.ts`: Removed `dashboard|docs` from matcher; added
`isDashboardOrDocs` guard that sets `_sb_mw_diag` diagnostic cookie
instead of stamping attribution
- `apps/www/middleware.test.ts`: 12 tests covering cookie stamping on
www paths, diagnostic cookie encoding for all scenarios (external
referrer, direct nav, internal referrer, existing cookie)
- `packages/common/first-referrer-cookie.ts`: Exported
`MW_DIAG_COOKIE_NAME`, `MwDiagData` type, and `parseMwDiagCookie()`
helper
- `packages/common/telemetry.tsx`: Reads `_sb_mw_diag` on initial Studio
pageview; reports `mw_diag_*` properties to PostHog
## Testing
Unit tests pass (13/13 www, 31/31 first-referrer-cookie). Production
validation needed:
- [ ] Studio SPA navigation works (tab changes, SQL editor, no full page
reloads)
- [ ] PostHog shows `mw_diag_hit = true` on Studio initial pageviews
- [ ] `mw_diag_would_stamp` distribution looks reasonable before
enabling Phase 2
- [ ] Monitor 24h before Phase 2
Ref: GROWTH-625 / GROWTH-668
## 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?
This is something we've discussed for a while. A shared place for error
codes and their mappings, descriptors etc. Available for all projects in
the monorepo.
## What kind of change does this PR introduce?
Bug fix: custom icons now respect their source SVG’s stroke/fill and
stroke-width instead of always getting a global stroke.
## What is the current behavior?
Every custom icon gets `stroke="currentColor"` and `strokeWidth={2}`
from `createSupabaseIcon`, so fill-only logos get an extra stroke and
icons designed at `stroke-width="1"` (e.g. postgres, auth) render too
thick. Call sites and the design-system grid needed workarounds
(`strokeWidth={0}`, `FILL_ONLY_ICONS`, `STROKE_WIDTH_FROM_SOURCE`).
## What is the new behavior?
The icon build reads root SVG attributes (`fill`, `stroke`,
`stroke-width`, etc.) and passes them as per-icon defaults. Fill-only
icons (chatgpt, claude, axiom, last9) have `stroke="none"` in source and
render with no stroke; stroke icons keep their source stroke-width (e.g.
postgres at 1). No `strokeWidth={0}` or allowlists needed at call sites
or in the icon grid.
| Before | After |
| --- | --- |
| <img width="1826" height="552" alt="CleanShot 2026-03-05 at 10 53
31@2x-3D63CEF0-1132-44F5-A382-730346432F1E"
src="https://github.com/user-attachments/assets/9caf73fa-351b-4ea2-a420-b3339f934742"
/> | <img width="1814" height="552" alt="CleanShot 2026-03-05 at 10 53
40@2x-514FC8BD-D30F-4D23-B209-0ECD6D13A184"
src="https://github.com/user-attachments/assets/936ea5a5-dae0-413f-8545-b90a502cea69"
/> |
## Additional context
- Added `stroke="none"` to the four fill-only source SVGs;
sentry/grafana/otlp/datadog already had `stroke-width="0"`.
- `createSupabaseIcon` only applies `color`/`strokeWidth` when the
consumer passes them, so `svgDefaults` from the build are used
otherwise.
- Removed workarounds from `icons.tsx` and GuidesSidebar; updated
icons.mdx (defaults + fill-only guidance).
Allows users to select logs and copy their contents for debugging, or
pass them on to assistant with one click.
## To test
- go to logs or log explorer
- select some logs
- try copying as json, markdown, or sending it to assistant.
## What kind of change does this PR introduce?
- UI fixes and cleanup
## What is the current behavior?
- We use the _Anthropic_ logo for _Claude Code_ in the MCP connector
panel
- We have a bunch of redundant dark mode logos (visually the same as
their light mode siblings)
| Before | After |
| --- | --- |
| <img width="987" height="373" alt="Krosno Toolshed
Supabase-03CD5E6F-53E6-4282-9087-ACB9F67B6DDA"
src="https://github.com/user-attachments/assets/ca7b5d9c-2a2b-4520-8bd4-8cf26c759c73"
/> | <img width="987" height="373" alt="Krosno Toolshed
Supabase-53F3849B-2D86-494B-BE25-8D23EA050243"
src="https://github.com/user-attachments/assets/7bd2e9a6-82ae-48a1-9ef1-591b7a33632e"
/> |
## What is the new behavior?
- We use the _Claude_ logo for _Claude Code_
- Removed duplicative logos
- Made note of which MCP servers have a different logo for dark mode
## What kind of change does this PR introduce?
UI fix
## What is the current behavior?
Radio button circles are off-center in Safari.
## What is the new behavior?
Radio button circles are centered in Safari. Extraneous stroke on the
Lucide Circle icon also removed.
| Before | After |
| --- | --- |
| <img width="1502" height="864" alt="General Supabase"
src="https://github.com/user-attachments/assets/7fea0cc5-d62f-4c29-b341-494e66b91c38"
/> | <img width="1502" height="864" alt="General Supabase"
src="https://github.com/user-attachments/assets/296cbb72-ced2-44f7-8c73-d2c758a66507"
/> |
It’s hard to see the before-after via screenshots. Go to org settings on
`master` in Safari to see the difference.
## Additional context
We already applied this fix in `radio-group-stacked`.
## 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?
- Allow selecting the column, it respects different types and updates
the values correctly. If the values are different it gets wiped due to
mismatches
- Updated E2E tests and unit tests
Adds the new `dedicated_pooler` entitlement and it's respective
entitlement checks in the following components: `ConnectTabContent`,
`ConnectStepsSection`, `LogsSidebarMenuV2` and `ConnectionPooling`
## Testing
### ConnectTabContent and ConnectStepsSection
- Head to `project/_?showConnect=true` with an Org on the Pro Plan or
above
- Assert that the `Dedicated Pooler` option is available.
<img width="1007" height="641" alt="image"
src="https://github.com/user-attachments/assets/b4891544-b84b-4745-9e25-4cbc7c76686c"
/>
### IPv4SidePanel
- Head to `/project/_/database/settings` with an Org on the Pro Plan and
above and assert that the Dedicated Pooler is available
<img width="889" height="562" alt="image"
src="https://github.com/user-attachments/assets/3150cb3d-18e9-4b34-bc9b-2589d0a33c5f"
/>
### Dedicated Pooler Logs
- Head to `/project/_/logs/dedicated-pooler-logs` with an Org on the Pro
Plan and assert that you are in the `dedicated-poolers-logs` page.
- Head to `/project/_/logs/dedicated-pooler-logs` with an Org on the
Free Plan and assert that you are redirected to `/logs/pooler-logs`
### Logs Sidebar
- Head to `/project/jdvjfujajfyywbaaakje/logs/explorer` with an Org on
the Free Plan
- Assert that only the "Poolers" collection is shown
- Head to `/project/jdvjfujajfyywbaaakje/logs/explorer` with an Org on
the Pro Plan
- Assert that the Dedicated and Shared Poolers collections are shown
<img width="251" height="774" alt="image"
src="https://github.com/user-attachments/assets/747bceee-d5e7-4a8f-911d-6b02cdb115eb"
/>
## 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?
- For the new filters experience, we are missing null changes for dates
and also no support for isNull
- Updated E2E tests to account for new null cases
## Summary
- Add contest rules legal page (`/go/contest-rules`) with official
sweepstakes rules
- Add executive dinner landing page (`/go/stripe/exec-dinner`) with RSVP
form backed by HubSpot and Customer.io
- Add executive dinner thank-you page
(`/go/stripe/exec-dinner/thank-you`)
- Add Stripe Sessions contest page (`/go/stripe/contest`) for iPhone 17
Pro Max sweepstakes
## Notes
- HubSpot `formGuid` on the exec dinner page needs to be replaced with
the real value before going live
- Customer.io `staticProperties` support is needed to send `event_name`
as a track property (see TODO comment in exec dinner page)
- iPhone image placed at
`public/images/landing-pages/stripe-sessions/iphone17-pro-max.png`
## Test plan
- [ ] Verify all four pages render correctly at their respective slugs
- [ ] Test RSVP form submission on exec dinner page
- [ ] Confirm contest rules page content matches official legal rules
- [ ] Verify iPhone image renders in contest page hero
- [ ] Check mobile responsiveness on all pages
---------
Co-authored-by: Alan Daniel <stylesshjs@gmail.com>
## 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?
Blog post on using pg_partman instead of TimescaleDB to prepare for the
upcoming deprecation
## What is the current behavior?
## What is the new behavior?
Blog post to include migration information for those using Timescale
## Additional context
Not to be merged until pg_partman is released in 15 and 17 images
<!-- This is an auto-generated comment: release notes by coderabbit.ai
-->
## Summary by CodeRabbit
* **Documentation**
* Added a comprehensive pg_partman guide covering setup, time- and
integer-based partitioning, maintenance, automation, and resources.
* Added a migration guide for moving from TimescaleDB hypertables to
native PostgreSQL partitioning using pg_partman.
* Updated TimescaleDB docs with migration notes and support guidance.
* **New Features**
* Listed pg_partman in the public extensions reference and added
navigation entries linking to the pg_partman guide and migration guide.
<sub>✏️ Tip: You can customize this high-level summary in your review
settings.</sub>
<!-- end of auto-generated comment: release notes by coderabbit.ai -->
---------
Co-authored-by: github-actions[bot] <41898282+github-actions[bot]@users.noreply.github.com>
## I have read the
[CONTRIBUTING.md](https://github.com/supabase/supabase/blob/master/CONTRIBUTING.md)
file.
YES
## What kind of change does this PR introduce?
Feature restoration
## What is the current behavior?
Incident banners cannot be dismissed by users.
## What is the new behavior?
Users can dismiss incident banners again.
## Additional context
This pull request improves how user consent is handled for telemetry and
tracking, ensuring that analytics scripts and cookies are only active
when the user has provided consent. The changes both enforce stricter
checks before enabling Google Tag Manager and ensure that tracking
cookies are cleared when consent is denied.
Mobile sheet nav doesn't close on route change and viewport resizing
after #43184.
This PR fixes that and also makes it optional to close on nav and
resizing, because the sidepanels need them _not_ to resize, while mobile
navigation menu does.
Also added some tests. 🪄
## What kind of change does this PR introduce?
Fix
## What is the current behavior?
The theme switcher in `CommandMenu` is not showing up when typing in
“dark mode”, “toggle theme” or similar commands.
## What is the new behavior?
Added hidden root commands: `Toggle theme`, `Use dark theme`, `Use light
theme`, `Use system theme`, plus existing `Switch theme...` with search
aliases.
Also added `value` aliases to the theme items so searches pop up.
---------
Co-authored-by: Joshen Lim <joshenlimek@gmail.com>
## Context
Renaming folders on the Storage Explorer has a tendency to be flaky as
we're using the `POST /objects/move` storage API to move files to the
renamed folder which handles one file per request.
For a big folder (e.g 100+ files), users will easily hit rate limits and
run into 429s with the API, in which the current behaviour just shows
toast errors as the error handler, leaving an odd state upon running
through every file in the folder where some files are in the old folder,
and others in the new one
## Changes involved
Main solution is to implement an automatic retry logic for
`renameFolder`, but changes involved are:
- Remove batching logic for renaming folders (Which fires `n` requests
per batch)
- The batch logic was negligible anyways since our batch size was only 2
😅
- Instead we now handle moving of files sequentially
- If a file runs into an error during the `POST` request, retry the
request after `n` seconds
- If the error was a 429, retry after 60 seconds, otherwise just 5
seconds
- Will attempt the request for a total of 3 times
- Toast progress description will also be updated to show the message
(timer will also count down to keep the UI interactive and not look
stuck)
<img width="362" height="98" alt="image"
src="https://github.com/user-attachments/assets/52ba685a-2f35-42f1-8fcf-98351184fd56"
/>
- After the whole process is completed, if any file ran into an error,
toast description will add a CTA to retry the rename
## Demo
https://github.com/user-attachments/assets/d65b3c22-f9f8-4984-9521-6fc83a69f82e
## To test
Have a folder in your project's storage bucket with 100+ files (can
stress test with nested folders)
- [ ] Verify that you can rename the folder, and the dashboard
automatically handles errors
## What kind of change does this PR introduce?
- Feature
- Resolves DEPR-355
## What is the current behavior?
Only one email address can be invited to an organization at a time.
## What is the new behavior?
- Multiple email addresses can be invited (at a single scope) to an
organization at one time
- List of email addresses detected via comma-separation
- Pluralization on fields and labels
- Table and copywriting cleanup
| Before | After |
| --- | --- |
| <img width="808" height="691" alt="Supabase"
src="https://github.com/user-attachments/assets/f6450c26-968c-4ee8-bb7c-d6f6a3af1209"
/> | <img width="808" height="691" alt="8298"
src="https://github.com/user-attachments/assets/2d7e3869-b9d4-4a4f-89aa-ae55d67e794b"
/> |
| <img width="1024" height="560" alt="Supabase"
src="https://github.com/user-attachments/assets/9a255167-fcd3-4294-ba3a-9160bd500cff"
/> | <img width="1024" height="560" alt="Supabase"
src="https://github.com/user-attachments/assets/daba5bb8-eb12-43dc-86de-217e9baf0b72"
/> |
<!-- This is an auto-generated comment: release notes by coderabbit.ai
-->
## Summary by CodeRabbit
* **New Features**
* Added support for inviting multiple team members simultaneously via
comma-separated emails.
* **Improvements**
* Enhanced member management interface with clearer status indicators
(You, Invited, SSO, MFA enabled/disabled).
* Improved feedback messages for invitation outcomes and member status
changes.
* Updated member table layout with summary footer displaying member
count.
<!-- end of auto-generated comment: release notes by coderabbit.ai -->
## What kind of change does this PR introduce?
Changes the base font weight for strong tags within the
tailwind/typography configuration.
## What is the current behavior?
I noticed that texts within our strong tags had an irregular stroke, and
problems on rendering. The main problem is we are using the default 600
weight value coming from the config of tailwind, while our Circular
custom font supports 400 and 600.
_See the first text in the list from the screen just, like "Multi
Protocol"._
<img width="717" height="555" alt="Screenshot 2026-02-25 at 16 10 29"
src="https://github.com/user-attachments/assets/1063f049-ba9d-45a4-9946-ec4a0e380c48"
/>
## What is the new behavior?
Strong tags now render with 500 font weight to prevent bad text
rendering.
<img width="674" height="505" alt="Screenshot 2026-02-25 at 16 12 56"
src="https://github.com/user-attachments/assets/383e895d-e2b7-4d92-9357-403396ca2722"
/>
## Summary
Re-lands the first-referrer cookie feature from #42768 (reverted in
#43129) with middleware matcher fixes that prevent Studio traffic
interference.
**Tracks:** [GROWTH-651](https://linear.app/supabase/issue/GROWTH-651)
## What changed
New shared module in `packages/common/first-referrer-cookie.ts` that
handles stamping and parsing a first-referrer cookie (referrer, UTMs,
click IDs, landing URL). Each app's middleware calls
`stampFirstReferrerCookie` on the edge response — www and docs are the
primary entry points, Studio is a fallback for direct visits with UTMs.
On the telemetry side, `handlePageTelemetry` now takes an options object
instead of positional args, reads the cookie on initial pageview, and
overrides the referrer if the cookie captured an external source but the
current referrer is internal (i.e., the user navigated cross-app). Also
sends `first_referrer_cookie_present`/`consumed` properties so we can
observe the handoff in PostHog.
The docs middleware matcher was broadened from `/reference/:path*` to
all docs pages so we stamp cookies site-wide, not just on reference
paths.
## Root cause of original revert
Two layers:
1. **Matcher gap**: www middleware ran on `/dashboard/*` traffic in prod
due to Vercel Multi-Zone architecture (www is the gateway for
`supabase.com`, proxying `/dashboard` → Studio, `/docs` → Docs).
Middleware runs *before* rewrites, so www middleware executed on all
proxied traffic.
2. **`_next/data` interception**: The matcher didn't exclude
`_next/data` paths. Client-side navigation in Next.js fetches JSON via
`/_next/data/...` — middleware intercepted these, returned
`NextResponse.next()` with cookie mutations (which processes through the
middleware response pipeline), and this interfered with the JSON
responses, causing full page reloads in the SQL editor.
## How this PR fixes it
| Fix | Detail |
|---|---|
| Exclude `_next/data` | All three matchers (`www`, `docs`, `studio`)
exclude `_next/data` via negative lookahead |
| Exclude `dashboard` + `docs` from www | www middleware no longer runs
on proxied app traffic |
| `/api/` path guard in Studio | Broadened matcher requires explicit
path check for API route filtering |
| `NextResponse.next()` semantics | Cookie stamping only happens on
matched paths; unmatched paths never enter middleware |
### `NextResponse.next()` vs `undefined` nuance
Returning an explicit `NextResponse.next()` with cookie mutations
processes through Next.js's middleware response pipeline (headers are
merged, cookies are set). Returning `undefined` (i.e. the request never
matches the matcher) lets Next.js handle the request completely
untouched. The matcher exclusions ensure `_next/data` and proxied app
paths never enter middleware at all.
## Testing
- ✅ 22 unit tests for shared cookie utilities (all pass)
- ✅ Studio prod build succeeds, middleware recognized as `ƒ Proxy
(Middleware)`
- ✅ Playwright validation: client-side navigation works across 3 page
transitions, `_next/data` requests return 200 OK without middleware
interception, no full-page reloads
- ❌ www/docs SSG builds require platform backend services (expected —
same as master)
The SDK now handles orphaned lock recovery via steal internally
(supabase-js#2106). Keep the BroadcastChannel observability wrapper for
Sentry signals. The steal-based orphaned lock recovery in
`debuggableNavigatorLock` (packages/common/gotrue.ts) (introduced in
https://github.com/supabase/supabase/pull/39868) is now redundant,
supabase-js#2106 handles this natively in the SDK.
Removes the `navigator.locks.request({ steal: true })` block while
keeping the BroadcastChannel wrapper that sends lock-holder stack traces
to Sentry.
Related: supabase/supabase-js#2106, supabase/supabase-js#2125
## I have read the
[CONTRIBUTING.md](https://github.com/supabase/supabase/blob/master/CONTRIBUTING.md)
file.
YES/NO
## What kind of change does this PR introduce?
Bug fix, feature, docs update, ...
## What is the current behavior?
Please link any relevant issues here.
## What is the new behavior?
Feel free to include screenshots if it includes visual changes.
## Additional context
Add any other context or screenshots.
Co-authored-by: Jordi Enric <37541088+jordienr@users.noreply.github.com>
## What kind of change does this PR introduce?
UI improvement
## What is the current behavior?
The session expired dialog is quite hard to parse when, for most people,
the ask is simple.
## What is the new behavior?
Improved session expired dialog:
- Refactored to use AlertDialog
- Clarified copywriting
- Uses the new AlertCollapsible to hide all the complicated debugging
steps under a toggle
- This component is documented in the design-system
| Before | After |
| --- | --- |
| <img width="1024" height="563"
alt="Supabase-B1728A05-DDD2-4A50-AED4-D62EAA2E7D7C"
src="https://github.com/user-attachments/assets/771f85d8-21ea-42b5-99f5-b9b05f5617dd"
/> | <img width="1024" height="563" alt="Storage Supabase"
src="https://github.com/user-attachments/assets/b2fcab68-fb29-4cb9-bd42-aecc57b9fa32"
/> |
| <img width="1024" height="563"
alt="Supabase-B1728A05-DDD2-4A50-AED4-D62EAA2E7D7C"
src="https://github.com/user-attachments/assets/771f85d8-21ea-42b5-99f5-b9b05f5617dd"
/> | <img width="1024" height="563" alt="Storage Supabase"
src="https://github.com/user-attachments/assets/babd3711-5fdf-43b9-be06-d96268a191fd"
/> |
## To test
In apps/studio/hooks/misc/withAuth.tsx:
```diff
- const [isSessionTimeoutModalOpen, setIsSessionTimeoutModalOpen] = useState(false)
+ const [isSessionTimeoutModalOpen, setIsSessionTimeoutModalOpen] = useState(true) // Mocked as true for UI testing
```
---------
Co-authored-by: Joshen Lim <joshenlimek@gmail.com>
## What kind of change does this PR introduce?
Feature. Resolves DEPR-390
## What is the current behavior?
Projects aren’t sortable in either the card or table view.
## What is the new behavior?
Projects are sortable in both:
- Card view: sort dropdown
- Table view: sort dropdown or table column headers
| Before | After |
| --- | --- |
| <img width="1382" height="797"
alt="Supabase-4D1BFE40-875D-494C-8F17-A68D92826458"
src="https://github.com/user-attachments/assets/c4f17b77-bc90-447f-90cd-78a11c2e4129"
/> | <img width="1382" height="797"
alt="Supabase-D8C0AC7C-A28D-4AA6-BA7C-0FCD61DB5D11"
src="https://github.com/user-attachments/assets/d926d03d-2702-48e5-9d1f-0e09d163079d"
/> |
| <img width="1382" height="797"
alt="Supabase-0A545C5C-40B5-47F7-9ACD-2200879BB95E"
src="https://github.com/user-attachments/assets/f2103c32-a150-4db7-a78a-8bd610e2a028"
/> | <img width="1382" height="797"
alt="Supabase-0F7AB608-2E86-4F0C-BB60-C85D9B7F3D57"
src="https://github.com/user-attachments/assets/baa63f14-4059-483d-a9d6-33663e5cff43"
/> |
## Additional context
I wonder if this is overkill given most folks only have 1–2 projects.
Some ideas:
- Only sortable in table view via column headers
- Conditional rendering for folks with 2+ projects
- Opt-in feature
- Feature-flag
I’ve opted to make it global and synced for now.
---------
Co-authored-by: Joshen Lim <joshenlimek@gmail.com>
## 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?
New Go landing page for the upcoming Bolt webinar. This is where we will
direct customers who want to learn more to go to request a meeting.
---------
Co-authored-by: Alan Daniel <stylesshjs@gmail.com>
Joshen Lim