diff --git a/apps/docs/content/guides/ai/going-to-prod.mdx b/apps/docs/content/guides/ai/going-to-prod.mdx index ff7ceb25647..cf422a2c101 100644 --- a/apps/docs/content/guides/ai/going-to-prod.mdx +++ b/apps/docs/content/guides/ai/going-to-prod.mdx @@ -93,7 +93,7 @@ First, a few generic tips which you can pick and choose from: 2. Prefer `inner-product` to `L2` or `Cosine` distances if your vectors are normalized (like `text-embedding-ada-002`). If embeddings are not normalized, `Cosine` distance should give the best results with an index. 3. **Pre-warm your database.** Implement the warm-up technique before transitioning to production or running benchmarks. - Use [pg_prewarm](https://www.postgresql.org/docs/current/pgprewarm.html) to load the index into RAM `select pg_prewarm('vecs.docs_vec_idx');`. This will help to avoid cold cache issues. - - Execute 10,000 to 50,000 "warm-up" queries before each benchmark/prod. This will help to utilize cache and buffers more efficiently. + - Execute 10,000 to 50,000 "warm-up" queries before each benchmark or prod. This helps to use cache and buffers more efficiently. 4. **Establish your workload.** Fine-tune `m` and `ef_construction` or `lists` constants for the pgvector index to accelerate your queries (at the expense of a slower build times). For instance, for benchmarks with 1,000,000 OpenAI embeddings, we set `m` and `ef_construction` to 32 and 80, and it resulted in 35% higher QPS than 24 and 56 values respectively. 5. **Benchmark your own specific workloads.** Doing this during cache warm-up helps gauge the best value for the index build parameters, balancing accuracy with queries per second (QPS). diff --git a/apps/docs/content/guides/api/custom-claims-and-role-based-access-control-rbac.mdx b/apps/docs/content/guides/api/custom-claims-and-role-based-access-control-rbac.mdx index 0ab154329dc..7625cacfe7e 100644 --- a/apps/docs/content/guides/api/custom-claims-and-role-based-access-control-rbac.mdx +++ b/apps/docs/content/guides/api/custom-claims-and-role-based-access-control-rbac.mdx @@ -154,7 +154,7 @@ To learn more about Auth Hooks, see the [Auth Hooks docs](/docs/guides/auth/auth ## Accessing custom claims in RLS policies -To utilize Role-Based Access Control (RBAC) in Row Level Security (RLS) policies, create an `authorize` method that reads the user's role from their JWT and checks the role's permissions: +To use Role-Based Access Control (RBAC) in Row Level Security (RLS) policies, create an `authorize` method that reads the user's role from their JWT and checks the role's permissions: ```sql supabase/migrations/init.sql create or replace function public.authorize( diff --git a/apps/docs/content/guides/auth/auth-anonymous.mdx b/apps/docs/content/guides/auth/auth-anonymous.mdx index c8d7f823f92..8d1276750bb 100644 --- a/apps/docs/content/guides/auth/auth-anonymous.mdx +++ b/apps/docs/content/guides/auth/auth-anonymous.mdx @@ -32,7 +32,7 @@ See the [Access control section](#access-control) for more details. -The Supabase team has received reports of user metadata being cached across unique anonymous users as a result of Next.js static page rendering. For the best user experience, utilize dynamic page rendering. +The Supabase team has received reports of user metadata being cached across unique anonymous users as a result of Next.js static page rendering. For the best user experience, use dynamic page rendering. diff --git a/apps/docs/content/guides/auth/auth-web3.mdx b/apps/docs/content/guides/auth/auth-web3.mdx index 0a113aa4d63..63d00da8798 100644 --- a/apps/docs/content/guides/auth/auth-web3.mdx +++ b/apps/docs/content/guides/auth/auth-web3.mdx @@ -13,7 +13,7 @@ Supported Web3 wallets: ## How does it work? -Sign in with Web3 utilizes the [EIP 4361](https://eips.ethereum.org/EIPS/eip-4361) standard to authenticate wallet addresses off-chain. This standard is widely supported by the Ethereum and Solana ecosystems, making it the best choice for verifying wallet ownership. +Sign in with Web3 uses the [EIP 4361](https://eips.ethereum.org/EIPS/eip-4361) standard to authenticate wallet addresses off-chain. This standard is widely supported by the Ethereum and Solana ecosystems, making it the best choice for verifying wallet ownership. Authentication works by asking the Web3 wallet application to sign a predefined message with the user's wallet. This message is parsed both by the Web3 wallet application and Supabase Auth to verify its validity and purpose, before creating a user account or session. diff --git a/apps/docs/content/guides/auth/social-login/auth-google.mdx b/apps/docs/content/guides/auth/social-login/auth-google.mdx index ce6cade5649..2f0ef6d8bb1 100644 --- a/apps/docs/content/guides/auth/social-login/auth-google.mdx +++ b/apps/docs/content/guides/auth/social-login/auth-google.mdx @@ -280,7 +280,7 @@ const { data, error } = await supabase.auth.signInWithOAuth({ ### Google pre-built [#google-pre-built] -Most web apps and websites can utilize Google's [personalized sign-in buttons](https://developers.google.com/identity/gsi/web/guides/personalized-button), [One Tap](https://developers.google.com/identity/gsi/web/guides/features) or [automatic sign-in](https://developers.google.com/identity/gsi/web/guides/automatic-sign-in-sign-out) for the best user experience. +Most web apps and websites can use Google's [personalized sign-in buttons](https://developers.google.com/identity/gsi/web/guides/personalized-button), [One Tap](https://developers.google.com/identity/gsi/web/guides/features) or [automatic sign-in](https://developers.google.com/identity/gsi/web/guides/automatic-sign-in-sign-out) for the best user experience. 1. Load the Google client library in your app by including the third-party script: diff --git a/apps/docs/content/guides/auth/social-login/auth-linkedin.mdx b/apps/docs/content/guides/auth/social-login/auth-linkedin.mdx index 12f1138502f..e80d89cb7aa 100644 --- a/apps/docs/content/guides/auth/social-login/auth-linkedin.mdx +++ b/apps/docs/content/guides/auth/social-login/auth-linkedin.mdx @@ -177,7 +177,7 @@ suspend fun signOut() { ## LinkedIn Open ID Connect (OIDC) -We will be replacing the _LinkedIn_ provider with a new _LinkedIn (OIDC)_ provider to support recent changes to the LinkedIn [OAuth APIs](https://learn.microsoft.com/en-us/linkedin/shared/authentication/authorization-code-flow?context=linkedin%2Fcontext&tabs=HTTPS1). The new provider utilizes the [Open ID Connect standard](https://learn.microsoft.com/en-us/linkedin/consumer/integrations/self-serve/sign-in-with-linkedin-v2#validating-id-tokens). In view of this change, we have disabled edits on the _LinkedIn_ provider and will be removing it effective 4th January 2024. Developers with LinkedIn OAuth Applications created prior to 1st August 2023 should create a new OAuth application [via the steps outlined above](/docs/guides/auth/social-login/auth-linkedin#create-a-linkedin-oauth-app) and migrate their credentials from the _LinkedIn_ provider to the _LinkedIn (OIDC)_ provider. Alternatively, you can also head to the `Products` section and add the newly release`Sign In with LinkedIn using OpenID Connect` to your existing OAuth application. +We are replacing the _LinkedIn_ provider with a new _LinkedIn (OIDC)_ provider to support recent changes to the LinkedIn [OAuth APIs](https://learn.microsoft.com/en-us/linkedin/shared/authentication/authorization-code-flow?context=linkedin%2Fcontext&tabs=HTTPS1). The new provider uses the [Open ID Connect standard](https://learn.microsoft.com/en-us/linkedin/consumer/integrations/self-serve/sign-in-with-linkedin-v2#validating-id-tokens). In view of this change, we have disabled edits on the _LinkedIn_ provider and will be removing it effective 4th January 2024. Developers with LinkedIn OAuth Applications created prior to 1st August 2023 should create a new OAuth application [via the steps outlined above](/docs/guides/auth/social-login/auth-linkedin#create-a-linkedin-oauth-app) and migrate their credentials from the _LinkedIn_ provider to the _LinkedIn (OIDC)_ provider. Alternatively, you can also head to the `Products` section and add the newly release`Sign In with LinkedIn using OpenID Connect` to your existing OAuth application. Developers using the Supabase CLI to test their LinkedIn OAuth application should also update their `config.toml` to make use of the new provider: diff --git a/apps/docs/content/guides/database/connecting-to-postgres.mdx b/apps/docs/content/guides/database/connecting-to-postgres.mdx index b1ee6e35da7..20e48681bd6 100644 --- a/apps/docs/content/guides/database/connecting-to-postgres.mdx +++ b/apps/docs/content/guides/database/connecting-to-postgres.mdx @@ -1,7 +1,7 @@ --- title: 'Connect to your database' description: 'Connect to Postgres from your frontend, backend, or serverless environment' -subtitle: 'Supabase provides multiple methods to connect to your Postgres database, whether you’re working on the frontend, backend, or utilizing serverless functions.' +subtitle: 'Supabase provides multiple methods to connect to your Postgres database, whether you’re working on the frontend, backend, or using serverless functions.' --- ## How to connect to your Postgres databases diff --git a/apps/docs/content/guides/database/custom-postgres-config.mdx b/apps/docs/content/guides/database/custom-postgres-config.mdx index 4a2c30b7db6..51c533bf808 100644 --- a/apps/docs/content/guides/database/custom-postgres-config.mdx +++ b/apps/docs/content/guides/database/custom-postgres-config.mdx @@ -212,7 +212,7 @@ You can also pass the `--no-restart` flag to attempt a reload-only apply. If the Postgres requires several parameters to be synchronized between the Primary cluster and [Read Replicas](/docs/guides/platform/read-replicas). -By default, Supabase ensures that this propagation is executed correctly. However, if the `--no-restart` behavior is used in conjunction with parameters that cannot be reloaded without a restart, the user is responsible for ensuring that both the primaries and the read replicas get restarted in a timely manner to ensure a stable running state. Leaving the configuration updated, but not utilized (via a restart) in such a case can result in read replica failure if the primary, or a read replica, restarts in isolation (e.g. due to an out-of-memory event, or hardware failure). +By default, Supabase ensures that this propagation is executed correctly. However, if the `--no-restart` behavior is used in conjunction with parameters that cannot be reloaded without a restart, the user is responsible for ensuring that both the primaries and the read replicas get restarted in a timely manner to ensure a stable running state. Leaving the configuration updated, but not used (via a restart) in such a case can result in read replica failure if the primary, or a read replica, restarts in isolation (e.g. due to an out-of-memory event, or hardware failure). diff --git a/apps/docs/content/guides/database/extensions/postgis.mdx b/apps/docs/content/guides/database/extensions/postgis.mdx index 61b14e05a4e..728bf7ebbf9 100644 --- a/apps/docs/content/guides/database/extensions/postgis.mdx +++ b/apps/docs/content/guides/database/extensions/postgis.mdx @@ -205,7 +205,7 @@ We will create [database functions](/docs/guides/database/functions) so that we ### Order by distance -Sorting datasets from closest to farthest, sometimes called nearest-neighbor sort, is a very common use case in Geo-queries. PostGIS can handle it with the use of the [`<->`](https://postgis.net/docs/geometry_distance_knn.html) operator. `<->` operator returns the two-dimensional distance between two geometries and will utilize the spatial index when used within `order by` clause. You can create the following database function to sort the restaurants from closest to farthest by passing the current locations as parameters. +Sorting datasets from closest to farthest, sometimes called nearest-neighbor sort, is a very common use case in Geo-queries. PostGIS can handle it with the use of the [`<->`](https://postgis.net/docs/geometry_distance_knn.html) operator. `<->` operator returns the two-dimensional distance between two geometries and uses the spatial index when used within `order by` clause. You can create the following database function to sort the restaurants from closest to farthest by passing the current locations as parameters. ```sql create or replace function nearby_restaurants(lat float, long float) @@ -344,7 +344,7 @@ as $$ $$; ``` -The [`&&`](https://postgis.net/docs/geometry_overlaps.html) operator used in the `where` statement here returns a boolean of whether the bounding box of the two geometries intersect or not. We are basically creating a bounding box from the two points and finding those points that fall under the bounding box. We are also utilizing a few different PostGIS functions: +The [`&&`](https://postgis.net/docs/geometry_overlaps.html) operator used in the `where` statement here returns a boolean of whether the bounding box of the two geometries intersect or not. It creates a bounding box from the two points and finds those points that fall under the bounding box. It also uses a few PostGIS functions: - [ST_MakeBox2D](https://postgis.net/docs/ST_MakeBox2D.html): Creates a 2-dimensional box from two points. - [ST_SetSRID](https://postgis.net/docs/ST_SetSRID.html): Sets the [SRID](https://postgis.net/docs/manual-dev/using_postgis_dbmanagement.html#spatial_ref_sys), which is an identifier of what coordinate system to use for the geometry. 4326 is the standard longitude and latitude coordinate system. diff --git a/apps/docs/content/guides/database/inspect.mdx b/apps/docs/content/guides/database/inspect.mdx index cce91f7b3b5..965e83912a2 100644 --- a/apps/docs/content/guides/database/inspect.mdx +++ b/apps/docs/content/guides/database/inspect.mdx @@ -10,7 +10,7 @@ Database performance is a large topic and many factors can contribute. Some of t - A lack of indexes causing slower than required queries over large tables - Unused indexes causing slow `INSERT`, `UPDATE` and `DELETE` operations - Not enough compute resources, such as memory, causing your database to go to disk for results too often -- Lock contention from multiple queries operating on highly utilized tables +- Lock contention from multiple queries operating on heavily used tables - Large amount of bloat on your tables causing poor query planning You can examine your database and queries for these issues using either the [Supabase CLI](/docs/guides/local-development/cli/getting-started) or SQL. diff --git a/apps/docs/content/guides/functions/examples/push-notifications.mdx b/apps/docs/content/guides/functions/examples/push-notifications.mdx index b346ebe70b7..dc9b26e33d3 100644 --- a/apps/docs/content/guides/functions/examples/push-notifications.mdx +++ b/apps/docs/content/guides/functions/examples/push-notifications.mdx @@ -27,7 +27,7 @@ Push notifications are an important part of any mobile app. They allow you to se ## Expo setup - To utilize Expo's push notification service, you must configure your app by installing a set of libraries, implementing functions to handle notifications, and setting up credentials for Android and iOS. Follow the official [Expo Push Notifications Setup Guide](https://docs.expo.dev/push-notifications/push-notifications-setup/) to get the credentials for Android and iOS. This project uses [Expo's EAS build](https://docs.expo.dev/build/introduction/) service to simplify this part. + To use Expo's push notification service, you must configure your app by installing a set of libraries, implementing functions to handle notifications, and setting up credentials for Android and iOS. Follow the official [Expo Push Notifications Setup Guide](https://docs.expo.dev/push-notifications/push-notifications-setup/) to get the credentials for Android and iOS. This project uses [Expo's EAS build](https://docs.expo.dev/build/introduction/) service to simplify this part. 1. Install the dependencies: `npm i` 1. Create a [new Expo project](https://expo.dev/accounts/_/projects) diff --git a/apps/docs/content/guides/functions/examples/semantic-search.mdx b/apps/docs/content/guides/functions/examples/semantic-search.mdx index 47548c35d7d..78d803f4b1d 100644 --- a/apps/docs/content/guides/functions/examples/semantic-search.mdx +++ b/apps/docs/content/guides/functions/examples/semantic-search.mdx @@ -69,7 +69,7 @@ export default { ## Create a Database Function and RPC -With the embeddings now stored in your Postgres database table, you can query them from Supabase Edge Functions by utilizing [Remote Procedure Calls (RPC)](/docs/guides/database/functions?language=js). +With the embeddings now stored in your Postgres database table, you can query them from Supabase Edge Functions by using [Remote Procedure Calls (RPC)](/docs/guides/database/functions?language=js). Given the [following Postgres Function](https://github.com/supabase/supabase/blob/master/examples/ai/edge-functions/supabase/migrations/20240410031515_vector-search.sql): diff --git a/apps/docs/content/guides/functions/unit-test.mdx b/apps/docs/content/guides/functions/unit-test.mdx index d33046713d2..98af634535f 100644 --- a/apps/docs/content/guides/functions/unit-test.mdx +++ b/apps/docs/content/guides/functions/unit-test.mdx @@ -123,7 +123,7 @@ Make sure to replace the placeholders (`supabaseUrl`, `supabaseKey`, `my_table`) ## Running Edge Functions locally -To locally test and debug Edge Functions, you can utilize the Supabase CLI. Let's explore how to run Edge Functions locally using the Supabase CLI: +To locally test and debug Edge Functions, you can use the Supabase CLI. Let's explore how to run Edge Functions locally using the Supabase CLI: 1. Ensure that the Supabase server is running by executing the following command: diff --git a/apps/docs/content/guides/platform/billing-faq.mdx b/apps/docs/content/guides/platform/billing-faq.mdx index 24d8cd58770..032103c704c 100644 --- a/apps/docs/content/guides/platform/billing-faq.mdx +++ b/apps/docs/content/guides/platform/billing-faq.mdx @@ -66,7 +66,7 @@ Read more about [Compute usage](/docs/guides/platform/manage-your-usage/compute) #### What is egress and how is it billed? -Egress refers to the total bandwidth (network traffic) quota available to each organization. This quota can be utilized for various purposes such as Storage, Realtime, Auth, Functions, Supavisor, Log Drains and Database. Each plan includes a specific egress quota, and any additional usage beyond that quota is billed accordingly. +Egress refers to the total bandwidth (network traffic) quota available to each organization. This quota can be used for various purposes such as Storage, Realtime, Auth, Functions, Supavisor, Log Drains and Database. Each plan includes a specific egress quota, and any additional usage beyond that quota is billed accordingly. We differentiate between cached (served via our CDN from cache hits) and uncached egress and give quotas for each type and have varying pricing (cached egress is cheaper). Cached egress only applies to Storage. diff --git a/apps/docs/content/guides/platform/performance.mdx b/apps/docs/content/guides/platform/performance.mdx index 1bc78848a4c..0c75a8d30fb 100644 --- a/apps/docs/content/guides/platform/performance.mdx +++ b/apps/docs/content/guides/platform/performance.mdx @@ -4,7 +4,7 @@ title: 'Performance Tuning' description: 'Getting the best results out of your Supabase project' --- -The Supabase platform automatically optimizes your Postgres database to take advantage of the compute resources of the plan your project is on. However, these optimizations are based on assumptions about the type of workflow the project is being utilized for, and it is likely that better results can be obtained by tuning the database for your particular workflow. +The Supabase platform automatically optimizes your Postgres database to take advantage of the compute resources of the plan your project is on. However, these optimizations are based on assumptions about the type of workflow the project is being used for, and it is likely that better results can be obtained by tuning the database for your particular workflow. ## Examining query performance diff --git a/apps/docs/content/guides/platform/read-replicas/getting-started.mdx b/apps/docs/content/guides/platform/read-replicas/getting-started.mdx index c4f768b47d5..085cdb2e218 100644 --- a/apps/docs/content/guides/platform/read-replicas/getting-started.mdx +++ b/apps/docs/content/guides/platform/read-replicas/getting-started.mdx @@ -100,7 +100,7 @@ We combine it with streaming replication to reduce replication lag. Once WAL-G f ### Restart or compute add-on change behaviour -When you restart a project that utilizes Read Replicas, or change the compute add-on size, the Primary database gets restarted first. During this period, the Read Replicas remain available. +When you restart a project that uses Read Replicas, or change the compute add-on size, the Primary database gets restarted first. During this period, the Read Replicas remain available. Once the Primary database has completed restarting (or resizing, in case of a compute add-on change) and become available for usage, all the Read Replicas are restarted (and resized, if needed) concurrently. @@ -138,7 +138,7 @@ If you are already ingesting your [project's metrics](/docs/guides/telemetry/met Some common sources of high replication lag include: 1. **Exclusive locks on tables on the Primary**: Operations such as `drop table` and `reindex` take an access-exclusive lock on the table. This can result in increasing replication lag for the duration of the lock. -2. **Resource Constraints on the database**: Heavy utilization on the primary or the replica, if run on an under-resourced project, can result in high replication lag. This includes the characteristics of the disk being utilized (IOPS, Throughput). +2. **Resource Constraints on the database**: Heavy utilization on the primary or the replica, if run on an under-resourced project, can result in high replication lag. This includes the characteristics of the disk being used (IOPS, Throughput). 3. **Long-running transactions on the Primary**: Transactions that run for a long-time on the primary can also result in high replication lag. You can use the `pg_stat_activity` view to identify and terminate such transactions if needed. `pg_stat_activity` is a live view, and does not offer historical data on transactions that might have been active for a long time in the past. High replication lag can result in stale data returned for queries executed against the affected read replicas. diff --git a/apps/docs/content/guides/realtime/architecture.mdx b/apps/docs/content/guides/realtime/architecture.mdx index dab8ff0f051..cbf6b59737f 100644 --- a/apps/docs/content/guides/realtime/architecture.mdx +++ b/apps/docs/content/guides/realtime/architecture.mdx @@ -7,7 +7,7 @@ sidebar_label: 'Architecture' Realtime is a globally distributed Elixir cluster. Clients can connect to any node in the cluster via WebSockets and send messages to any other client connected to the cluster. -Realtime is written in [Elixir](https://elixir-lang.org/), which compiles to [Erlang](https://www.erlang.org/), and utilizes many tools the [Phoenix Framework](https://www.phoenixframework.org/) provides out of the box. +Realtime is written in [Elixir](https://elixir-lang.org/), which compiles to [Erlang](https://www.erlang.org/), and uses many tools the [Phoenix Framework](https://www.phoenixframework.org/) provides out of the box. Architecture - When an asynchronous method needs to be used within a synchronous context, such as the callback for `.subscribe()`, utilize `asyncio.create_task()` to schedule the coroutine. This is why the [initialize the client](#initialize-the-client) example includes an import of `asyncio`. + When an asynchronous method needs to be used within a synchronous context, such as the callback for `.subscribe()`, use `asyncio.create_task()` to schedule the coroutine. This is why the [initialize the client](#initialize-the-client) example includes an import of `asyncio`. @@ -689,7 +689,7 @@ You can pass configuration options while initializing the Supabase Client. - When an asynchronous method needs to be used within a synchronous context, such as the callback for `.subscribe()`, utilize `asyncio.create_task()` to schedule the coroutine. This is why the [initialize the client](#initialize-the-client) example includes an import of `asyncio`. + When an asynchronous method needs to be used within a synchronous context, such as the callback for `.subscribe()`, use `asyncio.create_task()` to schedule the coroutine. This is why the [initialize the client](#initialize-the-client) example includes an import of `asyncio`. diff --git a/apps/docs/content/guides/storage/security/access-control.mdx b/apps/docs/content/guides/storage/security/access-control.mdx index 075c5a89dc3..f56c3c5ae7b 100644 --- a/apps/docs/content/guides/storage/security/access-control.mdx +++ b/apps/docs/content/guides/storage/security/access-control.mdx @@ -14,7 +14,7 @@ You can use RLS to create [Security Access Policies](https://www.postgresql.org/ By default Storage does not allow any uploads to buckets without RLS policies. You selectively allow certain operations by creating RLS policies on the `storage.objects` table. -You can find the documentation for the storage schema [here](/docs/guides/storage/schema/design) , and to simplify the process of crafting your policies, you can utilize these [helper functions](/docs/guides/storage/schema/helper-functions) . +You can find the documentation for the storage schema [here](/docs/guides/storage/schema/design) , and to simplify the process of crafting your policies, you can use these [helper functions](/docs/guides/storage/schema/helper-functions) . If you need different `SELECT` policies for different Storage actions, such as listing objects versus reading authenticated objects, use the operation-aware helpers `storage.allow_only_operation()` and `storage.allow_any_operation()` documented in [Storage Helper Functions](/docs/guides/storage/schema/helper-functions). diff --git a/apps/docs/content/guides/telemetry/advanced-log-filtering.mdx b/apps/docs/content/guides/telemetry/advanced-log-filtering.mdx index 9b591e483af..0e10827c4a1 100644 --- a/apps/docs/content/guides/telemetry/advanced-log-filtering.mdx +++ b/apps/docs/content/guides/telemetry/advanced-log-filtering.mdx @@ -21,7 +21,7 @@ The Logs Explorer uses BigQuery and supports all [available SQL functions and op ## Timestamp display and behavior -BigQuery stores each log entry with a `timestamp` as a `TIMESTAMP` data type. Use the appropriate [timestamp function](https://cloud.google.com/bigquery/docs/reference/standard-sql/timestamp_functions#timestamp) to utilize the `timestamp` field in a query. +BigQuery stores each log entry with a `timestamp` as a `TIMESTAMP` data type. Use the appropriate [timestamp function](https://cloud.google.com/bigquery/docs/reference/standard-sql/timestamp_functions#timestamp) to use the `timestamp` field in a query. BigQuery renders raw top-level timestamp values as Unix microseconds. To render the timestamps in a human-readable format, use the `DATETIME()` function to convert the Unix timestamp display into an ISO-8601 timestamp. diff --git a/apps/docs/content/guides/telemetry/logs.mdx b/apps/docs/content/guides/telemetry/logs.mdx index a915f64d18b..60fec5f516f 100644 --- a/apps/docs/content/guides/telemetry/logs.mdx +++ b/apps/docs/content/guides/telemetry/logs.mdx @@ -257,7 +257,7 @@ The Logs Explorer uses BigQuery and supports all [available SQL functions and op ### Timestamp display and behavior -Each log entry is stored with a `timestamp` as a `TIMESTAMP` data type. Use the appropriate [timestamp function](https://cloud.google.com/bigquery/docs/reference/standard-sql/timestamp_functions#timestamp) to utilize the `timestamp` field in a query. +Each log entry is stored with a `timestamp` as a `TIMESTAMP` data type. Use the appropriate [timestamp function](https://cloud.google.com/bigquery/docs/reference/standard-sql/timestamp_functions#timestamp) to use the `timestamp` field in a query. Raw top-level timestamp values are rendered as unix microsecond. To render the timestamps in a human-readable format, use the `DATETIME()` function to convert the unix timestamp display into an ISO-8601 timestamp. diff --git a/apps/docs/content/guides/telemetry/reports.mdx b/apps/docs/content/guides/telemetry/reports.mdx index 8feb421e00d..da2e2e0fbaf 100644 --- a/apps/docs/content/guides/telemetry/reports.mdx +++ b/apps/docs/content/guides/telemetry/reports.mdx @@ -491,7 +491,7 @@ The Realtime API Gateway reports focus on API requests related to Realtime funct ## Storage -The Storage report provides visibility into how your Supabase Storage is being utilized, including request patterns, performance characteristics, and caching effectiveness. +The Storage report provides visibility into how your Supabase Storage is being used, including request patterns, performance characteristics, and caching effectiveness. | Chart | Description | Key Insights | | --------------- | ------------------------------------------ | ---------------------------------------------------------------------------- | diff --git a/apps/docs/content/troubleshooting/edge-function-504-error-response.mdx b/apps/docs/content/troubleshooting/edge-function-504-error-response.mdx index 44c21da185e..86e2d5e9394 100644 --- a/apps/docs/content/troubleshooting/edge-function-504-error-response.mdx +++ b/apps/docs/content/troubleshooting/edge-function-504-error-response.mdx @@ -100,7 +100,7 @@ const [resultA, resultB] = await Promise.all([ The Edge Function may be doing more than it needs to. It may be better to split up it's logic into multiple parts that can be called individually and run for shorter periods. -#### Utilize background tasks +#### Use background tasks [utilize-background-tasks] You can initiate functions in a background task to be handled independently of the request/response handler. The process is outlined in the [Background Task docs](/docs/guides/functions/background-tasks) diff --git a/apps/docs/content/troubleshooting/edge-function-wall-clock-time-limit-reached-Nk38bW.mdx b/apps/docs/content/troubleshooting/edge-function-wall-clock-time-limit-reached-Nk38bW.mdx index ebbf45c2cc6..402453a70fc 100644 --- a/apps/docs/content/troubleshooting/edge-function-wall-clock-time-limit-reached-Nk38bW.mdx +++ b/apps/docs/content/troubleshooting/edge-function-wall-clock-time-limit-reached-Nk38bW.mdx @@ -15,7 +15,7 @@ message = "Edge Function 'wall clock time limit reached'" The message "wall clock time limit reached" typically indicates that a process has reached the maximum time allowed for execution. This time is measured by a clock, similar to a system clock or a clock on the wall. It encompasses the entire duration a process takes to complete, including any periods of inactivity or waiting. -When this message appears in the context of your edge function, it means that the function has emitted a Shutdown event either after reaching the specified wall clock duration or when it hits a resource limit such as CPU time used or memory utilized. +When this message appears in the context of your edge function, it means that the function has emitted a Shutdown event either after reaching the specified wall clock duration or when it hits a resource limit such as CPU time used or memory used. **Current Limits Explained** diff --git a/apps/docs/content/troubleshooting/exhaust-swap.mdx b/apps/docs/content/troubleshooting/exhaust-swap.mdx index c137d293a86..7a730f17b42 100644 --- a/apps/docs/content/troubleshooting/exhaust-swap.mdx +++ b/apps/docs/content/troubleshooting/exhaust-swap.mdx @@ -17,7 +17,7 @@ High Swap is usually not a problem unless other resources (such as RAM) are cons Every Supabase project runs on its own dedicated virtual machine. The machine's underlying specs and hardware depend on your [compute add-on](/docs/guides/platform/compute-add-ons). If your hardware isn't suitable for your workload, you might experience high Swap usage. -Swap is a portion of your instance's disk that is reserved for the operating system to use when the available RAM has been utilized. As it uses the disk, Swap is slower to access and is generally used as a last resort. +Swap is a portion of your instance's disk that is reserved for the operating system to use when the available RAM is used. As it uses the disk, Swap is slower to access and is generally used as a last resort. Swap can be used even if your instance has plenty of RAM. If this is the case, do not worry. Your instance might try to "preemptively swap" by swapping background processes to make space for your traffic in RAM. 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 9b2c0a21edf..18f13fae035 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 @@ -259,7 +259,7 @@ limit 100; ### Customized object and role activity logging -> ⚠️ NOTE: This is specifically designated for those using the `postgres` role or [custom roles](/docs/guides/database/postgres/roles) to interact with their database. Those utilizing the Database REST API should reference the [Database API Logging Guide](https://github.com/orgs/supabase/discussions/22849) instead. +> ⚠️ NOTE: This is specifically designated for those using the `postgres` role or [custom roles](/docs/guides/database/postgres/roles) to interact with their database. Those using the Database REST API should reference the [Database API Logging Guide](https://github.com/orgs/supabase/discussions/22849) instead. 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. diff --git a/apps/docs/content/troubleshooting/how-to-migrate-from-supabase-auth-helpers-to-ssr-package-5NRunM.mdx b/apps/docs/content/troubleshooting/how-to-migrate-from-supabase-auth-helpers-to-ssr-package-5NRunM.mdx index 6b11208a51c..d35d2376ae2 100644 --- a/apps/docs/content/troubleshooting/how-to-migrate-from-supabase-auth-helpers-to-ssr-package-5NRunM.mdx +++ b/apps/docs/content/troubleshooting/how-to-migrate-from-supabase-auth-helpers-to-ssr-package-5NRunM.mdx @@ -215,7 +215,7 @@ export async function signup(formData: FormData) { } ``` -### 5. Utilize the server actions in your login page UI +### 5. Use the server actions in your login page UI ``` // app/login/page.tsx diff --git a/apps/docs/content/troubleshooting/increase-vector-lookup-speeds-by-applying-an-hsnw-index-ohLHUM.mdx b/apps/docs/content/troubleshooting/increase-vector-lookup-speeds-by-applying-an-hsnw-index-ohLHUM.mdx index 6c5e0f6365b..8138030cd14 100644 --- a/apps/docs/content/troubleshooting/increase-vector-lookup-speeds-by-applying-an-hsnw-index-ohLHUM.mdx +++ b/apps/docs/content/troubleshooting/increase-vector-lookup-speeds-by-applying-an-hsnw-index-ohLHUM.mdx @@ -26,7 +26,7 @@ operator | description | search type `<#>` | negative inner product | vector_ip_ops `<=>` | cosine distance | vector_cosine_ops -Queries can only utilize the index if it matches the search type used. If you are unsure which search type to prioritize, vector_cosine_ops is the most commonly used. You can checkout our [guide](/docs/guides/ai/vector-indexes/hnsw-indexes) for more info. The folks at Crunchy Data also wrote an [explainer](https://www.crunchydata.com/blog/hnsw-indexes-with-postgres-and-pgvector) that you may find useful. +Queries can only use the index if it matches the search type used. If you are unsure which search type to prioritize, vector_cosine_ops is the most commonly used. You can checkout our [guide](/docs/guides/ai/vector-indexes/hnsw-indexes) for more info. The folks at Crunchy Data also wrote an [explainer](https://www.crunchydata.com/blog/hnsw-indexes-with-postgres-and-pgvector) that you may find useful. Applying an index can be slow and computationally expensive, so there are a few preparations that should be made beforehand: diff --git a/apps/docs/content/troubleshooting/interpreting-supabase-grafana-cpu-charts-9JSlkC.mdx b/apps/docs/content/troubleshooting/interpreting-supabase-grafana-cpu-charts-9JSlkC.mdx index 7f6e7c5442c..7d49046e4a0 100644 --- a/apps/docs/content/troubleshooting/interpreting-supabase-grafana-cpu-charts-9JSlkC.mdx +++ b/apps/docs/content/troubleshooting/interpreting-supabase-grafana-cpu-charts-9JSlkC.mdx @@ -18,7 +18,7 @@ Here are examples of unhealthy CPU utilization: The CPU chart shows 4 distinct metrics of interest: -- **Yellow**: It represents CPU utilized in [kernel space](https://en.wikipedia.org/wiki/User_space_and_kernel_space) (privileged OS operations). If this is high, it may be a sign that your app is connecting/disconnecting too aggressively. It could also be symptomatic of extension-related errors. +- **Yellow**: It represents CPU used in [kernel space](https://en.wikipedia.org/wiki/User_space_and_kernel_space) (privileged OS operations). If this is high, it may be a sign that your app is connecting/disconnecting too aggressively. It could also be symptomatic of extension-related errors. - **Blue**: It represents requests in user space and mainly reflects the CPU usage from regular queries. For optimization tips, check out the links at the end of the page. - **Red**: It represents cycles the CPU spent idle because it was waiting on IO tasks. Any amount of red often implies [disk](https://github.com/orgs/supabase/discussions/27003) or, indirectly, [memory](https://github.com/orgs/supabase/discussions/27021) problems. The links outline how to address this type of issue. - **Green**: These are CPU cycles spent idle. diff --git a/apps/docs/content/troubleshooting/manually-created-databases-are-not-visible-in-the-supabase-dashboard-4415aa.mdx b/apps/docs/content/troubleshooting/manually-created-databases-are-not-visible-in-the-supabase-dashboard-4415aa.mdx index 079069d919d..87e25287dca 100644 --- a/apps/docs/content/troubleshooting/manually-created-databases-are-not-visible-in-the-supabase-dashboard-4415aa.mdx +++ b/apps/docs/content/troubleshooting/manually-created-databases-are-not-visible-in-the-supabase-dashboard-4415aa.mdx @@ -40,7 +40,7 @@ The core of this behavior stems from the distinction between how Postgres manage ## Resolution and best practices -To effectively utilize Supabase and its features, consider the following approaches: +To effectively use Supabase and its features, consider the following approaches: - **For Supabase Feature Integration:** If you intend for your data to be managed via the Supabase Dashboard, accessed through auto-generated APIs (PostgREST), or integrated with Supabase's Authentication or Storage services, all your data and schemas **must reside within the project's default `postgres` database**. This is the designated database for full Supabase ecosystem compatibility. diff --git a/apps/docs/content/troubleshooting/oauth-sign-in-isnt-redirecting-on-the-server-side-ShGMtr.mdx b/apps/docs/content/troubleshooting/oauth-sign-in-isnt-redirecting-on-the-server-side-ShGMtr.mdx index 1e4f93e8f5e..9c53a61735a 100644 --- a/apps/docs/content/troubleshooting/oauth-sign-in-isnt-redirecting-on-the-server-side-ShGMtr.mdx +++ b/apps/docs/content/troubleshooting/oauth-sign-in-isnt-redirecting-on-the-server-side-ShGMtr.mdx @@ -7,7 +7,7 @@ keywords = [ "oauth", "redirects", "server-side" ] database_id = "3e9246cb-d592-4051-93c8-53e4e555711c" --- -The reason behind this limitation is that the auth helpers library lacks a direct mechanism for performing server-side redirects, as each framework handles redirects differently. However, the library does offer a URL through the data property it returns, which should be utilized for the purpose of redirection. +The reason behind this limitation is that the auth helpers library lacks a direct mechanism for performing server-side redirects, as each framework handles redirects differently. However, the library does offer a URL through the data property it returns, which should be used for the purpose of redirection. **Next.js:** diff --git a/apps/docs/content/troubleshooting/performing-administration-tasks-on-the-server-side-with-the-servicerole-secret-BYM4Fa.mdx b/apps/docs/content/troubleshooting/performing-administration-tasks-on-the-server-side-with-the-servicerole-secret-BYM4Fa.mdx index 2452c3defb3..8e80632b281 100644 --- a/apps/docs/content/troubleshooting/performing-administration-tasks-on-the-server-side-with-the-servicerole-secret-BYM4Fa.mdx +++ b/apps/docs/content/troubleshooting/performing-administration-tasks-on-the-server-side-with-the-servicerole-secret-BYM4Fa.mdx @@ -9,9 +9,9 @@ database_id = "0d3389c0-5e75-473c-a18b-0699d0911fb2" By default, server side rendering (SSR) does not permit the use of a `secret` key. This restriction is in place to prevent the accidental exposure of your `secret` key to the public. Since SSR runs on both the server and client side, it becomes challenging to separate the key specifically for client-side usage. -However, there is a solution. You can create a separate Supabase client using the `createClient` method from `@supabase/supabase-js` and provide it with the `secret` key. In a server environment, you will also need to disable certain properties to ensure proper functionality. See the example code below for the required settings. +However, there is a solution. You can create a separate Supabase client using the `createClient` method from `@supabase/supabase-js` and provide it with the `secret` key. In a server environment, you also need to disable certain properties to ensure proper functionality. See the example code below for the required settings. -By implementing this approach, you can safely utilize the `secret` key without compromising security or exposing sensitive information to the public. +By implementing this approach, you can safely use the `secret` key without compromising security or exposing sensitive information to the public. ```ts import { createClient } from '@supabase/supabase-js' diff --git a/apps/docs/content/troubleshooting/supavisor-faq-YyP5tI.mdx b/apps/docs/content/troubleshooting/supavisor-faq-YyP5tI.mdx index f75c004363a..7234ad53a91 100644 --- a/apps/docs/content/troubleshooting/supavisor-faq-YyP5tI.mdx +++ b/apps/docs/content/troubleshooting/supavisor-faq-YyP5tI.mdx @@ -66,7 +66,7 @@ postgresql://postgres.ajrbwkcuthywfddihrmflo:[YOUR-PASSWORD]@aws-0-us-east-1.poo ### Supavisor: Transaction mode vs. Session mode? -When a client forms a direct connection with Postgres, it usually will make a few queries, but may not utilize the connection the entire time. In transaction mode, a client is allowed to make a single query before being sent back to the figurative "waiting room". This prevents greedy or sedentary clients from hoarding connections. In most cases, this increases query throughput and is optimal. +When a client forms a direct connection with Postgres, it usually makes a few queries but may not use the connection the entire time. In transaction mode, a client is allowed to make a single query before being sent back to the figurative "waiting room". This prevents greedy or sedentary clients from hoarding connections. In most cases, this increases query throughput and is optimal. In session mode, once the pooler assigns a direct connection, it stays with that client until voluntarily surrendered. diff --git a/apps/docs/content/troubleshooting/troubleshooting-connect_timeout-or-hanging-queries-in-vercel-serverless-functions-775f92.mdx b/apps/docs/content/troubleshooting/troubleshooting-connect_timeout-or-hanging-queries-in-vercel-serverless-functions-775f92.mdx index 3477600da21..c12305bf573 100644 --- a/apps/docs/content/troubleshooting/troubleshooting-connect_timeout-or-hanging-queries-in-vercel-serverless-functions-775f92.mdx +++ b/apps/docs/content/troubleshooting/troubleshooting-connect_timeout-or-hanging-queries-in-vercel-serverless-functions-775f92.mdx @@ -15,7 +15,7 @@ Serverless environments may freeze the function between requests. This causes TC **How to Resolve This:** -- **Use the Data API:** Migrate read-heavy workloads to the Supabase Data API (PostgREST). This utilizes stateless HTTP requests and avoids persistent TCP socket issues. +- **Use the Data API:** Migrate read-heavy workloads to the Supabase Data API (PostgREST). This uses stateless HTTP requests and avoids persistent TCP socket issues. - **Liveness Preflight:** For transactional paths using `postgres-js`, implement a preflight check by racing a `SELECT 1` query against a short timeout (e.g., a few seconds) before executing the primary query. If the preflight times out, recycle the database client. - **Migrate to Vercel Fluid Compute:** Use Vercel's Fluid Compute with `attachDatabasePool`. This environment supports the `waitUntil` hook, which allows the runtime to close idle connections properly before the instance suspends. - **Application Retries:** Implement application-level retry logic specifically for connection timeout errors to force a new connection attempt.