Organizational MFA enforcement
If you are an organization owner and on the Pro, Team, or Enterprise plan, you can enforce that all organization members must have MFA enabled.
platform
492 notes in this subject, read out of this brain and free to use. This is page 7 of 9.
Disable MFA in account settings
MFA can be disabled for a Supabase user account under account settings at the Supabase account security page. On subsequent login attempts after disabling MFA, users will not be prompted to enter an MFA code.
Supabase automatic performance optimization
The Supabase platform automatically optimizes your Postgres database to take advantage of the compute resources of the plan your project is on. These optimizations are based on assumptions about your workflow type, but better results can typically be obtained by tuning the database for your particular workflow.
Enterprise database tuning support
Enterprise customers can contact Supabase for help tuning their database for their specific workflow.
Network restrictions do not apply to HTTPS APIs
Network restrictions apply only to Postgres and the database pooler. They do not apply to HTTPS APIs such as PostgREST, Storage, and Auth, or to Supabase client libraries like supabase-js.
Network restrictions purpose and scope
Network restrictions let you control which IP ranges can connect to Postgres and its pooler. These restrictions are enforced before traffic reaches your database and reduce a project's exposure to unauthorized access. Connections that aren't restricted by IP still need to authenticate with valid database credentials.
Network restrictions prerequisite Postgres version
Network restrictions section is available in Database Settings only if you are running a current Postgres version. If you can't find the Network Restrictions section, you need to update your Postgres version in Infrastructure Settings.
Network restrictions IPv4 and IPv6 requirements
If direct connections to your database resolve to an IPv6 address, you must add both IPv4 and IPv6 CIDRs to your allowlist. Network restrictions apply to all connection routes whether pooled or direct. The exception is if you have an extension on the IPv6 migration or if you have the IPv4 add-on, in which case you only need to add IPv4 CIDRs.
Network restrictions dashboard access permissions
You need Owner or Admin permissions to make changes to network restrictions in the Database Settings page.
Permission violations may not cause immediate outage
Violations of schema ownership assumptions may not cause an immediate service outage. Instead, issues may take effect at a later time when a newer migration becomes available for the service.
Supabase services use database for operational data
Additional Supabase services such as Storage default to storing their operational data within your database. This design ensures you retain complete control over the data. Services assume base level access to their data to perform operations like running migrations.
Project transfer cannot change region
Project transfers only move projects across organizations within the same region and cannot be used to transfer projects between different regions. To move a project to a different region, use the project migration feature instead.
Project transfer downtime risk
Transferring a project might result in a short 1-2 minute downtime if you are moving a project from a paid to a Free Plan.
Project transfer plan downgrade risks
You could lose access to certain project features depending on the plan of the target organization. For example, moving a project from a Pro Plan to a Free Plan results in feature loss. When moving your project to a Free Plan, you must ensure you are not exceeding your two free project limit; it is best to upgrade your target organization to Pro Plan first. Additionally, you could have less rights on the project depending on your role in the target organization; for example, you might have been an Owner in the previous organization but only have a Read-Only role in the target organization.
Project transfer pre-requirements
To transfer a project, you must meet these requirements: (1) you need to be the owner of the source organization, (2) you need to be at least a member of the target organization you want to move the project to, (3) there must be no active GitHub integration connection, (4) there must be no project-scoped roles pointing to the project (Team/Enterprise plan only), and (5) there must be no log drains configured.
Project transfer overview
You can freely transfer projects between different organizations. Access the projects' general settings page to initiate a project transfer. The source organization is the organization the project currently belongs to, and the target organization is the organization you want to move the project to.
When to use Read Replicas decision flowchart
Do not scale until CPU is sustained above 70%. After sustained high CPU, optimize queries and add missing indexes using EXPLAIN ANALYZE before adding hardware. If workload is less than 80% reads, upgrade compute instead of using Read Replicas. If workload is read-heavy, use Read Replicas after reaching 16XL compute size, or earlier if you need workload isolation or geographic distribution. Below 16XL with no isolation need, either compute upgrade or Read Replicas works, though compute is simpler while Read Replicas scale further.
Read Replica dedicated endpoints
Each Read Replica has its own dedicated database and API endpoints. The database endpoint can be found on the Connect panel by toggling between Primary and Read Replicas using the Source dropdown. The API endpoint can be found on the API Settings page under Project URL, also toggled using the Source dropdown. If using an IPv4 add-on, Read Replica database endpoints also use an IPv4 add-on.
Read Replicas REST API limitations
Read Replicas only support GET requests from the REST API. To call a read-only Postgres function through the REST API on a Read Replica, set the get: true option. Requests to other Supabase products such as Auth, Storage, and Realtime cannot use a Read Replica or its API endpoint.
Read Replica connection pool
A dedicated connection pool through Supavisor is available for each Read Replica. The connection string can be found on the Database Settings page under Connection String.
API load balancer for Read Replicas
An API load balancer automatically balances requests between the Primary database and Read Replicas. The endpoint can be found on the API Settings page. The load balancer enables geo-routing for Data API requests to automatically route GET requests to the database closest to the user for lowest latency. Non-GET requests are routed to the Primary database automatically. All Auth requests are routed to the Primary even when sent over the load balancer endpoint.
API load balancer routing behavior change April 4 2025
From April 4th, 2025, the routing behavior for eligible Data API requests changed from round-robin distribution among all databases (read replicas and primary) regardless of location to geo-routing that directs requests to the closest available database. This new behavior minimizes latency to the project.
Custom domain incompatibility with load balancer
If using a custom domain, requests will not be routed through the load balancer. Use the dedicated endpoints provided in the dashboard instead.
SQL editor Read Replica selection
In the SQL editor, you can choose to run a query on a particular Read Replica.
Read Replica metrics and observability
Observability and metrics for Read Replicas are available on the Supabase Dashboard. Resource utilization for a specific Read Replica can be viewed on the Database Reports page by toggling the Source. Metrics on API requests through Read Replicas or Load Balancer API endpoints are available on the API Reports page. Project metrics can be ingested into your own environment, and existing Grafana ingestion pipelines can be updated to ingest metrics from Read Replicas.
Read Replica logging services
When a Read Replica is deployed, it emits logs from API, Postgres, PostgREST, and Supavisor services. In the Log Explorer, views are automatically filtered by databases with Primary database logs displayed by default. Logs from other databases can be toggled using the Source button on the upper-right section of the Logs Explorer page. For API logs, logs can originate from the API Load Balancer and the upstream database handling the request can be found in the Redirect Identifier field (equivalent to metadata.load_balancer_redirect_identifier when querying underlying logs).
Read Replica centralized configuration management
All settings configured through the dashboard are propagated across all databases of a project. This ensures that no Read Replica gets out of sync with the Primary database or with other Read Replicas.
Load balancer removal when Read Replicas deleted
If all Read Replicas are removed from a project, the load balancer and its endpoint are removed as well. Requests must be redirected back to the Primary database before removal of all Read Replicas.
Load balancer support for other Supabase services
The load balancer endpoint can be used to interact with other Supabase services including Auth, Edge Functions, Realtime, and Storage, eliminating the need to worry about which endpoint to use in different situations. Geo-routing for Auth, Realtime, and Storage are not yet available but are planned.
Read Replicas definition and purpose
Read Replicas are additional databases kept in sync with a Primary database. They help with load balancing by reducing load on the Primary database for complex analytical queries, improve latency for global user bases by deploying databases closer to users, and provide data redundancy.
Replication lag in Read Replicas
Replication between the Primary database and Read Replicas is asynchronous to ensure that transactions on the Primary are not blocked. This means there is a delay between an update on the Primary and when a Read Replica receives the change, called replication lag.
Read Replica operations supported
Read Replicas support only select (read) operations. Insert, update, and delete operations are not supported on Read Replicas. The Primary database supports all four operations: select, insert, update, and delete.
Operations blocked by Read Replicas
Project upgrades and data restorations require all Read Replicas for a project to be brought down before performing them. These operations need to complete before Read Replicas can be re-deployed.
Common causes of high replication lag
Common sources of high replication lag include: (1) Exclusive locks on tables on the Primary, such as from `drop table` and `reindex` operations which take access-exclusive locks, (2) Resource constraints on the database from heavy utilization on the primary or replica, including disk IOPS and throughput characteristics, (3) Long-running transactions on the Primary, which can be identified and terminated using the `pg_stat_activity` view (note: this is a live view and does not offer historical data).
Init failed Read Replica status troubleshooting
The 'Init failed' replica status indicates Read Replica deployment failure. Possible causes include: underlying instance failed to come up, network issues preventing connection to the Primary database, incompatible database settings between Primary and Read Replica, platform issues, or very high active workloads combined with large (50+ GB) database sizes. It is safe to drop a failed Read Replica and attempt to spin up another one. If deployments consistently fail, check the status page for ongoing incidents or open a support ticket. Do not bring down the recently failed Read Replica to aid investigation.
Monitoring replication lag in Read Replicas
Replication lag for a specific Read Replica can be monitored through the Database Reports page in the project dashboard, which displays a chart under Replica Information showing historical replication lag in seconds. Realtime replication lag in seconds is visible on the Infrastructure Settings page. The `physical_replication_lag_physical_replica_lag_seconds` metric can be used if project metrics are ingested into your own environment for tracking and setting alarms.
Read Replicas availability by plan
Read Replicas are available for all projects on the Pro, Team, and Enterprise plans.
Read Replicas prerequisites
To use Read Replicas, projects must meet these requirements: (1) Running on AWS, (2) Running on at least a Small compute add-on (Read Replicas start on the same compute instance as the Primary to keep up with changes), (3) Running on Postgres 15 or later (older versions require platform upgrade), (4) Not using legacy logical backups (physical backups are automatically enabled if using Point in Time Recovery).
Read Replica limits by compute size
Projects on an XL compute add-on or larger can create up to five Read Replicas. Projects on compute add-ons smaller than XL can create up to two Read Replicas. All Read Replicas inherit the compute size of their Primary database.
Read Replica deployment process
Read Replicas are deployed using a physical backup as a starting point, combined with write ahead logging (WAL) file archives and direct replication from the Primary database to catch up. Time to restore from physical backup depends on database size. Time to catch up using WAL archives and direct replication depends on activity level on the Primary database, with more active databases producing larger numbers of WAL files to process.
Streaming replication in Read Replicas
Streaming replication works by having Postgres generate a Write Ahead Log (WAL) as database changes occur, which streams directly from the Primary to the Read Replica server. This method is fast, but can fail if the Read Replica cannot keep up with WAL changes, which can happen if the Read Replica is too small, running on degraded hardware, or has a heavier workload. Postgres provides tunable configuration like `wal_keep_size` to adjust WAL retained by the Primary. If the Read Replica fails to catch up before the WAL surpasses the `wal_keep_size` setting, the replication terminates.
File-based log shipping in Read Replicas
File-based log shipping involves the Primary continuously buffering WAL changes to a local file and then sending the file to the Read Replica. If multiple Read Replicas exist, files could be sent to an intermediary location accessible by all replicas. The Read Replica then reads the WAL files and applies changes. There is higher replication lag than streaming replication since the Primary buffers changes locally first. There is a small chance WAL changes do not reach Read Replicas if the Primary goes down before the file is transferred.
Hybrid replication approach for Read Replicas
Supabase uses a hybrid approach combining streaming replication and file-based log shipping. Streaming replication minimizes replication lag, while file-based log shipping provides a fallback. For file-based log shipping, Supabase uses its Point In Time Recovery (PITR) infrastructure, regularly archiving files from the Primary using WAL-G and shipping WAL files to S3. Read Replicas connect to the Primary and stream WAL directly once WAL-G files have been synced from S3, reducing replication lag.
Read Replica behavior during project restart or compute change
When restarting a project with Read Replicas or changing the compute add-on size, the Primary database is restarted first while Read Replicas remain available. Once the Primary completes restarting (or resizing) and becomes available, all Read Replicas are restarted (and resized if needed) concurrently.
SSO availability and plans
Supabase SSO is available for Team and Enterprise Plan customers only. It is not available on other plan tiers.
Database size reduction during upgrade
As part of the upgrade process, maintenance operations such as vacuuming are executed. This can result in a reduction in the reported database size.
Breaking changes in service upgrades
Newer versions of services can break functionality or change performance characteristics. Breaking changes are generally only present in major version upgrades of Postgres and PostgREST. Release notes are available at: Postgres (https://www.postgresql.org/docs/release/) and PostgREST (https://github.com/PostgREST/postgrest/releases). If upgrading from a significantly older version, consider release notes for any intermediary releases as well.
Free vs paid projects pause and upgrade behavior
Free projects will move to the latest minor version when their paused project is restored. Paid projects cannot be paused.
Paused project restore window
When a project is paused, users have a 1-year window to restore the project on the platform from within Supabase Studio. This restore window exists because backups are only retained for a limited period and platform changes may not be backwards compatible with older backups. After the restore window, you can only download your project's backup file and Storage objects from the project dashboard.
Upgrade process steps
The Supabase upgrade process follows these steps: 1) Use the 'Upgrade project' button on the Infrastructure section of your dashboard. 2) An estimate of upgrade time is shown along with any warnings about blocking issues. 3) Your project is taken offline and the Dashboard shows upgrade status. 4) A new instance is created running the latest version of Supabase. 5) Your data is copied to the new instance and upgraded using pg_upgrade. 6) If upgrade fails, your original database is brought back online. 7) When upgrade succeeds, a pg_basebackup is taken and your project becomes available in the Dashboard.
Upgrade downtime estimation
A Supabase project deployed with a GP3 disk type by default provides approximately 100Mbps when upgrading. You can derive an approximation of downtime necessary for upgrade by using your database size as a metric. During the upgrade window, the database and associated services will be unavailable.
Upgrade pre-requisites blocking conditions
Before upgrading, the following conditions must be addressed: 1) Projects with read-replicas cannot be upgraded; delete replicas and recreate them after upgrade. 2) pg_upgrade does not support databases containing reg* data types referencing system OIDs; modify data to not use reg* data types before upgrade. 3) Logical replication slots must be dropped. 4) Deprecated or unsupported extensions must be dropped; backup data from extensions with dependencies to restore after upgrade with updated extension versions.
Pre-upgrade best practices
Before upgrading: 1) Discuss with teams a suitable maintenance window as upgrading involves downtime. 2) For smaller databases, take a logical backup using pg_dump to ensure sufficient backup before upgrading. 3) For larger databases, ensure a recent backup exists in the Backups page of the Dashboard. 4) Reduce database data size and number of objects, as upgrade time depends on these factors. Consider archiving inactive data, dropping unused indexes, and running vacuum. Use the Supabase CLI inspect command for detailed reports on space that can be gained.
Post-upgrade best practices
After upgrading: 1) Plan for your own application-level validations as there might be unanticipated changes; budget this into the downtime window. 2) Analyze logs for new slow-running queries that may have emerged post-upgrade due to changes in data structure. 3) Verify extension versions and identify extensions you need to upgrade.
Disk sizing during upgrade
When upgrading, Supabase right-sizes your disk based on current database size. For example, if your database is 100GB in size and you have a 200GB disk, the upgrade will reduce the disk size to 120GB (1.2x the size of your database).
Product-specific security configuration guides
Each Supabase product comes with customizable security controls. Detailed information for configuring security controls for individual products is available in the security configuration guides.
Supabase HIPAA compliance and add-on
Supabase provides HIPAA compliance support with a HIPAA add-on available for projects that deal with electronic Protected Health Information (ePHI). Additional security and compliance controls for HIPAA compliance are managed through this add-on. Details are covered in the HIPAA Compliance Guide.
Supabase ISO 27001 certification
Supabase is ISO 27001 certified. ISO 27001 is an internationally recognized standard for information security management systems (ISMS), confirming that Supabase maintains rigorous controls to protect customer data. Enterprise and Team customers can access the ISO 27001 certificate on the dashboard.
Supabase GDPR compliance and data residency
Supabase supports GDPR-related requirements through EU-region hosting for data residency and provides a Data Processing Agreement (DPA) for customers who need one. The GDPR compliance guide covers shared responsibility, residency scope, and the DPA.
Supabase platform security controls location
Security controls for the Supabase hosted platform can be found on the dedicated security page under organization settings in the dashboard, at /dashboard/org/_/security. These controls are described in detail in the platform security documentation.