## What kind of change does this PR introduce?
Feature that resolves DEPR-321.
## What is the current behavior?
From @dshukertjr:
> Users of free and pro orgs frequently struggle to figure out how to
add teammates to a project.
## What is the new behavior?
Project Settings → General now has a Project access section showing who
can access the project (email + role), with a link to team management
(_Manage members_ or _View team_ for limited users). Large member lists
are truncated with +N more.
| Permutations |
| --- |
| <img width="1462" height="544" alt="CleanShot 2026-03-06 at 17 00
00@2x"
src="https://github.com/user-attachments/assets/68e5519f-3851-4ab8-a364-9fcb222fbcb7"
/> |
| <img width="1486" height="676" alt="CleanShot 2026-03-06 at 16 59
48@2x"
src="https://github.com/user-attachments/assets/e1b85bb5-6fbd-46ec-9b13-15501defd030"
/> |
| <img width="1464" height="566" alt="CleanShot 2026-03-06 at 16 59
34@2x"
src="https://github.com/user-attachments/assets/e9fdc188-cf79-4af9-8b3c-313e98256109"
/> |
| <img width="1438" height="654" alt="CleanShot 2026-03-06 at 17 11
25@2x-83D06149-E4AE-4AC0-98D9-FBBE10A58C8C"
src="https://github.com/user-attachments/assets/8a6e1aa2-76bb-486e-999a-1df4f88c3692"
/> |
## Additional context
Behaviour is based on user role visibility, not a special plan-only
toggle. Team+ orgs are more likely to hit limited/project-scoped cases;
free/pro are usually org-wide access.
## What kind of change does this PR introduce?
Copywriting improvements
## What is the current behavior?
The “missing tax ID” banner:
- Is longer than it needs to be
- Therefore overflows on smaller viewports
- Has unnecessarily qualifications despite having a dismiss button
- Has funky capitalization
## What is the new behavior?
- Tighter copywriting with less redundancy
| Before | After |
| --- | --- |
| <img width="1024" height="563" alt="AWS Healthy Toolshed
Supabase-8B1E57CE-72A6-4C7F-918F-71C1842CBDD3"
src="https://github.com/user-attachments/assets/755fd9ac-50e7-4540-9dd3-529e37bdeaff"
/> | <img width="1024" height="563" alt="AWS Healthy Toolshed
Supabase-A2B65D23-103A-4146-BE6A-DEAC592646D0"
src="https://github.com/user-attachments/assets/deefb639-0670-4d92-8b75-bc0080bfb587"
/> |
## What kind of change does this PR introduce?
UI nit changes
## What is the current behavior?
- We use big dots `•` to separate semantically different sets of text
that are in the same row
- This looks a bit odd given how large the dot is to text
- We put _Project Settings_ in its own sidebar section but without a
separator like all other sidebar sections
## What is the new behavior?
- Use the smaller dots `·` to separate text
- Place a separator above _Project Settings_ in sidebar
| Before | After |
| --- | --- |
| <img width="1342" height="711" alt="AWS Healthy Toolshed
Supabase-70BD1825-8077-4D1B-84C1-831A4ADAFC0B"
src="https://github.com/user-attachments/assets/70246009-a3c7-4b5c-8d75-122140a637d1"
/> | <img width="1342" height="711" alt="AWS Healthy Toolshed Supabase"
src="https://github.com/user-attachments/assets/e3fc13e4-923d-472e-aaf9-d689e890697b"
/> |
## 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)
Stacked PR 3/5 for page title improvements. Includes Logs and
Observability layout title adoption, unified logs title cleanup, and
small route title fixes.
_Base:
[dnywh/feat/page-titles](https://github.com/supabase/supabase/pull/43538)_
---
## What kind of change does this PR introduce?
- Resolves FE-1960
- Resolves FE-1983
- Resolves DEPR-207
## What is the current behavior?
Page titles between surfaces are inconsistent and vague. Sometimes they
say the product name:
```
My Project | My Org | Supabase
```
...even when on a specific surface like Database > Tables.
Other times they show the entity name but skip over the project or org
name :
```
Edge Functions | Supabase
```
## What is the new behavior?
Logs and Observability adopts the layout title format introduced in
https://github.com/supabase/supabase/pull/43538:
```
users | Table Editor | My Project | My Org | Supabase
hello-world | Logs | Edge Functions | My Project | My Org | Supabase
Backups | Database | My Project | My Org | Supabase
Authentication | My Project | My Org | Supabase
```
That format is:
entity, section, surface, project, org, brand.
Also includes unified logs title cleanup, and small route title fixes.
## Additional context
Related stacked PRs also based on the the original
[dnywh/feat/page-titles](https://github.com/supabase/supabase/pull/43538)
branch:
- https://github.com/supabase/supabase/pull/43534
- https://github.com/supabase/supabase/pull/43536
- https://github.com/supabase/supabase/pull/43537
---------
Co-authored-by: Joshen Lim <joshenlimek@gmail.com>
### 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
## Changes
- Replaces plan ID-based chart gating with entitlement-based checks
across all observability pages (database, auth, realtime,
edge-functions)
- Adds requiredPlan display field so the upsell shows the correct target
plan (e.g. "Upgrade to Team" for disk throughput, not just "Upgrade")
- Decouples database-charts.ts from Organization Plan, now accepts
pre-computed entitlement flags instead
### Note on `requiredPlan`
The entitlement system currently tells us whether a user has access, but
not what plan they need to get access. `requiredPlan` is a frontend-only
display hint. Ideally the backend entitlement response would include a
minimumPlan field so we can remove this hardcoded mapping. For now, this
is a pragmatic workaround to avoid misleading upsell copy (e.g. a Free
user seeing "Upgrade" for a Team-only feature and landing on Pro).
## Testing
### Database
- Head to `/project/_/observability/database` with an Org on the Free
Plan and assert that the Disk throughput is gated.
<img width="1402" height="682" alt="image"
src="https://github.com/user-attachments/assets/b783d866-774d-44dc-88d1-797d26502f02"
/>
### Auth
- Head to `/project/_/observability/auth` with an Org on the Free Plan
and assert that the following metrics are gated:
<img width="1402" height="682" alt="image"
src="https://github.com/user-attachments/assets/cb062dd7-5864-4e40-a11f-ad6be1f7fd41"
/>
### Edge Functions
- Head to `/project/_/observability/edge-functions` with an Org on the
Free Plan and assert that the following metrics are gated:
<img width="1402" height="320" alt="image"
src="https://github.com/user-attachments/assets/517b5483-4575-493c-9401-2c67ac9e684c"
/>
### Realtime
- Head to `/project/_/observability/realtime` with an Org on the Free
Plan and assert that the following metrics are gated:
<img width="1402" height="722" alt="image"
src="https://github.com/user-attachments/assets/0c2757a2-8482-43f4-a65c-c0dde3d878c7"
/>
## 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?
Remove from preview, but keep local storage check for now for those who
enabled it.
## How to test
- Check the feature does not exist
- Enable the key manually
`localStorage.setItem('supabase-ui-api-side-panel', 'true')` to see it
work
Fixes a rendering bug where template URLs like
`https://<project-ref>.supabase.co/...` were displayed incorrectly in
Assistant responses. The markdown parser was treating `<project-ref>` as
a tag and silently stripping it.
- Adds `wrapPlaceholderUrls()` preprocessing step that auto-wraps bare
URLs containing `<kebab-case>` placeholders in backticks before passing
to the markdown renderer
- Strengthens the prompt instruction to explicitly say "always format
template URLs as inline code using backticks"
Sample prompt:
```
What are the OAuth2 endpoints for Supabase projects? List the authorization, token, and JWKS URLs.
```
| Before | After |
|--------|--------|
| <img width="1314" height="841" alt="CleanShot 2026-03-06 at 15 32
13@2x"
src="https://github.com/user-attachments/assets/55eaa0c6-39fb-48e0-91a0-31903021a4c9"
/> | <img width="1421" height="827" alt="CleanShot 2026-03-06 at 15 31
37@2x"
src="https://github.com/user-attachments/assets/5335c71a-19c7-44a0-b027-6f2efd76eb8c"
/> |
Closes AI-470
`concisenessScorer` was passing full serialized text + tool calls JSON
to the LLM judge (SQL queries, GraphQL payloads, etc.). Switches to
`extractTextOnly` so the judge only evaluates text the user actually
sees.
Prerequisite for https://github.com/supabase/supabase/pull/43613 to set
a fair conciseness baseline score.
Ref AI-402
## 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?
Spotted by @kostasb, index advisor was recommending slightly different
column names. Index advisor was running on mismatched queries thus
recommending for the wrong table.
Previously `connectionString` was passed into the query key for
`table-rows`. Since `connectionString` is unstable, it would cause the
query key to change randomly, often making the user experience brief
random "no rows found" states while data loaded for the new key.
This PR uses `readReplicaIdentifier` as a stable version of
`connectionString`, maintaining the existing functionality while
avoiding the unnecessary data reloads.
Note that there are still quite a few places where `connectionString` is
passed into the query key. We'll fix these as follow up PRs.
I'm opting to also include the fix from
https://github.com/supabase/supabase/pull/43572 in here for consistency.
**To test:**
- Ensure table editor functions normally
- Use the table editor with a read replica selected
New feature — adds a platform-only API endpoint to Studio.
## What is the current behavior?
`NEXT_PUBLIC_ONGOING_INCIDENT` is not exposed outside of the dashboard.
## What is the new behavior?
`GET /api/status-override` returns `{ enabled: boolean }` indicating
whether `NEXT_PUBLIC_ONGOING_INCIDENT` is set to `"true"`. The endpoint
returns 404 on self-hosted and is added to the proxy allowlist for
hosted platform access.
This is so that the incident banner bot can detect whether an override
is in place.
## Context
Adds a warning if running an `ALTER DATABASE` command that prevents
connections to the database. This would lock the dashboard out of the
database, and re-configuring the setting will require a direct
connection to the DB
<img width="623" height="535" alt="image"
src="https://github.com/user-attachments/assets/4c388f4a-753b-4fd6-89c5-89dfaa52c859"
/>
## To test
- Could try running the following command in the SQL editor to check the
warning, this will show all the warnings
```
ALTER TABLE colors2 drop column sss;
update colors set name = 'test';
alter database postgres connection limit 0;
```
## Context
Initial ground work for Marketplace Integrations (feature flagged under
the flag `marketplaceIntegrations`), in which some integrations will be
fetched over a network request (than hard-coded within the repo).
Feature flag just controls whether to we need to fetch them.
Similarly, categories under "Explore" will also be fetched, and the flag
just decides whether that should be enabled.
We're also planning to update the overview tab for integrations as well,
in which integrations fetched over the network request will use the new
UI (altho not functional just yet)
## To test
Note that the LOC changes are seemingly large, but that's just because
I've added in a types file for the Supabase project that we're using to
store the integrations data
- [x] Verify that behaviour is status quo with the flag off (Priority)
- [x] Verify that behaviour is status quo on CLI / self-host env
- [x] Verify that with the flag on you'll see one of the new
integrations fetched over network (Grafana), including an additional
category "Observability" (and clicking into it will show the new UI)
- [x] Verify that all other existing integrations are status quo
---------
Co-authored-by: Katerina Skroumpelou <sk.katherine@gmail.com>
Stacked PR 2/5 for page title improvements. Includes Auth, Database,
editors, and Edge Functions layout title adoption.
_Base:
[dnywh/feat/page-titles](https://github.com/supabase/supabase/pull/43538)_
---
## What kind of change does this PR introduce?
- Resolves FE-1960
- Resolves FE-1983
- Resolves DEPR-207
## What is the current behavior?
Page titles between surfaces are inconsistent and vague. Sometimes they
say the product name:
```
My Project | My Org | Supabase
```
...even when on a specific surface like Database > Tables.
Other times they show the entity name but skip over the project or org
name :
```
Edge Functions | Supabase
```
## What is the new behavior?
Auth, Database, editors, and Edge Functions adopt the layout title
format introduced in https://github.com/supabase/supabase/pull/43538:
```
users | Table Editor | My Project | My Org | Supabase
hello-world | Logs | Edge Functions | My Project | My Org | Supabase
Backups | Database | My Project | My Org | Supabase
Authentication | My Project | My Org | Supabase
```
That format is:
entity, section, surface, project, org, brand
## Additional context
Related stacked PRs also based on the the original
[dnywh/feat/page-titles](https://github.com/supabase/supabase/pull/43538)
branch:
- https://github.com/supabase/supabase/pull/43535
- https://github.com/supabase/supabase/pull/43536
- https://github.com/supabase/supabase/pull/43537
---------
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?
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
Editing a column from the schema visualiser requires many clicks
## Solution
When hovering over a column in the schema visualiser, an edit button
should appear on the right side. Clicking this button should open the
column edit pane on the right side of the screen. This would reduce the
number of clicks required and allow users to make edits directly from
the visualiser instead of using it only as a visual aid.
When saving Data API settings with only max rows changes (no
table/function privilege changes), updateExposedEntities sent an empty
string to pg-meta/query which failed server-side validation with 'String
must contain at least 1 character(s)'. Early return when there are no
SQL parts to execute.
## 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 PR changes the logic for show/hide password icon in the sign up
form. Fix#39399 and #41459
## What is the current behavior?
For Password Field Eye Icon Label
<ul>
<li>When password is hidden: Button shows "Hide password" label
(incorrect).
<li>When password is visible: Button shows "Show password" label
(incorrect)
</ul>
For Edge Functions Secrets
<ul>
<li>All secret values are always visible in plain text
<li>No visibility toggle functionality exists
<li>No way to hide/show individual secret values
</ul>
## What is the new behavior?
Sign-up Form Password Field:
<ul>
<li>When password is hidden: Button correctly shows "Show password"
label
<li>When password is visible: Button correctly shows "Hide password"
label</ul>
Labels now accurately describe what clicking the button will do
<p></p>
Edge Functions Secrets:
<ul>
<li>Secret values are hidden by default (security-first approach)
<li>Each secret has its own independent visibility toggle button
<li>Hidden secrets display as bullet points (•••••••••••••••••••••)
<li>Eye icon appears when secret is hidden - click to reveal
<li>EyeOff icon appears when secret is visible - click to hide
<li>Tooltip shows "Hidden" when value is masked, actual value when
visible</ul>
---------
Co-authored-by: Gildas Garcia <1122076+djhi@users.noreply.github.com>
Co-authored-by: Alaister Young <a@alaisteryoung.com>
**Changes:**
- Add function exposure controls to Data API settings
- Adds a per-function GRANT/REVOKE UI to the Data API settings page,
alongside the existing table selector.
- Empty state: shows "No tables/functions available" instead of "0 of 0
X exposed" when there's nothing to show
- Renamed update-exposed-tables-mutation →
update-exposed-entities-mutation to handle both tables and functions in
one save
**Decisions of note:**
- Functions are grouped by schema.name across overloads — toggling one
entry grants/revokes `EXECUTE` on all overloads
- Only normal and window functions are shown (`prokind in ('f', 'w')`) —
triggers and aggregates are excluded
---
**To test:**
- Table and schema selectors still works end-to-end
- Toggling a function and saving updates the count label and applies the
grant (check via SQL Editor: select * from
information_schema.role_routine_grants where routine_schema = 'public')
- Functions in unexposed schemas are dimmed and unclickable
- With no functions in the selected schemas, the selector label reads
"No functions available" and the dropdown shows the same
## Problem
When editing email templates or edge functions, users may navigate away
from the page without a warning indicating they may loose their changes.
This is because we only handle the `beforeunload` event when we should
also handle NextJS routing events.
This is actually done for the observability reports.
## Solution
Extract the logic from the observability reports into a reusable
component and use it where needed
## How to test
On staging, for each case:
- Authentication email templates
- Observability reports
- Edge functions creation
- Edge functions edition
Test:
- Modify the template/report/function
- Navigate away using either the sidebar link, the browser back button
or closing the tab
- Cancel navigation in the confirmation dialog
- Navigation should be prevented and you should not loose your changes
Test:
- Modify the template/report/function
- Navigate away using either the sidebar link, the browser back button
or closing the tab
- Confirm navigation in the confirmation dialog
- Navigation should not be prevented and you should have lost your
changes
## 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
Bug fix
## What is the current behavior?
Read-only users cannot download files because the download feature
requires minting a temporary API key, which is properly blocked for
read-only users.
## What is the new behavior?
Instead of using temporary API keys, we now create signed URLs for the
files to be downloaded. We batch-create signed URLs for an entire
folder's worth of files, requiring only a single management API call,
then use those signed URLs to download the files. This allows read-only
users to download files without needing elevated permissions.
## Additional context
Resolves FE-2737
## 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 filter by value for the new feature bar experience
- Will follow up with an E2E test later
## 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.
## 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 introduces a small snippet preview of the error code coming via our
content API for the docs. This appears in a couple of places right now.
- **Auth Overview** - This page isn't fully released yet, but it appears
on the error codes table (as depicted below).
- **Logs** - When you delve into the logs panel, if there's an error
code available, they're also wrapped in this popover.
We are also working on a shared-data package (#43458) to potentially
replace this endpoint internally. Also introduces a multifaceted button
to debug/fix with either Assistant or LLM of choice.
| Auth Overview | Logs Panel |
|--------|--------|
| <img width="407" height="287" alt="Screenshot 2026-03-09 at 14 14 09"
src="https://github.com/user-attachments/assets/7450dddb-6828-4cd3-802d-37d47ba1b440"
/> | <img width="394" height="216" alt="Screenshot 2026-03-09 at 14 13
56"
src="https://github.com/user-attachments/assets/80c2a46e-dbe4-4e88-a0a7-68b977a71d6b"
/> |
---------
Co-authored-by: Claude Sonnet 4.6 <noreply@anthropic.com>
Lays groundwork for online evals on Assistant chat logs.
https://www.braintrust.dev/docs/observe/score-online
### Changes
- New workflows:
- `braintrust-scorers-deploy.yml` keeps prod scorers in sync on push to
`master`
- `braintrust-preview-scorers-deploy.yml` deploys preview scorers to the
staging project for PRs labeled `preview-scorers`, posting a comment
with scorer links
([example](https://github.com/supabase/supabase/pull/43194#issuecomment-4000097222))
- `braintrust-preview-scorers-cleanup.yml` deletes preview scorers when
the PR is closed
([example](https://github.com/supabase/supabase/pull/43194#issuecomment-4000749847))
- Adds `evals/scorer-online.ts` entry point invoked with `pnpm
scorers:deploy`, registering scorers for online evals in the Braintrust
"Assistant" project
- Refactors scorer code to separate online-compatible scorers
(`scorer-online.ts`) from WASM-dependent ones (`scorer-wasm.ts`)
- "URL Validity" scorer now only checks Supabase domains to prevent
requests to untrusted origins
- Span `input` is now shaped `{ prompt: string }` instead of plain
`string` for compatibility with offline eval scorers
- Env vars `BRAINTRUST_STAGING_PROJECT_ID` and `BRAINTRUST_PROJECT_ID`
configured in GitHub repo settings
- `generateAssistantResponse` now uses `startSpan` + `withCurrent`
instead of `traced()` to manually manage the root span lifecycle — this
ensures `onFinish` logs output to the span _before_ `span.end()` is
called, which is when Braintrust triggers scoring automations
### Online Scorers
We share scoring logic across offline and online evals, but some of our
scorers aren't transferrable to an "online" setting due to runtime
challenges or ground truth requirements.
**Supported**
- Goal Completion
- Conciseness
- Completeness
- Docs Faithfulness
- URL Validity
**Unsupported**
- Correctness (requires ground truth output)
- Tool Usage (requires ground truth requiredTools)
- SQL Syntax (uses libpg-query WASM)
- SQL Identifier Quoting (uses libpg-query WASM)
### How to use these scorers
Going forward if you want to add/edit online eval scorers, add the
`preview-scorers` label to a PR. This deploys scorers to the [Assistant
(Staging
Scorers)](https://www.braintrust.dev/app/supabase.io/p/Assistant%20(Staging%20Scorers)?v=Overview)
project in Braintrust with branch-specific slugs, and comments on the PR
([example](https://github.com/supabase/supabase/pull/43194#issuecomment-4000097222)).
From the Braintrust dashboard you can "Test" the scorer with traces from
any project.
<img width="1866" height="528" alt="CleanShot 2026-03-05 at 15 15 00@2x"
src="https://github.com/user-attachments/assets/4f15cebc-3f2d-4e8a-9ee2-fe8ef7bf4199"
/>
Once merged, scorers are deployed to the primary
[Assistant](https://www.braintrust.dev/app/supabase.io/p/Assistant)
project, and preview scorers are deleted from the staging project. Down
the road, scorers on the Assistant project will run automatically on a
sample of production traces.
Closes AI-437
## Problem
- database e2e tests run in serial mode, which is slower
- they also are a bit flaky
## Solution
- Ensure they can run in parallel
- Make them more stable by using UI checks when waiting
- Use assertions that automatically wait/retry in playwright
## Problem
The `tableCreateGeneratePolicies` A/B experiment tested an AI-assisted
policy generator (`RLSManagement`) as a variation in the table creation
side panel. The variation didn't pass — control wins, so the standard
RLS checkbox should be the permanent behavior.
## Changes
- Deleted `useTableCreateGeneratePolicies` hook (PostHog flag + exposure
tracking)
- Deleted the entire `RLSManagement/` component directory (variation UI
— `RLSManagement`, `PolicyList`, `PolicyListEmptyState`,
`ToggleRLSButton`)
- Removed experiment flag checks from `TableEditor.tsx` — RLS checkbox
is now always rendered (was already the control)
- Removed experiment conversion tracking from `SidePanelEditor.tsx`
## Testing
Verified `pnpm typecheck` passes clean. Table creation side panel
renders the RLS checkbox unconditionally as it did in the control.
GROWTH-653
## Problem
The `projectCreationEnableRlsEventTrigger` A/B experiment tested showing
an opt-in "Enable automatic RLS" checkbox in the project creation flow,
which sets up a Postgres event trigger to auto-enable RLS on every new
table in the public schema. The test variant passed with a +3.3pp lift.
## Changes
- `SecurityOptions.tsx` — removed PostHog flag check, checkbox is now
always rendered
- `pages/new/[slug].tsx` — removed experiment flag reads, exposure
tracking (`useTrackExperimentExposure`), and the conditional
`rlsOptionVariant` telemetry property
The underlying feature logic (`enableRlsEventTrigger` form field,
`AUTO_ENABLE_RLS_EVENT_TRIGGER_SQL`, submission handling) is unchanged —
we're just removing the scaffolding that was gating it.
## Testing
Verified `pnpm typecheck` passes clean. The "Enable automatic RLS"
checkbox now shows unconditionally in the Security Options section of
project creation.
GROWTH-653
## Problem
- Some tests don't always cleanup after themselves or don't do it
consistently which make it hard to work on them locally
- Some test suites don't allow parallel execution of their tests
- Some tests are flaky
This a follow up of #43547
## What kind of change does this PR introduce?
- Resolves FE-1960
- Resolves FE-1983
- Resolves DEPR-207
## What is the current behavior?
Page titles between surfaces are inconsistent and vague. Sometimes they
say the product name:
```
My Project | My Org | Supabase
```
...even when on a specific surface like Database > Tables.
Other times they show the entity name but skip over the project or org
name :
```
Edge Functions | Supabase
```
## What is the new behavior?
Page titles *mostly* (see below) follow the same format:
```
users | Table Editor | My Project | My Org | Supabase
hello-world | Logs | Edge Functions | My Project | My Org | Supabase
Backups | Database | My Project | My Org | Supabase
Authentication | My Project | My Org | Supabase
```
That format is:
entity, section, surface, project, org, brand
## Additional context
This is stacked PR 1/5 for page title improvements. Includes the core
title utility and ProjectLayout integration/tests. Follow-up stacked PRs
are based on this branch:
- https://github.com/supabase/supabase/pull/43534
- https://github.com/supabase/supabase/pull/43535
- https://github.com/supabase/supabase/pull/43536
- https://github.com/supabase/supabase/pull/43537
This one should be merged first. The others (listed right above) can
_then_ be merged in any order.
## I have read the
[CONTRIBUTING.md](https://github.com/supabase/supabase/blob/master/CONTRIBUTING.md)
file.
YES
## What kind of change does this PR introduce?
Bug fix
## What is the current behavior?
Currently, the SMTP Host input field in the Project Dashboard
(Authentication > Email > SMTP Settings) does not sanitize whitespace.
If a user accidentally pastes a hostname with leading or trailing spaces
(e.g., " smtp.resend.com "), the DNS lookup fails during the OTP
delivery process.
This results in the following error in the Auth logs:
```"dial tcp: lookup smtp.resend.com on 127.0.0.53:53: server misbehaving"```
Noticed, the other input fields of Sender details and Host, Username and Password under SMTP Provider settings take leading and trailing whitespaces as well.
## What is the new behavior?
Input sanitization has been applied across the SMTP configuration schema. The following fields now utilize .trim() to ensure data integrity:
- SMTP_HOST
- SMTP_ADMIN_EMAIL & SMTP_SENDER_NAME
- SMTP_USER
- SMTP_PASS
## Screenshots:
Before Fix:
<img width="604" height="198" alt="Screenshot 2026-03-09 at 2 04 49 AM" src="https://github.com/user-attachments/assets/76ae23a6-3ad8-4f82-8f0f-ab12f4168e81" />
After Fix:
<img width="594" height="194" alt="Screenshot 2026-03-09 at 1 58 48 AM" src="https://github.com/user-attachments/assets/03f64294-0bfe-4fca-a82b-12ee07a6d218" />
This fixes the issue #43529
---------
Co-authored-by: Joshen Lim <joshenlimek@gmail.com>
Danny White