Upgrade to Pro
++ Customize templates while using Supabase’s email service +
+Configure Send Email hook
++ Send auth emails through your own workflow +
+
+```mermaid
+erDiagram
+ buckets ||--o{ objects : "buckets_id:id"
+ buckets {
+ text id PK
+ text name
+ timestamptz created_at
+ timestamptz updated_at
+ boolean public
+ bigint file_size_limit
+ text[] allowed_mime_types
+ text owner_id
+ }
+ objects {
+ uuid id PK
+ text bucket_id FK
+ text name
+ timestamptz created_at
+ timestamptz updated_at
+ jsonb metadata
+ text[] path_tokens
+ text version
+ text owner_id
+ }
+ migrations {
+ integer id PK
+ varchar(100) name
+ varchar(40) hash
+ timestamp executed_at
+ }
+```
-You have the option to query this table directly to retrieve information about your files in Storage without the need to go through our API.
+The schema centers on three tables. Each `buckets` row can own many `objects` rows by a one-to-many relationship that joins `buckets.id` to `objects.bucket_id`. The `buckets` table holds bucket configuration. Its `id` and `name`, whether the bucket is `public`, and constraints such as `file_size_limit` and `allowed_mime_types`. The `objects` table holds per-file metadata: the owning `bucket_id`, the object `name` and `path_tokens`, a `metadata` JSON blob, and version information. The `migrations` table is standalone and tracks the schema migrations applied to the storage service.
## Modifying the schema
diff --git a/apps/docs/content/guides/storage/security/ownership.mdx b/apps/docs/content/guides/storage/security/ownership.mdx
index 10f724d6841..dd0d6aa8ae2 100644
--- a/apps/docs/content/guides/storage/security/ownership.mdx
+++ b/apps/docs/content/guides/storage/security/ownership.mdx
@@ -36,4 +36,4 @@ using (
);
```
-The use of RLS policies is just one way to enforce access control. You can also implement access control in your server code by following the same pattern.
+The use of RLS policies is one way to enforce access control. You can also implement access control in your server code by following the same pattern.
diff --git a/apps/docs/content/guides/telemetry/logs.mdx b/apps/docs/content/guides/telemetry/logs.mdx
index 9f5d9ae85bc..0d41674f528 100644
--- a/apps/docs/content/guides/telemetry/logs.mdx
+++ b/apps/docs/content/guides/telemetry/logs.mdx
@@ -147,6 +147,8 @@ Do not log Personal Identifiable Information (PII) within the `User-Agent` heade
Postgres can log connection lifecycle events to your project's Postgres logs, for example when a client connects or authenticates. By default, Supabase sets `log_connections` to off for new projects and you must enable it first.
+<$Partial path="log_connections_default_effective_date.mdx" />
+
To enable connection logging for audit or compliance, see [Postgres connection logging](/docs/guides/platform/postgres-connection-logging).
In the [Logs Explorer](/dashboard/project/_/logs-explorer), connection lifecycle messages may be hidden by default. Use the connection logs filter in the sidebar to show them.
diff --git a/apps/docs/content/navigation.references.ts b/apps/docs/content/navigation.references.ts
index dc4f4c137a0..b1a1fc10972 100644
--- a/apps/docs/content/navigation.references.ts
+++ b/apps/docs/content/navigation.references.ts
@@ -39,8 +39,10 @@ export const REFERENCES = {
icon: 'reference-dart',
meta: {
v2: {
+ // Dart v2 is driven by the new reference pipeline
+ // (`scripts/build-reference-content.ts` + `spec/reference/dart/v2/`).
+ // It intentionally has no `specFile`, so the legacy YAML loader skips it.
libId: 'reference_dart_v2',
- specFile: 'supabase_dart_v2',
},
v1: {
libId: 'reference_dart_v1',
diff --git a/apps/docs/content/troubleshooting/disabling-prepared-statements-qL8lEL.mdx b/apps/docs/content/troubleshooting/disabling-prepared-statements-qL8lEL.mdx
index bddc58bf5f7..c9741c78913 100644
--- a/apps/docs/content/troubleshooting/disabling-prepared-statements-qL8lEL.mdx
+++ b/apps/docs/content/troubleshooting/disabling-prepared-statements-qL8lEL.mdx
@@ -31,7 +31,7 @@ export const client = postgres(connectionString, { prepare: false })
## Node Postgres
-[Just omit the "name" value in a query definition](https://node-postgres.com/features/queries#prepared-statements):
+[Omit the "name" value in a query definition](https://node-postgres.com/features/queries#prepared-statements):
```ts
const query = {
diff --git a/apps/docs/content/troubleshooting/edge-function-500-error-response.mdx b/apps/docs/content/troubleshooting/edge-function-500-error-response.mdx
index c28c5761e0f..2351c1cb1e0 100644
--- a/apps/docs/content/troubleshooting/edge-function-500-error-response.mdx
+++ b/apps/docs/content/troubleshooting/edge-function-500-error-response.mdx
@@ -123,7 +123,7 @@ const some_num = 5
some_num() // TypeError: some_num is not a function
```
-This issue often appears when working with returned objects from external APIs. One may assume a response has a certain shape, but if the value is actually `null` or `undefined`, using it without checking can lead to a `TypeError`.
+This issue often appears when working with returned objects from external APIs. One may assume a response has a certain shape, but if the value is `null` or `undefined`, using it without checking can lead to a `TypeError`.
```js
const data = await req.json() // returns undefined if request body is empty
@@ -277,7 +277,7 @@ if (req.method === 'OPTIONS') {
}
```
-So, when encountering these errors, it is still important to check the logs or run the request outside the browser to make sure it is actually the primary factor and not a side-effect of a larger issue.
+So, when encountering these errors, it is still important to check the logs or run the request outside the browser to make sure it is the primary factor and not a side-effect of a larger issue.
## Still stuck?
diff --git a/apps/docs/content/troubleshooting/edge-function-546-error-response.mdx b/apps/docs/content/troubleshooting/edge-function-546-error-response.mdx
index cc869fa405a..9f4b12e25d0 100644
--- a/apps/docs/content/troubleshooting/edge-function-546-error-response.mdx
+++ b/apps/docs/content/troubleshooting/edge-function-546-error-response.mdx
@@ -252,7 +252,7 @@ If you believe a portion of your function is overly aggressive, try testing loca
Common culprits:
-**CPU intensive recursions**: intensive loops or recursion can quickly exhaust CPU
+**CPU intensive recursions**: intensive loops or recursion can exhaust CPU
```js
// This will exhaust CPU allocation when called repeatedly
@@ -288,7 +288,7 @@ If you are performing logic to process data from Supabase Postgres, you may be a
### 4. Offload operations to an external API:
-Instead of managing all operations within the function itself, there may be an external API that can execute CPU or memory intensive jobs on its behalf. One [example](/docs/guides/functions/examples/screenshots) would be using an external API for orchestrating a headless browser and then just using the edge function to manage the output of the activity instead of everything all in place.
+Instead of managing all operations within the function itself, there may be an external API that can execute CPU or memory intensive jobs on its behalf. One [example](/docs/guides/functions/examples/screenshots) would be using an external API for orchestrating a headless browser and then using the edge function to manage the output of the activity instead of everything all in place.
### 5. Split operations into individual functions:
@@ -312,7 +312,7 @@ Performing edits against images or other large files can be both CPU and Memory
### AI embedding generation and inference
-AI models process data into embeddings (large arrays), that they can more understand. Edge Functions are capable of managing [some small models directly](/blog/ai-inference-now-available-in-supabase-edge-functions); however, some require more processing power than what the edge function can support directly. In these cases, the solution is to manage the embeddings via an external source, such as OpenAI, Anthropic, etc. and to just use the edge function for light processing and coordination.
+AI models process data into embeddings (large arrays), that they can more understand. Edge Functions are capable of managing [some small models directly](/blog/ai-inference-now-available-in-supabase-edge-functions); however, some require more processing power than what the edge function can support directly. In these cases, the solution is to manage the embeddings via an external source, such as OpenAI, Anthropic, etc. and to use the edge function for light processing and coordination.
### Web scraping
diff --git a/apps/docs/content/troubleshooting/edge-function-dependency-analysis.mdx b/apps/docs/content/troubleshooting/edge-function-dependency-analysis.mdx
index 9d1f742018b..b1b764d3d78 100644
--- a/apps/docs/content/troubleshooting/edge-function-dependency-analysis.mdx
+++ b/apps/docs/content/troubleshooting/edge-function-dependency-analysis.mdx
@@ -26,7 +26,7 @@ Review the output for:
- **Large dependencies:** Packages that contribute significantly to bundle size
- **Redundant imports:** Multiple packages providing similar functionality
- **Outdated versions:** Dependencies that can be updated to more efficient versions
-- **Unused imports:** Dependencies imported but not actually used in your code
+- **Unused imports:** Dependencies imported but not used in your code
## Optimizing NPM dependencies
@@ -39,18 +39,17 @@ Import specific submodules to minimize overhead:
```tsx
// Good: Import specific submodules
import { Sheets } from 'npm:@googleapis/sheets'
+import * as googleAuth from 'npm:google-auth-library'
import { JWT } from 'npm:google-auth-library/build/src/auth/jwtclient'
-
// Avoid: Import entire package
import * as googleapis from 'npm:googleapis'
-import * as googleAuth from 'npm:google-auth-library'
```
## Best practices
### Tree-shake aggressively
-Only import what you actually use. Avoid wildcard imports (`import *`) when possible.
+Only import what you use. Avoid wildcard imports (`import *`) when possible.
### Choose lightweight alternatives
diff --git a/apps/docs/content/troubleshooting/edge-function-shutdown-reasons-explained.mdx b/apps/docs/content/troubleshooting/edge-function-shutdown-reasons-explained.mdx
index e1900cefcfc..eca96448772 100644
--- a/apps/docs/content/troubleshooting/edge-function-shutdown-reasons-explained.mdx
+++ b/apps/docs/content/troubleshooting/edge-function-shutdown-reasons-explained.mdx
@@ -80,11 +80,11 @@ These events are surfaced through logs and observability tools, allowing you to
### EarlyDrop
-**What it means:** The runtime detected that the function has completed all its work and can be shut down early, before reaching any resource limits. This is actually the most common shutdown reason and typically indicates efficient function execution.
+**What it means:** The runtime detected that the function has completed all its work and can be shut down early, before reaching any resource limits. This is the most common shutdown reason and typically indicates efficient function execution.
**When it happens:** Your function has finished processing the request, sent the response, and has no remaining async work (pending promises, timers, or callbacks). The runtime recognizes that the worker can be safely terminated without waiting for timeouts or other limits.
-**Why this is good:** `EarlyDrop` means your function is running efficiently. It completed quickly, didn't exhaust resources, and the runtime could reclaim the worker for other requests. Most well-designed functions should end with `EarlyDrop`.
+**Why this is good:** `EarlyDrop` means your function is running efficiently. It completed without exhausting resources, and the runtime could reclaim the worker for other requests. Most well-designed functions should end with `EarlyDrop`.
**What to do:**
diff --git a/apps/docs/content/troubleshooting/error-index-row-size-exceeds-btree-version-4-maximum-for-index-LMmoeU.mdx b/apps/docs/content/troubleshooting/error-index-row-size-exceeds-btree-version-4-maximum-for-index-LMmoeU.mdx
index dc9439700af..5d9df4a6c53 100644
--- a/apps/docs/content/troubleshooting/error-index-row-size-exceeds-btree-version-4-maximum-for-index-LMmoeU.mdx
+++ b/apps/docs/content/troubleshooting/error-index-row-size-exceeds-btree-version-4-maximum-for-index-LMmoeU.mdx
@@ -62,6 +62,6 @@ select * from table_name where column_name = 'search_value';
[More on building index by expression](https://www.postgresql.org/docs/current/sql-createindex.html)
-For some datatypes other than text that allows queries by partial inclusion (i.e. that the pair key-value is includes in a JSON or for implementing tsvector phrase search) you'd just use GIST/GIN indexes that inherently have values space much narrower that the whole to be indexed.
+For some non-text datatypes that support queries by partial inclusion—such as checking whether a key-value pair exists in JSON, or implementing `tsvector` phrase search—use GiST or GIN indexes. These index types operate on a narrower value space than the full content being indexed.
[More on GIN/GiST indexes](https://www.postgresql.org/docs/15/textsearch-indexes.html)
diff --git a/apps/docs/content/troubleshooting/high-cpu-and-slow-queries-with-error-must-be-a-superuser-to-terminate-superuser-process.mdx b/apps/docs/content/troubleshooting/high-cpu-and-slow-queries-with-error-must-be-a-superuser-to-terminate-superuser-process.mdx
index b676cdf8c54..22d1be7e136 100644
--- a/apps/docs/content/troubleshooting/high-cpu-and-slow-queries-with-error-must-be-a-superuser-to-terminate-superuser-process.mdx
+++ b/apps/docs/content/troubleshooting/high-cpu-and-slow-queries-with-error-must-be-a-superuser-to-terminate-superuser-process.mdx
@@ -40,7 +40,7 @@ This situation often arises in large, high-write tables (e.g., `your_table`, whi
### **Mitigating performance impact during a critical autovacuum**
-Since the wraparound prevention autovacuum cannot be stopped, the best approach is to provide the database with sufficient resources to complete the operation as quickly and efficiently as possible.
+Since the wraparound prevention autovacuum cannot be stopped, the best approach is to provide the database with sufficient resources to complete the operation as efficiently as possible.
1. **Upgrade your Database Compute Instance:**
- **Action:** Temporarily scale up your instance's CPU (e.g., from `m6g.4xlarge` to `m6g.8xlarge` or higher).
diff --git a/apps/docs/content/troubleshooting/high-latency-with-supabase-client-z0pZzR.mdx b/apps/docs/content/troubleshooting/high-latency-with-supabase-client-z0pZzR.mdx
index 13ab6fdba1f..5f84bbb234d 100644
--- a/apps/docs/content/troubleshooting/high-latency-with-supabase-client-z0pZzR.mdx
+++ b/apps/docs/content/troubleshooting/high-latency-with-supabase-client-z0pZzR.mdx
@@ -92,8 +92,8 @@ if __name__ == "__main__":
print(f"postgres: {ref}, supabase: {sup}, ratio: {sup/ref}")
```
-3. You will see that the Supabase client takes longer to execute the same query, especially for smaller tables or queries returning just one row.
+3. You will see that the Supabase client takes longer to execute the same query, especially for smaller tables or queries returning only one row.
## Expected behavior
-The overhead from PostgREST shouldn't be higher than a few milliseconds at max. 60-70 ms is way too high. This is particular deceiving because one can run the query on the SQL Editor page and it reports the same time as the direct Postgres query, which is not what actually happens.
+The overhead from PostgREST shouldn't be higher than a few milliseconds at max. 60-70 ms is way too high. This is particular deceiving because one can run the query on the SQL Editor page and it reports the same time as the direct Postgres query, which is not what happens.
diff --git a/apps/docs/content/troubleshooting/how-postgres-chooses-which-index-to-use-_JHrf4.mdx b/apps/docs/content/troubleshooting/how-postgres-chooses-which-index-to-use-_JHrf4.mdx
index 914c5b6cc4c..ac3880bae98 100644
--- a/apps/docs/content/troubleshooting/how-postgres-chooses-which-index-to-use-_JHrf4.mdx
+++ b/apps/docs/content/troubleshooting/how-postgres-chooses-which-index-to-use-_JHrf4.mdx
@@ -77,7 +77,7 @@ In most cases, developers work with the default BTREE index. It is the most prac
An operator's functional equivalents, such as `IN`, `BETWEEN`, and `ANY`, are also valid.
-However, just because the base requirements (relevant column, filter, and operators) are present, doesn't mean that an index will be used.
+However, an index isn't guaranteed to be used, even when the base requirements (relevant column, filter, and operators) are present.
Indexes have a startup cost, so for small tables, Postgres might use a sequential scan if it believes that it will take less time. The database keeps statistics about each table that it uses to inform these choices.
@@ -141,7 +141,7 @@ select * from test1 where lower(col1) = 'value';
#### Covering indexes
-Indexes contain pointers to a specific row, but you could instruct an index to actually hold a copy of a column's value for even faster retrieval. These are known as `covering` indexes. Because maintaining a copy is storage intensive, you should avoid using it for values with large data footprints.[ FULL VIDEO ON TOPIC](https://www.youtube.com/watch?v=bBu_V8CfWgM)
+Indexes contain pointers to a specific row, but you could instruct an index to hold a copy of a column's value for even faster retrieval. These are known as `covering` indexes. Because maintaining a copy is storage intensive, you should avoid using it for values with large data footprints.[ FULL VIDEO ON TOPIC](https://www.youtube.com/watch?v=bBu_V8CfWgM)
```sql
CREATE INDEX a_b_idx ON x (a,b) INCLUDE (c);
@@ -149,7 +149,7 @@ CREATE INDEX a_b_idx ON x (a,b) INCLUDE (c);
#### Indexes on JSONB
-Although a GIN/GIST index can be used to index entire JSONB bodies, you can also target just specific Key-values with standard BTREE indexes:
+Although a GIN/GIST index can be used to index entire JSONB bodies, you can also target only specific Key-values with standard BTREE indexes:
```sql
-- Example table
diff --git a/apps/docs/content/troubleshooting/how-to-change-max-database-connections-_BQ8P5.mdx b/apps/docs/content/troubleshooting/how-to-change-max-database-connections-_BQ8P5.mdx
index e1c69e3ee29..4682d7ed2dd 100644
--- a/apps/docs/content/troubleshooting/how-to-change-max-database-connections-_BQ8P5.mdx
+++ b/apps/docs/content/troubleshooting/how-to-change-max-database-connections-_BQ8P5.mdx
@@ -71,7 +71,7 @@ This is a Grafana Chart of unhealthy memory usage:

- Yellow: represents active memory
-- Red: represents SWAP, which is disk storage that the system treats as if it were actually memory
+- Red: represents SWAP, which is disk storage that the system treats as if it were memory
- Green: it is unclaimed (the system will always leave some memory unclaimed)
- Blue: it is cached data and a buffer
diff --git a/apps/docs/content/troubleshooting/how-to-interpret-and-explore-the-postgres-logs-OuCIOj.mdx b/apps/docs/content/troubleshooting/how-to-interpret-and-explore-the-postgres-logs-OuCIOj.mdx
index 811abe5dc63..c0ece19c525 100644
--- a/apps/docs/content/troubleshooting/how-to-interpret-and-explore-the-postgres-logs-OuCIOj.mdx
+++ b/apps/docs/content/troubleshooting/how-to-interpret-and-explore-the-postgres-logs-OuCIOj.mdx
@@ -263,7 +263,7 @@ limit 100;
When recording what is accessed and by whom, logging based on database roles and objects is the most reliable way to ensure a proper trail of activity.
-You can use the [pg_audit](/docs/guides/database/extensions/pgaudit) extension to selectively log relevant queries (not just errors) by certain roles, against specific database objects.
+You can use the [pg_audit](/docs/guides/database/extensions/pgaudit) extension to selectively log relevant queries, not only errors, by certain roles, against specific database objects.
You should take care when using the extension to not log all database events, but only what is absolutely necessary. Over-logging can strain the database and create log noise that makes it difficult to filter for relevant events.
diff --git a/apps/docs/content/troubleshooting/inserting-into-sequenceserial-table-causes-duplicate-key-violates-unique-constraint-error-pi6DnC.mdx b/apps/docs/content/troubleshooting/inserting-into-sequenceserial-table-causes-duplicate-key-violates-unique-constraint-error-pi6DnC.mdx
index c09d6d28ae7..bb30ac7b402 100644
--- a/apps/docs/content/troubleshooting/inserting-into-sequenceserial-table-causes-duplicate-key-violates-unique-constraint-error-pi6DnC.mdx
+++ b/apps/docs/content/troubleshooting/inserting-into-sequenceserial-table-causes-duplicate-key-violates-unique-constraint-error-pi6DnC.mdx
@@ -28,7 +28,7 @@ SELECT nextval(pg_get_serial_sequence('