[pull] master from supabase:master

apps/docs/content/guides/database/prisma/prisma-troubleshooting.mdx

@@ -25,15 +25,15 @@ These options, called "query parameters," can be used to address specific errors
 connection_string.../postgres?KEY1=VALUE&KEY2=VALUE&KEY3=VALUE
 ```
 
-# Errors
+## Errors
 
 {/* supa-mdx-lint-disable-next-line Rule001HeadingCase */}
 
-## ... prepared statement already exists
+### Prepared statement already exists
 
 Supavisor in transaction mode (port 6543) does not support [prepared statements](https://www.postgresql.org/docs/current/sql-prepare.html), which Prisma will try to create in the background.
 
-### Solution: [#solution-prepared-statement-exists]
+#### Solution: [#solution-prepared-statement-exists]
 
 - Add `pgbouncer=true` to the connection string. This turns off prepared statements in Prisma.
 
@@ -43,17 +43,17 @@ Supavisor in transaction mode (port 6543) does not support [prepared statements]
 
 ---
 
-## Can't reach database server at:
+### Can't reach the database server
 
-Prisma couldn't establish a connection with Postgres or Supavisor before the timeout
+Prisma couldn't establish a connection with Postgres or Supavisor before the timeout.
 
-### Possible causes: [#possible-causes-cant-reach-database-server-at]
+#### Possible causes: [#possible-causes-cant-reach-database-server-at]
 
 - **Database overload**: The database server is under heavy load, causing Prisma to struggle to connect.
 - **Malformed connection string**: The connection string used by Prisma is incorrect or incomplete.
 - **Transient network issues**: Temporary network problems are disrupting the connection.
 
-### Solutions: [#solution-cant-reach-database-server-at]
+#### Solutions: [#solution-cant-reach-database-server-at]
 
 - **Check database health**: Use the [Observability Dashboard](/dashboard/project/_/observability/database) to monitor CPU, memory, and I/O usage. If the database is overloaded, consider increasing your [compute size](/docs/guides/platform/compute-add-ons) or [optimizing your queries](/docs/guides/database/query-optimization).
 - **Verify connection string**: Double-check the connection string in your Prisma configuration to ensure it matches in your [project connect page](/dashboard/project/_?showConnect=true).
@@ -65,17 +65,17 @@ Prisma couldn't establish a connection with Postgres or Supavisor before the tim
 
 ---
 
-## Timed out fetching a new connection from the connection pool:
+### Timed out fetching a new connection from the connection pool
 
 Prisma is unable to allocate connections to pending queries fast enough to meet demand.
 
-### Possible causes: [#possible-causes-timed-out-fetching-a-new-connection]
+#### Possible causes: [#possible-causes-timed-out-fetching-a-new-connection]
 
 - **Overwhelmed server**: The server hosting Prisma is under heavy load, limiting its ability to manage connections. By default, Prisma will create the default `num_cpus * 2 + 1` worth of connections. A common cause for server strain is increasing the `connection_limit` significantly past the default.
 - **Insufficient pool size**: The Supavisor pooler does not have enough connections available to quickly satisfy Prisma's requests.
 - **Slow queries**: Prisma's queries are taking too long to execute, preventing it from releasing connections for reuse.
 
-### Solutions: [#solution-timed-out-fetching-a-new-connection]
+#### Solutions: [#solution-timed-out-fetching-a-new-connection]
 
 - **Increase the pool timeout**: Increase the `pool_timeout` parameter in your Prisma configuration to give the pooler more time to allocate connections.
 - **Reduce the connection limit**: If you've explicitly increased the `connection_limit` parameter in your Prisma configuration, try reducing it to a more reasonable value.
@@ -85,43 +85,43 @@ Prisma is unable to allocate connections to pending queries fast enough to meet
 
 ---
 
-## Server has closed the connection
+### Server has closed the connection
 
 According to this [GitHub Issue for Prisma](https://github.com/prisma/prisma/discussions/7389), this error may be related to large return values for queries. It may also be caused by significant database strain.
 
-### Solutions: [#solution-server-has-closed-the-connection]
+#### Solutions: [#solution-server-has-closed-the-connection]
 
 - **Limit row return sizes**: Try to limit the total amount of rows returned for particularly large requests.
 - **Minimize database strain**:Check the Reports Page for database strain. If there is obvious strain, consider [optimizing](/docs/guides/database/query-optimization) or increasing compute size
 
 ---
 
-## Drift detected: Your database schema is not in sync with your migration history
+### Drift detected: Your database schema is not in sync with your migration history
 
 Prisma relies on migration files to ensure your database aligns with Prisma's model. External schema changes are detected as "drift", which Prisma will try to overwrite, potentially causing data loss.
 
-### Possible causes: [#possible-causes-your-database-schema-is-not-in-sync]
+#### Possible causes: [#possible-causes-your-database-schema-is-not-in-sync]
 
 - **Supabase Managed Schemas**: Supabase may update managed schemas like auth and storage to introduce new features. Granting Prisma access to these schemas can lead to drift during updates.
 - **External Schema Modifications**: Your team or another tool might have modified the database schema outside of Prisma, causing drift.
 
-### Solution: [#solution-your-database-schema-is-not-in-sync]
+#### Solution: [#solution-your-database-schema-is-not-in-sync]
 
 - **Baselining migrations**: [baselining](https://www.prisma.io/docs/orm/prisma-migrate/workflows/baselining) re-syncs Prisma by capturing the current database schema as the starting point for future migrations.
 
 ---
 
-## Max client connections reached
+### Max client connections reached
 
 Postgres or Supavisor rejected a request for more connections
 
-### Possible causes:[#possible-causes-max-client-connections-reached]
+#### Possible causes:[#possible-causes-max-client-connections-reached]
 
 - **When working in transaction mode (port 6543):** The error "Max client connections reached" occurs when clients try to form more connections with the pooler than it can support.
 - **When working in session mode (port 5432):** The max amount of clients is restricted to the "Pool Size" value in the [Database Settings](/dashboard/project/_/database/settings). If the "Pool Size" is set to 15, even if the pooler can handle 200 client connections, it will still be effectively capped at 15 for each unique ["database-role+database" combination](https://github.com/orgs/supabase/discussions/21566).
 - **When working with direct connections**: Postgres is already servicing the max amount of connections
 
-### Solutions [#solutions-causes-max-client-connections-reached]
+#### Solutions [#solutions-causes-max-client-connections-reached]
 
 - **Transaction Mode for serverless apps**: If you are using serverless functions (Supabase Edge, Vercel, AWS Lambda), switch to transaction mode (port 6543). It handles more connections than session mode or direct connections.
 - **Reduce the number of Prisma connections**: A single client-server can establish multiple connections with a pooler. Typically, serverless setups do not need many connections. Starting with fewer, like five or three, or even just one, is often sufficient. In serverless setups, begin with `connection_limit=1`, increasing cautiously if needed to avoid maxing out connections.
@@ -132,15 +132,15 @@ Postgres or Supavisor rejected a request for more connections
 
 ---
 
-## Cross schema references are only allowed when the target schema is listed in the schemas property of your data-source
+### Cross schema references are only allowed when the target schema is listed in the schemas property of your data-source
 
 A Prisma migration is referencing a schema it is not permitted to manage.
 
-### Possible causes: [#possible-causes-cross-schema-references]
+#### Possible causes: [#possible-causes-cross-schema-references]
 
 - A migration references a schema that Prisma is not permitted to manage
 
-### Solutions: [#solutions-cross-schema-references]
+#### Solutions: [#solutions-cross-schema-references]
 
 - Multi-schema support: If the external schema isn't Supabase managed, list the relevant schemas on the `datasource` block in your `schema.prisma` file.
 

apps/docs/content/guides/database/testing.mdx

@@ -10,13 +10,13 @@ To ensure that queries return the expected data, RLS policies are correctly appl
 
 - Secondly, you can test through the Supabase CLI, which is a more low-level approach where you write tests in SQL.
 
-# Testing using the Supabase CLI
+## Testing using the Supabase CLI
 
 You can use the Supabase CLI to test your database. The minimum required version of the CLI is [v1.11.4](https://github.com/supabase/cli/releases). To get started:
 
 - [Install the Supabase CLI](/docs/guides/cli) on your local machine
 
-## Creating a test
+### Creating a test
 
 Create a tests folder inside the `supabase` folder:
 
@@ -30,7 +30,7 @@ Create a new file with the `.sql` extension which will contain the test.
 touch ./supabase/tests/database/hello_world.test.sql
 ```
 
-## Writing tests
+### Writing tests
 
 All `sql` files use [pgTAP](/docs/guides/database/extensions/pgtap) as the test runner.
 
@@ -51,7 +51,7 @@ select * from finish();
 rollback;
 ```
 
-## Running tests
+### Running tests
 
 To run the test, you can use:
 
@@ -69,7 +69,7 @@ Files=1, Tests=1,  1 wallclock secs ( 0.01 usr  0.00 sys +  0.04 cusr  0.02 csys
 Result: PASS
 ```
 
-## More resources
+### More resources
 
 - [Testing RLS policies](/docs/guides/database/extensions/pgtap#testing-rls-policies)
 - [pgTAP extension](/docs/guides/database/extensions/pgtap)

apps/docs/content/guides/platform/migrating-within-supabase/backup-restore.mdx

@@ -4,9 +4,9 @@ subtitle: 'Learn how to backup and restore projects using the Supabase CLI'
 breadcrumb: 'Migrations'
 ---
 
-# Migrating the database
+## Migrating the database
 
-## Backup database using the CLI
+### Back up database using the CLI
 
 <StepHikeCompact>
   <StepHikeCompact.Step step={1}>
@@ -74,7 +74,7 @@ breadcrumb: 'Migrations'
 
 </StepHikeCompact>
 
-## Before you begin
+### Before you begin
 
 <Accordion
   type="default"
@@ -91,7 +91,7 @@ breadcrumb: 'Migrations'
   </div>
 </Accordion>
 
-## Restore backup using CLI
+### Restore backup using CLI
 
 <StepHikeCompact>
     <StepHikeCompact.Step step={1}>
@@ -197,9 +197,9 @@ breadcrumb: 'Migrations'
 
 </StepHikeCompact>
 
-## Special considerations
+### Special considerations
 
-#### Preserving migration history
+##### Preserving migration history
 
 If you were using Supabase CLI for managing migrations on your old database and would like to preserve the migration history in your newly restored project, you need to insert the migration records separately using the following commands.
 
@@ -214,7 +214,7 @@ psql \
   --dbname "$NEW_DB_URL"
 ```
 
-#### Schema changes to `auth` and `storage`
+##### Schema changes to `auth` and `storage`
 
 If you have modified the `auth` and `storage` schemas in your old project, such as adding triggers or Row Level Security(RLS) policies, you have to restore them separately. The Supabase CLI can help you diff the changes to these schemas using the following commands.
 
@@ -223,21 +223,21 @@ supabase link --project-ref "$OLD_PROJECT_REF"
 supabase db diff --linked --schema auth,storage > changes.sql
 ```
 
-## Troubleshooting notes
+### Troubleshooting notes
 
-#### Disabling triggers during restore:
+##### Disabling triggers during restore:
 
 Setting `session_replication_role` to `replica` disables triggers during the migration, preventing columns from being double encrypted.
 
-#### Custom roles require passwords
+##### Custom roles require passwords
 
 If you created any [custom roles](/dashboard/project/_/database/roles) with the `LOGIN` attribute, you must manually set their passwords in the new project. This can be done with the SQL command:
 
 ```sql
 alter user "YOUR_USER" with password 'SOME_NEW_PASSWORD';
 ```
 
-#### `supabase_admin` permission errors
+##### `supabase_admin` permission errors
 
 If you encounter permission errors related to `supabase_admin` during restore:
 
@@ -248,7 +248,7 @@ If you encounter permission errors related to `supabase_admin` during restore:
   ALTER ... OWNER TO "supabase_admin"
 ```
 
-#### `cli_login_postgres` role grant error
+##### `cli_login_postgres` role grant error
 
 If you encounter the error:
 
@@ -264,7 +264,7 @@ DETAIL:  Only roles with the ADMIN option on role "postgres" may grant this role
 GRANT "postgres" TO "cli_login_postgres" WITH INHERIT FALSE GRANTED BY "supabase_admin";
 ```
 
-#### `cli_login_postgres` role issues after cloning
+##### `cli_login_postgres` role issues after cloning
 
 The `cli_login_role` must be created by the `supabase_admin` role. If the migration process cloned over the role before the CLI could generate its own version, it may encounter the error:
 
@@ -279,9 +279,9 @@ To resolve the issue, drop the custom `cli_login_postgres` role. Then the CLI ca
 DROP ROLE IF EXISTS cli_login_postgres;
 ```
 
-# Migrating edge functions
+## Migrating edge functions
 
-## Steps (using the Supabase CLI):
+### Steps (using the Supabase CLI):
 
 <StepHikeCompact>
   <StepHikeCompact.Step step={1}>
@@ -326,7 +326,7 @@ DROP ROLE IF EXISTS cli_login_postgres;
   </StepHikeCompact.Step>
 </StepHikeCompact>
 
-## Steps (using the Supabase Dashboard):
+### Steps (using the Supabase Dashboard):
 
 <Admonition type="note">
 
@@ -369,7 +369,7 @@ Dependencies defined through [import maps](/docs/guides/functions/dependencies#u
   </StepHikeCompact.Step>
 </StepHikeCompact>
 
-# Migrating storage objects
+## Migrating storage objects
 
 <StepHikeCompact>
   <StepHikeCompact.Step step={1}>
@@ -808,6 +808,6 @@ Dependencies defined through [import maps](/docs/guides/functions/dependencies#u
 
 </StepHikeCompact>
 
-## Resources
+### Resources
 
 - [Connecting with PSQL](/docs/guides/database/psql)

apps/docs/content/guides/security.mdx

@@ -8,20 +8,20 @@ hideToc: true
 
 Supabase is a hosted platform to get you started without needing to manage any infrastructure yourself. The hosted platform comes with many security and compliance controls managed by Supabase.
 
-# Compliance
+## Compliance
 
 Supabase is SOC 2 Type 2 compliant and regularly audited. All projects at Supabase are governed by the same set of compliance controls.
 The [SOC 2 Compliance Guide](/docs/guides/security/soc-2-compliance) explains Supabase's SOC 2 responsibilities and controls in more detail.
 
 The [HIPAA Compliance Guide](/docs/guides/security/hipaa-compliance) explains Supabase's HIPAA responsibilities. Additional [security and compliance controls](/docs/guides/deployment/shared-responsibility-model#managing-healthcare-data) for projects that deal with electronic Protected Health Information (ePHI) and require HIPAA compliance are available through the HIPAA add-on.
 
-# Platform configuration
+## Platform configuration
 
 As a hosted platform, Supabase provides additional security controls to further enhance the security posture depending on organizations' own requirements or obligations.
 
 These can be found under the [dedicated security page](/dashboard/org/_/security) under organization settings. And are described in greater detail [here](/docs/guides/security/platform-security).
 
-# Product configuration
+## Product configuration
 
 Each product offered by Supabase comes with customizable security controls and these security controls help ensure that applications built on Supabase are secure, compliant, and resilient against various threats.
 

apps/docs/content/guides/security/soc-2-compliance.mdx

@@ -21,32 +21,32 @@ Our [HIPAA documentation](/docs/guides/security/hipaa-compliance) provides more
 
 </Admonition>
 
-# Meeting compliance requirements
+## Meeting compliance requirements
 
 SOC 2 compliance is a critical aspect of data security for Supabase and our customers. Being fully SOC 2 compliant is a shared responsibility and here’s a breakdown of the responsibilities for both parties:
 
-### Supabase responsibilities
+#### Supabase responsibilities
 
 1. **Security Measures**: Supabase implements robust security controls to protect customer data. These includes measures to prevent data breaches and ensure the confidentiality and integrity of the information managed and stored by the platform. Supabase is obliged to be vigilant about security risks and must demonstrate that our security measures meet industry standards through regular audits.
 2. **Compliance Audits**: Supabase undergoes SOC 2 audits yearly to verify that our data management practices comply with the Trust Services Criteria (TSC), which include security, availability, processing integrity, confidentiality, and privacy. These audits are conducted by an independent third party.
 3. **Incident Response**: Supabase has an incident response plan in place to handle data breaches efficiently. This plan outlines how the organization detects issues, responds to incidents, and manages system vulnerabilities.
 4. **Reporting**: Upon a successful audit, Supabase receive a SOC 2 report that details our compliance status. This report is available to customers as a SOC 2 Type 2 report, and allows customers and stakeholders to assure that Supabase has implemented adequate and the requisite safeguards to protect sensitive information.
 
-### Customer responsibilities
+#### Customer responsibilities
 
 1. **Compliance Requirements**: Understand your own compliance requirements. While SOC 2 compliance is not a legal requirement, many enterprise customers require their providers to have a SOC 2 report. This is because it provides assurance that the provider has implemented robust controls to protect customer data.
 2. **Due Diligence**: Customers must perform due diligence when selecting Supabase as a provider. This includes reviewing the SOC 2 Type 2 report to ensure that Supabase meets the expected security standards. Customers should also understand the division of responsibilities between themselves and Supabase to avoid duplication of effort.
 3. **Monitoring and Review**: Customers should regularly monitor and review Supabase’s compliance status.
 4. **Control Compliance**: If a customer needs to be SOC 2 compliant, they should themselves implement the requisite controls and undergo a SOC 2 audit.
 
-### Shared responsibilities
+#### Shared responsibilities
 
 1. **Data Security**: Both customers and Supabase share the responsibility of ensuring data security. While the Supabase, as the provider, implements the security controls, the customer must ensure that their use of the Supabase platform does not compromise these controls.
 2. **Control Compliance**: Supabase asserts through our SOC 2 that all requisite security controls are met. Customers wishing to also be SOC 2 compliant need to go through their own SOC 2 audit, verifying that security controls are met on the customer's side.
 
 In summary, SOC 2 compliance involves a shared responsibility between Supabase and our customers to ensure the security and integrity of data. Supabase, as a provider, must implement and maintain robust security measures, customers must perform due diligence and monitor Supabase's compliance status, while also implement their own compliance controls to protect their sensitive information.
 
-## Frequently asked questions
+### Frequently asked questions
 
 **How often is Supabase SOC 2 audited?**
 
@@ -78,7 +78,7 @@ While SOC 2 itself does not mandate specific data residency requirements, organi
 SOC 2 is non-industry specific and provides a framework for the security and privacy of data. This is however not sufficient in most cases when dealing with Protected Healthcare Information (PHI), which requires additional privacy and legal controls.
 When dealing with PHI in the United States or for United States customers, HIPAA is mandatory.
 
-## Resources
+### Resources
 
 1. [System and Organization Controls: SOC Suite of Services](https://www.aicpa-cima.com/resources/landing/system-and-organization-controls-soc-suite-of-services)
 2. [Shared Responsibility Model](/docs/guides/deployment/shared-responsibility-model)