INDATA-193
BACKEND: <https://github.com/supabase/platform/pull/30575>
<img width="1199" height="1005" alt="Screenshot 2026-04-03 at 11 54 29"
src="https://github.com/user-attachments/assets/38e9d676-449f-45c0-9e07-f273312a812f"
/>
<!-- This is an auto-generated comment: release notes by coderabbit.ai
-->
## Summary by CodeRabbit
* **Refactor**
* Consolidated read replica limit configuration to provide more
consistent behavior across different compute tiers.
* **Tests**
* Added comprehensive test coverage for read replica eligibility checks
and replica limit calculations based on compute tier.
<!-- end of auto-generated comment: release notes by coderabbit.ai -->
## 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)
## Context
Part of dashboard scalability project
Opting to use the connection string of the project's read replica (if
available) for read queries on the database.
Trialing with the Table Editor as a first pass - changes involved will
opt to use replica connection string for `useTableRowsQuery`,
`useTableRowsCountQuery`, and `useForeignKeyConstraintsQuery`
There's definitely optimizations to be done for deciding which replica
to use - but am starting off with a rather naive logic to prioritize
replicas in the same region as the project.
## Changes involved
- We're no longer passing `connectionString` as a param into the
affected hooks, the `connectionString` is derived from within those
hooks instead
- Change is feature flagged, so things should be status quo if flag is
off (use primary database's connection string)
- Added `useConnectionStringForReadOps` hook which returns the replica's
connection string if (Otherwise defaults to primary database connection
string)
- Feature flag is on
- Project has a replica available
## To test
- [ ] Verify that the table editor works as expected for a project that
has read replicas (There shouldn't be any change really)
- [ ] Also just double check that updating cells in the table editor
works as well (There's no change there, we're using the primary DB's
connection string for mutation ops)
- [ ] ^ Same thing for a project that doesn't have read replicas
- [ ] ^ Same thing for local / self-host
* Bump the deps, refactor deprecated code.
* Migrate keepPreviousData usage.
* Migrate all uses of InfiniteQuery.
* Fix refetchInterval in queries.
* Migrate all use of isLoading to isPending in mutations.
* Fix accessing location in claim-project.
* Fix a bug in duplicate query keys.
* Migrate all queries to use isPending.
* Revert "Fix accessing location in claim-project."
This reverts commit 2a07df64b5.
* Revert the rss.xml file to master.
* Add custom types for queries, mutations and infinite queries.
* Migrate all queries to use the new type.
* Migrate all infinite queries to useCustomInfiniteQueryOptions.
* Migrate all mutations to use useCustomMutationOptions.
* Add type to all imports in `types` folder.
* First round of wrapping RQ errors with handleError
* Remove the throw before the handleError usage.
* Make the handling of an API error more versatile. Add logging in Sentry if the error is of unknown type.
* Remove throwing of the handleError function.
* Add return type to the handleError function to be never so that we're sure it always throws.
* Second round of wrapping RQ errors with handleError
* Temp fix in delete credential mutation, and fix loading state
---------
Co-authored-by: Ivan Vasilov <vasilov.ivan@gmail.com>
* Only show RR UI if project is enabled
* Only show RR UI if project has read replicas enabled, shift DatabaseSelector state to valtio, add Database Selector to API URl
* Update usage of Project interface from types to Project from project-details-query
* Fix ts errors
* Another one
* Another one...
* God one more
* Fingers crossed
* jesus
* Add deprecate mark on ProjectBase
* Resolve conflicts
* Rename ProjectState from valtio to DatabaseSelectorState
* Rename file
* fix imports
* tiny code changes
* Fixes
---------
Co-authored-by: Alaister Young <a@alaisteryoung.com>
* Implement read, create, delete replicas
* Long poll replica statuses if any one of them is coming up
* Support querying replicas in SQL editor
* Add optimistic rendering for setting up and removing replicas
* Small style fix for database selector in SQL editor
* Small fix
* Add Alerts around PITR and PG upgrades RE read replicas
* Small fixes after testing flag off
* Add UI guards to check that project has PITR before deploying replica
* Fix
* Address feedback
* Fix
* Update replicas RQ to enable based on flag
Giuseppe Mandato