diff --git a/README.md b/README.md index 70298a09e54..491a08b1009 100644 --- a/README.md +++ b/README.md @@ -67,7 +67,7 @@ You can also [self-host](https://supabase.com/docs/guides/hosting/overview) and - [pg_graphql](http://github.com/supabase/pg_graphql/) a PostgreSQL extension that exposes a GraphQL API - [Storage](https://github.com/supabase/storage-api) provides a RESTful interface for managing Files stored in S3, using Postgres to manage permissions. - [postgres-meta](https://github.com/supabase/postgres-meta) is a RESTful API for managing your Postgres, allowing you to fetch tables, add roles, and run queries, etc. -- [GoTrue](https://github.com/supabase/gotrue) is an JWT based API for managing users and issuing JWT tokens. +- [GoTrue](https://github.com/supabase/gotrue) is a JWT based API for managing users and issuing JWT tokens. - [Kong](https://github.com/Kong/kong) is a cloud-native API gateway. #### Client libraries diff --git a/apps/docs/components/Extensions.tsx b/apps/docs/components/Extensions.tsx index b49c5ad83d3..8740be67870 100644 --- a/apps/docs/components/Extensions.tsx +++ b/apps/docs/components/Extensions.tsx @@ -1,7 +1,7 @@ import Link from 'next/link' import React, { useState } from 'react' -import { GlassPanel, IconLink, IconX, Input } from 'ui' -import extensions from '../data/extensions.json' +import { extensions } from 'shared-data' +import { GlassPanel, IconX, Input } from 'ui' type Extension = { name: string diff --git a/apps/docs/components/Navigation/NavigationMenu/NavigationMenu.constants.ts b/apps/docs/components/Navigation/NavigationMenu/NavigationMenu.constants.ts index 81f0c44369e..9498cbe2ac4 100644 --- a/apps/docs/components/Navigation/NavigationMenu/NavigationMenu.constants.ts +++ b/apps/docs/components/Navigation/NavigationMenu/NavigationMenu.constants.ts @@ -449,6 +449,10 @@ export const auth = { name: 'Overview', url: '/guides/auth', }, + { + name: 'Redirect URLs', + url: '/guides/auth/concepts/redirect-urls', + }, { name: 'Quickstarts', items: [ @@ -937,7 +941,18 @@ export const storage: NavMenuConstant = { ], } -export const ai: NavMenuConstant = { +export const vectorIndexItems = [ + { + name: 'HNSW indexes', + url: '/guides/ai/vector-indexes/hnsw-indexes', + }, + { + name: 'IVFFlat indexes', + url: '/guides/ai/vector-indexes/ivf-indexes', + }, +] + +export const ai = { icon: 'ai', title: 'AI & Vectors', url: '/guides/ai', @@ -977,8 +992,8 @@ export const ai: NavMenuConstant = { url: undefined, items: [ { name: 'Managing collections', url: '/guides/ai/managing-collections' }, - { name: 'Managing indexes', url: '/guides/ai/managing-indexes' }, { name: 'Vector columns', url: '/guides/ai/vector-columns' }, + { name: 'Vector indexes', url: '/guides/ai/vector-indexes', items: vectorIndexItems }, { name: 'Engineering for scale', url: '/guides/ai/engineering-for-scale' }, { name: 'Choosing Compute Add-on', url: '/guides/ai/choosing-compute-addon' }, { name: 'Going to Production', url: '/guides/ai/going-to-prod' }, diff --git a/apps/docs/layouts/SiteLayout.tsx b/apps/docs/layouts/SiteLayout.tsx index 94cd0ae0631..1b0f0a75df1 100644 --- a/apps/docs/layouts/SiteLayout.tsx +++ b/apps/docs/layouts/SiteLayout.tsx @@ -244,7 +244,7 @@ const Container = memo(function Container(props) { className={[ // 'overflow-x-auto', 'w-full h-screen transition-all ease-out', - 'absolute lg:relative', + // 'absolute lg:relative', mobileMenuOpen ? '!w-auto ml-[75%] sm:ml-[50%] md:ml-[33%] overflow-hidden' : 'overflow-auto', diff --git a/apps/docs/pages/guides/ai/engineering-for-scale.mdx b/apps/docs/pages/guides/ai/engineering-for-scale.mdx index 871d0a5059c..0c4fff2fb26 100644 --- a/apps/docs/pages/guides/ai/engineering-for-scale.mdx +++ b/apps/docs/pages/guides/ai/engineering-for-scale.mdx @@ -53,7 +53,7 @@ const { data, error } = await supabase ## Enterprise workloads -As you move into production, we recommend running splitting your collections into separate projects. This is because it allows your vector stores to scale independently of your production data. Vectors typically grow faster than operational data, and they have different resource requirements. Running them on separate databases removes the single-point-of-failure. +As you move into production, we recommend splitting your collections into separate projects. This is because it allows your vector stores to scale independently of your production data. Vectors typically grow faster than operational data, and they have different resource requirements. Running them on separate databases removes the single-point-of-failure.
-For an in-depth guide on vector indexes, see [Managing indexes](/docs/guides/ai/managing-indexes). +For an in-depth guide on vector indexes, see [Vector indexes](/docs/guides/ai/vector-indexes). ### Query diff --git a/apps/docs/pages/guides/ai/vector-columns.mdx b/apps/docs/pages/guides/ai/vector-columns.mdx index b263cb9b619..4cfa8259708 100644 --- a/apps/docs/pages/guides/ai/vector-columns.mdx +++ b/apps/docs/pages/guides/ai/vector-columns.mdx @@ -162,7 +162,7 @@ Vectors and embeddings can be used for much more than search. Learn more about e ### Indexes -Once your vector table starts to grow, you will likely want to add an index to speed up queries. See [Managing indexes](/docs/guides/ai/managing-indexes) to learn how vector indexes work and how to create them. +Once your vector table starts to grow, you will likely want to add an index to speed up queries. See [Vector indexes](/docs/guides/ai/vector-indexes) to learn how vector indexes work and how to create them. export const Page = ({ children }) => diff --git a/apps/docs/pages/guides/ai/vector-indexes.mdx b/apps/docs/pages/guides/ai/vector-indexes.mdx new file mode 100644 index 00000000000..041e33a02cb --- /dev/null +++ b/apps/docs/pages/guides/ai/vector-indexes.mdx @@ -0,0 +1,41 @@ +import Layout from '~/layouts/DefaultGuideLayout' + +export const meta = { + id: 'ai-vector-indexes', + title: 'Vector indexes', + description: 'Understanding vector indexes', + sidebar_label: 'Vector indexes', +} + +Once your vector table starts to grow, you will likely want to add an index to speed up queries. Without indexes, you'll be performing a sequential scan which can be a resource-intensive operation when you have many records. + +## Choosing an index + +Today `pgvector` supports two types of indexes: + +- [HNSW](/docs/guides/ai/vector-indexes/hnsw-indexes) +- [IVFFlat](/docs/guides/ai/vector-indexes/ivf-indexes) + +In general we recommend using [HNSW](/docs/guides/ai/vector-indexes/hnsw-indexes) because of its [performance](https://supabase.com/blog/increase-performance-pgvector-hnsw#hnsw-performance-1536-dimensions) and [robustness against changing data](/docs/guides/ai/vector-indexes/hnsw-indexes#when-should-you-create-hnsw-indexes). + +## Distance operators + +Indexes can be used to improve performance of nearest neighbor search using various distance measures. `pgvector` includes 3 distance operators: + +| Operator | Description | [**Operator class**](https://www.postgresql.org/docs/current/sql-createopclass.html) | +| -------- | ---------------------- | ------------------------------------------------------------------------------------ | +| `<->` | Euclidean distance | `vector_l2_ops` | +| `<#>` | negative inner product | `vector_ip_ops` | +| `<=>` | cosine distance | `vector_cosine_ops` | + +Currently vectors with up to 2,000 dimensions can be indexed. + +If you are using the `vecs` Python library, follow the instructions in [Managing collections](/docs/guides/ai/managing-collections#create-an-index) to create indexes. + +## Resources + +Read more about indexing on `pgvector`'s [GitHub page](https://github.com/pgvector/pgvector#indexing). + +export const Page = ({ children }) => + +export default Page diff --git a/apps/docs/pages/guides/ai/vector-indexes/hnsw-indexes.mdx b/apps/docs/pages/guides/ai/vector-indexes/hnsw-indexes.mdx new file mode 100644 index 00000000000..23bcadcc661 --- /dev/null +++ b/apps/docs/pages/guides/ai/vector-indexes/hnsw-indexes.mdx @@ -0,0 +1,103 @@ +import Layout from '~/layouts/DefaultGuideLayout' + +export const meta = { + id: 'ai-hnsw-indexes', + title: 'HNSW indexes', + description: 'Understanding HNSW indexes in pgvector', + sidebar_label: 'HNSW indexes', +} + +HNSW is an algorithm for approximate nearest neighbor search. It is a frequently used index type that can improve performance when querying highly-dimensional vectors, like those representing embeddings. + +## Usage + +The way you create an HNSW index depends on the distance operator you are using. `pgvector` includes 3 distance operators: + +| Operator | Description | [**Operator class**](https://www.postgresql.org/docs/current/sql-createopclass.html) | +| -------- | ---------------------- | ------------------------------------------------------------------------------------ | +| `<->` | Euclidean distance | `vector_l2_ops` | +| `<#>` | negative inner product | `vector_ip_ops` | +| `<=>` | cosine distance | `vector_cosine_ops` | + +Use the following SQL commands to create an HNSW index for the operator(s) used in your queries. + +### Euclidean L2 distance (`vector_l2_ops`) + +```sql +create index on items using hnsw (column_name vector_l2_ops); +``` + +### Inner product (`vector_ip_ops`) + +```sql +create index on items using hnsw (column_name vector_ip_ops); +``` + +### Cosine distance (`vector_cosine_ops`) + +```sql +create index on items using hnsw (column_name vector_cosine_ops); +``` + +Currently vectors with up to 2,000 dimensions can be indexed. + +If you are using the `vecs` Python library, follow the instructions in [Managing collections](/docs/guides/ai/managing-collections#create-an-index) to create indexes. + +## How does HNSW work? + +HNSW uses proximity graphs (graphs connecting nodes based on distance between them) to approximate nearest-neighbor search. To understand HNSW, we can break it down into 2 parts: + +- **Hierarchical (H):** The algorithm operates over multiple layers +- **Navigable Small World (NSW):** Each vector is a node within a graph and is connected to several other nodes + +### Hierarchical + +The hierarchical aspect of HNSW builds off of the idea of skip lists. + +Skip lists are multi-layer linked lists. The bottom layer is a regular linked list connecting an ordered sequence of elements. Each new layer above removes some elements from the underlying layer (based on a fixed probability), producing a sparser subsequence that “skips” over elements. + +
+ visual of an example skip list (light) + visual of an example skip list (dark) +
+ +When searching for an element, the algorithm begins at the top layer and traverses its linked list horizontally. If the target element is found, the algorithm stops and returns it. Otherwise if the next element in the list is greater than the target (or `NULL`), the algorithm drops down to the next layer below. Since each layer below is less sparse than the layer above (with the bottom layer connecting all elements), the target will eventually be found. Skip lists offer O(log n) average complexity for both search and insertion/deletion. + +### Navigable Small World + +A navigable small world (NSW) is a special type of proximity graph that also includes long-range connections between nodes. These long-range connections support the “small world” property of the graph, meaning almost every node can be reached from any other node within a few hops. Without these additional long-range connections, many hops would be required to reach a far-away node. + +visual of an example navigable small world graph + +The “navigable” part of NSW specifically refers to the ability to logarithmically scale the greedy search algorithm on the graph, an algorithm that attempts to make only the locally optimal choice at each hop. Without this property, the graph may still be considered a small world with short paths between far-away nodes, but the greedy algorithm tends to miss them. Greedy search is ideal for NSW because it is quick to navigate and has low computational costs. + +### **Hierarchical +** Navigable Small World + +HNSW combines these two concepts. From the hierarchical perspective, the bottom layer consists of a NSW made up of short links between nodes. Each layer above “skips” elements and creates longer links between nodes further away from each other. + +Just like skip lists, search starts at the top layer and works its way down until it finds the target element. However, instead of comparing a scalar value at each layer to determine whether or not to descend to the layer below, a multi-dimensional distance measure (such as Euclidean distance) is used. + +## When should you create HNSW indexes? + +HNSW should be your default choice when creating a vector index. Add the index when you don't need 100% accuracy and are willing to trade a small amount of accuracy for a lot of throughput. + +Unlike IVFFlat indexes, you are safe to build an HNSW index immediately after the table is created. HNSW indexes are based on graphs which inherently are not affected by the same limitations as IVFFlat. As new data is added to the table, the index will be filled automatically and the index structure will remain optimal. + +## Resources + +Read more about indexing on `pgvector`'s [GitHub page](https://github.com/pgvector/pgvector#indexing). + +export const Page = ({ children }) => + +export default Page diff --git a/apps/docs/pages/guides/ai/managing-indexes.mdx b/apps/docs/pages/guides/ai/vector-indexes/ivf-indexes.mdx similarity index 61% rename from apps/docs/pages/guides/ai/managing-indexes.mdx rename to apps/docs/pages/guides/ai/vector-indexes/ivf-indexes.mdx index 6269919badf..cd03f55bd13 100644 --- a/apps/docs/pages/guides/ai/managing-indexes.mdx +++ b/apps/docs/pages/guides/ai/vector-indexes/ivf-indexes.mdx @@ -1,17 +1,60 @@ import Layout from '~/layouts/DefaultGuideLayout' export const meta = { - id: 'ai-managing-indexes', - title: 'Managing indexes', - description: 'Understanding vector indexes', - sidebar_label: 'Managing indexes', + id: 'ai-ivf-indexes', + title: 'IVFFlat indexes', + description: 'Understanding IVFFlat indexes in pgvector', + sidebar_label: 'IVFFlat indexes', } -Once your vector table starts to grow, you will likely want to add an index to speed up queries. Without indexes, you'll be performing a sequential scan which can be a resource-intensive operation when you have many records. +IVFFlat is a type of vector index for approximate nearest neighbor search. It is a frequently used index type that can improve performance when querying highly-dimensional vectors, like those representing embeddings. -## IVFFlat indexes +## Choosing an index -Today `pgvector` indexes use an algorithm called IVFFlat. IVF stands for 'inverted file indexes'. It works by clustering your vectors in order to reduce the similarity search scope. Rather than comparing a vector to every other vector, the vector is only compared against vectors within the same cell cluster (or nearby clusters, depending on your configuration). +Today `pgvector` supports two types of indexes: + +- [HNSW](/docs/guides/ai/vector-indexes/hnsw-indexes) +- [IVFFlat](/docs/guides/ai/vector-indexes/ivf-indexes) + +In general we recommend using [HNSW](/docs/guides/ai/vector-indexes/hnsw-indexes) because of its [performance](https://supabase.com/blog/increase-performance-pgvector-hnsw#hnsw-performance-1536-dimensions) and [robustness against changing data](/docs/guides/ai/vector-indexes/hnsw-indexes#when-should-you-create-hnsw-indexes). If you have a special use case that requires IVFFlat instead, keep reading. + +## Usage + +The way you create an IVFFlat index depends on the distance operator you are using. `pgvector` includes 3 distance operators: + +| Operator | Description | [**Operator class**](https://www.postgresql.org/docs/current/sql-createopclass.html) | +| -------- | ---------------------- | ------------------------------------------------------------------------------------ | +| `<->` | Euclidean distance | `vector_l2_ops` | +| `<#>` | negative inner product | `vector_ip_ops` | +| `<=>` | cosine distance | `vector_cosine_ops` | + +Use the following SQL commands to create an IVFFlat index for the operator(s) used in your queries. + +### Euclidean L2 distance (`vector_l2_ops`) + +```sql +create index on items using ivfflat (column_name vector_l2_ops) with (lists = 100); +``` + +### Inner product (`vector_ip_ops`) + +```sql +create index on items using ivfflat (column_name vector_ip_ops) with (lists = 100); +``` + +### Cosine distance (`vector_cosine_ops`) + +```sql +create index on items using ivfflat (column_name vector_cosine_ops) with (lists = 100); +``` + +Currently vectors with up to 2,000 dimensions can be indexed. + +If you are using the `vecs` Python library, follow the instructions in [Managing collections](/docs/guides/ai/managing-collections#create-an-index) to create indexes. + +## How does IVFFlat work? + +IVF stands for 'inverted file indexes'. It works by clustering your vectors in order to reduce the similarity search scope. Rather than comparing a vector to every other vector, the vector is only compared against vectors within the same cell cluster (or nearby clusters, depending on your configuration). ### Inverted lists (cell clusters) @@ -48,43 +91,9 @@ If the number of probes is the same as the number of lists, exact nearest neighb One important note with IVF indexes is that nearest neighbor search is approximate, since exact search on high dimensional data can't be indexed efficiently. This means that similarity results will change (slightly) after you add an index (trading recall for speed). -## Distance operators +## When should you create IVFFlat indexes? -The type of index required depends on the distance operator you are using. `pgvector` includes 3 distance operators: - -| Operator | Description | [**Operator class**](https://www.postgresql.org/docs/current/sql-createopclass.html) | -| -------- | ---------------------- | ------------------------------------------------------------------------------------ | -| `<->` | Euclidean distance | `vector_l2_ops` | -| `<#>` | negative inner product | `vector_ip_ops` | -| `<=>` | cosine distance | `vector_cosine_ops` | - -Use the following SQL commands to create an index for the operator(s) used in your queries. - -### Euclidean L2 distance (`vector_l2_ops`) - -```sql -create index on items using ivfflat (column_name vector_l2_ops) with (lists = 100); -``` - -### Inner product (`vector_ip_ops`) - -```sql -create index on items using ivfflat (column_name vector_ip_ops) with (lists = 100); -``` - -### Cosine distance (`vector_cosine_ops`) - -```sql -create index on items using ivfflat (column_name vector_cosine_ops) with (lists = 100); -``` - -Currently vectors with up to 2,000 dimensions can be indexed. - -If you are using the `vecs` Python library, follow the instructions in [Managing collections](/docs/guides/ai/managing-collections#create-an-index) to create indexes. - -## When should you add indexes? - -`pgvector` recommends adding indexes only after the table has sufficient data, so that the internal IVFFlat cell clusters are based on your data's distribution. Anytime the distribution changes significantly, consider recreating indexes. +`pgvector` recommends building IVFFlat indexes only after the table has sufficient data, so that the internal IVFFlat cell clusters are based on your data's distribution. Anytime the distribution changes significantly, consider rebuilding indexes. ## Resources diff --git a/apps/docs/pages/guides/auth.mdx b/apps/docs/pages/guides/auth.mdx index b827086f831..2a516ff35ea 100644 --- a/apps/docs/pages/guides/auth.mdx +++ b/apps/docs/pages/guides/auth.mdx @@ -6,12 +6,10 @@ export const meta = { id: 'auth', title: 'Auth', description: 'Use Supabase to Authenticate and Authorize your users.', - sidebar_label: 'Overview', + subtitle: 'Use Supabase to authenticate and authorize your users.', video: 'https://www.youtube.com/v/6ow_jW4epf8', } -## Overview - There are two parts to every Auth system: - **Authentication:** should this person be allowed in? If yes, who are they? @@ -64,56 +62,13 @@ You can enable third-party providers with the click of a button by navigating to ### Redirect URLs and wildcards -When using third-party providers, the [Supabase client library](/docs/reference/javascript/auth-signinwithoauth#sign-in-using-a-third-party-provider-with-redirect) redirects the user to the provider. When the third-party provider successfully authenticates the user, the provider redirects the user to the Supabase Auth callback URL where they are further redirected to the URL specified in the `redirectTo` parameter. This parameter defaults to the [`SITE_URL`](/docs/reference/auth/config#site_url). You can modify the `SITE_URL` or add additional [redirect URLs](https://supabase.com/dashboard/project/_/auth/url-configuration). +We've moved the guide for setting up redirect URLs [here](/docs/guides/auth/concepts/redirect-urls). -You can use wildcard match patterns to support preview URLs from providers like Netlify and Vercel. See the [full list of supported patterns](https://pkg.go.dev/github.com/gobwas/glob#Compile). Use [this tool](https://www.digitalocean.com/community/tools/glob?comments=true&glob=http%3A%2F%2Flocalhost%3A3000%2F%2A%2A&matches=false&tests=http%3A%2F%2Flocalhost%3A3000&tests=http%3A%2F%2Flocalhost%3A3000%2F&tests=http%3A%2F%2Flocalhost%3A3000%2F%3Ftest%3Dtest&tests=http%3A%2F%2Flocalhost%3A3000%2Ftest-test%3Ftest%3Dtest&tests=http%3A%2F%2Flocalhost%3A3000%2Ftest%2Ftest%3Ftest%3Dtest) to test your patterns. +#### [Netlify preview URLs](/docs/guides/auth/concepts/redirect-urls#netlify-preview-urls) - +#### [Vercel preview URLs](/docs/guides/auth/concepts/redirect-urls#vercel-preview-urls) -While the "globstar" (`**`) is useful for local development and preview URLs, we recommend setting the exact redirect URL path for your site URL in production. - - - -#### Netlify preview URLs - -For deployments with Netlify, set the `SITE_URL` to your official site URL. Add the following additional redirect URLs for local development and deployment previews: - -- `http://localhost:3000/**` -- `https://**--my_org.netlify.app/**` - -#### Vercel preview URLs - -For deployments with Vercel, set the `SITE_URL` to your official site URL. Add the following additional redirect URLs for local development and deployment previews: - -- `http://localhost:3000/**` -- `https://*-username.vercel.app/**` - -Vercel provides an environment variable for the URL of the deployment called `NEXT_PUBLIC_VERCEL_URL`. See the [Vercel docs](https://vercel.com/docs/concepts/projects/environment-variables#system-environment-variables) for more details. You can use this variable to dynamically redirect depending on the environment. You should also set the value of the environment variable called NEXT_PUBLIC_SITE_URL, this should be set to your site URL in production environment to ensure that redirects function correctly. - -```js -const getURL = () => { - let url = - process?.env?.NEXT_PUBLIC_SITE_URL ?? // Set this to your site URL in production env. - process?.env?.NEXT_PUBLIC_VERCEL_URL ?? // Automatically set by Vercel. - 'http://localhost:3000/' - // Make sure to include `https://` when not localhost. - url = url.includes('http') ? url : `https://${url}` - // Make sure to include a trailing `/`. - url = url.charAt(url.length - 1) === '/' ? url : `${url}/` - return url -} - -const { data, error } = await supabase.auth.signInWithOAuth({ - provider: 'github', - options: { - redirectTo: getURL(), - }, -}) -``` - -#### Mobile deep linking URIs - -For mobile applications you can use deep linking URIs. For example for your `SITE_URL` you can specify something like `com.supabase://login-callback/` and for additional redirect URLs something like `com.supabase.staging://login-callback/` if needed. +#### [Mobile deep linking URIs](/docs/guides/auth/concepts/redirect-urls#mobile-deep-linking-uris) ## Authorization diff --git a/apps/docs/pages/guides/auth/concepts/redirect-urls.mdx b/apps/docs/pages/guides/auth/concepts/redirect-urls.mdx new file mode 100644 index 00000000000..371df16ed15 --- /dev/null +++ b/apps/docs/pages/guides/auth/concepts/redirect-urls.mdx @@ -0,0 +1,87 @@ +import Layout from '~/layouts/DefaultGuideLayout' + +export const meta = { + id: 'redirect-urls', + title: 'Redirect URLs', + description: 'Set up redirect urls with Supabase Auth.', + subtitle: 'Set up redirect urls with Supabase Auth.', +} + +## Overview + +When using [passwordless sign-ins](/docs/reference/javascript/auth-signinwithotp) or [third-party providers](/docs/reference/javascript/auth-signinwithoauth#sign-in-using-a-third-party-provider-with-redirect), the Supabase client library methods provide a `redirectTo` parameter to specify where to redirect the user to after authentication. By default, the user will be redirected to the [`SITE_URL`](/docs/reference/auth/config#site_url) but you can modify the `SITE_URL` or add additional redirect URLs to the [allow list](https://supabase.com/dashboard/project/_/auth/url-configuration). Once you've added necessary URLs to the allow list, you can specify the URL you want the user to be redirected to in the `redirectTo` parameter. + +## Use wildcards in redirect URLs + +Supabase allows you to specify wildcards when adding redirect URLs to the [allow list](https://supabase.com/dashboard/project/_/auth/url-configuration). You can use wildcard match patterns to support preview URLs from providers like Netlify and Vercel. + +| Wildcard | Description | +| ------------------------ | ------------------------------------------------------------------------------------------------------------------------------------------ | +| `*` | matches any sequence of non-separator characters | +| `**` | matches any sequence of characters | +| `?` | matches any single non-separator character | +| `c` | matches character c (c != `*`, `**`, `?`, `\`, `[`, `{`, `}`) | +| `\c` | matches character c | +| `[!{ character-range }]` | matches any sequence of characters not in the `{ character-range }`. For example, `[!a-z]` will not match any characters ranging from a-z. | + +The separator characters in a URL are defined as `.` and `/`. Use [this tool](https://www.digitalocean.com/community/tools/glob?comments=true&glob=http%3A%2F%2Flocalhost%3A3000%2F%2A%2A&matches=false&tests=http%3A%2F%2Flocalhost%3A3000&tests=http%3A%2F%2Flocalhost%3A3000%2F&tests=http%3A%2F%2Flocalhost%3A3000%2F%3Ftest%3Dtest&tests=http%3A%2F%2Flocalhost%3A3000%2Ftest-test%3Ftest%3Dtest&tests=http%3A%2F%2Flocalhost%3A3000%2Ftest%2Ftest%3Ftest%3Dtest) to test your patterns. + + + +While the "globstar" (`**`) is useful for local development and preview URLs, we recommend setting the exact redirect URL path for your site URL in production. + + + +### Redirect URL examples with wildcards + +| Redirect URL | Description | +| ------------------------------ | ------------------------------------------------------------------------------------------------------------------------------------------------------------------ | +| `http://localhost:3000/*` | matches `http://localhost:3000/foo`, `http://localhost:3000/bar` but not `http://localhost:3000/foo/bar` or `http://localhost:3000/foo/` (note the trailing slash) | +| `http://localhost:3000/**` | matches `http://localhost:3000/foo`, `http://localhost:3000/bar` and `http://localhost:3000/foo/bar` | +| `http://localhost:3000/?` | matches `http://localhost:3000/a` but not `http://localhost:3000/foo` | +| `http://localhost:3000/[!a-z]` | matches `http://localhost:3000/1` but not `http://localhost:3000/a` | + +## Netlify preview URLs + +For deployments with Netlify, set the `SITE_URL` to your official site URL. Add the following additional redirect URLs for local development and deployment previews: + +- `http://localhost:3000/**` +- `https://**--my_org.netlify.app/**` + +## Vercel preview URLs + +For deployments with Vercel, set the `SITE_URL` to your official site URL. Add the following additional redirect URLs for local development and deployment previews: + +- `http://localhost:3000/**` +- `https://*-username.vercel.app/**` + +Vercel provides an environment variable for the URL of the deployment called `NEXT_PUBLIC_VERCEL_URL`. See the [Vercel docs](https://vercel.com/docs/concepts/projects/environment-variables#system-environment-variables) for more details. You can use this variable to dynamically redirect depending on the environment. You should also set the value of the environment variable called NEXT_PUBLIC_SITE_URL, this should be set to your site URL in production environment to ensure that redirects function correctly. + +```js +const getURL = () => { + let url = + process?.env?.NEXT_PUBLIC_SITE_URL ?? // Set this to your site URL in production env. + process?.env?.NEXT_PUBLIC_VERCEL_URL ?? // Automatically set by Vercel. + 'http://localhost:3000/' + // Make sure to include `https://` when not localhost. + url = url.includes('http') ? url : `https://${url}` + // Make sure to include a trailing `/`. + url = url.charAt(url.length - 1) === '/' ? url : `${url}/` + return url +} + +const { data, error } = await supabase.auth.signInWithOAuth({ + provider: 'github', + options: { + redirectTo: getURL(), + }, +}) +``` + +## Mobile deep linking URIs + +For mobile applications you can use deep linking URIs. For example, for your `SITE_URL` you can specify something like `com.supabase://login-callback/` and for additional redirect URLs something like `com.supabase.staging://login-callback/` if needed. + +export const Page = ({ children }) => + +export default Page diff --git a/apps/docs/pages/guides/auth/server-side/email-based-auth-with-pkce-flow-for-ssr.mdx b/apps/docs/pages/guides/auth/server-side/email-based-auth-with-pkce-flow-for-ssr.mdx index 81bba10258e..9e41fe99ede 100644 --- a/apps/docs/pages/guides/auth/server-side/email-based-auth-with-pkce-flow-for-ssr.mdx +++ b/apps/docs/pages/guides/auth/server-side/email-based-auth-with-pkce-flow-for-ssr.mdx @@ -168,7 +168,7 @@ export const GET = async (event) => { url, locals: { supabase } } = event; - const token_hash = url.searchParams.get('token') as string; + const token_hash = url.searchParams.get('token_hash') as string; const type = url.searchParams.get('type') as string; const next = url.searchParams.get('next') ?? '/'; diff --git a/apps/docs/pages/guides/database/column-encryption.mdx b/apps/docs/pages/guides/database/column-encryption.mdx index 1734d88a6af..0f6d7e599ee 100644 --- a/apps/docs/pages/guides/database/column-encryption.mdx +++ b/apps/docs/pages/guides/database/column-encryption.mdx @@ -11,7 +11,7 @@ export const meta = { Supabase provides a secure method for encrypting data using [Vault](/docs/guides/database/vault), our Postgres secrets manager. Vault is a Postgres extension with an [integrated UI](https://app.supabase.com/project/_/settings/vault/secrets) intended to act as a secure global secrets management for your project. -In addition to the Vault secret storage table, Supabase also enables an advanced feature called Transparent Column Encryption (TCE) which provides a safe way to encrypt columns in your own tables so that they doesn't leak into logs and backups. It can also provide row-level authenticated encryption. +In addition to the Vault secret storage table, Supabase also enables an advanced feature called Transparent Column Encryption (TCE) which provides a safe way to encrypt columns in your own tables so that they don't leak into logs and backups. It can also provide row-level authenticated encryption. Column Encryption comes with tradeoffs that need to be considered before using it. diff --git a/apps/docs/pages/guides/database/extensions/index_advisor.mdx b/apps/docs/pages/guides/database/extensions/index_advisor.mdx index d155c36a49b..988d2f315b2 100644 --- a/apps/docs/pages/guides/database/extensions/index_advisor.mdx +++ b/apps/docs/pages/guides/database/extensions/index_advisor.mdx @@ -31,7 +31,7 @@ Features: ## Installation -index_advisor is a trusted language extension, which means it is directly installable by users from the [database.dev](database.dev) SQL package repository. +index_advisor is a trusted language extension, which means it is directly installable by users from the [database.dev](https://database.dev/) SQL package repository. To get started, enable the dbdev client by executing the [setup SQL script](https://database.dev/installer). diff --git a/apps/docs/pages/guides/database/postgres/triggers.mdx b/apps/docs/pages/guides/database/postgres/triggers.mdx index 58b8aca96f4..bd3a48106c2 100644 --- a/apps/docs/pages/guides/database/postgres/triggers.mdx +++ b/apps/docs/pages/guides/database/postgres/triggers.mdx @@ -49,7 +49,7 @@ $$; create trigger salary_update_trigger after update on employees for each row -exectute function update_salary_log(); +execute function update_salary_log(); ``` ### Trigger variables diff --git a/apps/docs/pages/guides/platform/compute-add-ons.mdx b/apps/docs/pages/guides/platform/compute-add-ons.mdx index d3bd4ad528a..e809e93476a 100644 --- a/apps/docs/pages/guides/platform/compute-add-ons.mdx +++ b/apps/docs/pages/guides/platform/compute-add-ons.mdx @@ -8,21 +8,23 @@ export const meta = { Every project on the Supabase Platform comes with its own dedicated Postgres instance running inside a virtual machine (VM). The following table describes the base instance with additional compute add-ons available if you need extra performance when scaling up Supabase. -| Plan | Pricing | CPU | Memory | Connections: Direct | Connections: Pooler | -| --------------- | ------- | ----------------------- | ------ | ------------------- | ------------------- | -| Free (Included) | $0 | 2-core ARM (shared) | 1 GB | 60 | 200 | -| Small | $5 | 2-core ARM (shared) | 2 GB | 90 | 200 | -| Medium | $50 | 2-core ARM (shared) | 4 GB | 120 | 200 | -| Large | $100 | 2-core ARM (dedicated) | 8 GB | 160 | 300 | -| XL | $200 | 4-core ARM (dedicated) | 16 GB | 240 | 700 | -| 2XL | $400 | 8-core ARM (dedicated) | 32 GB | 380 | 1500 | -| 4XL | $950 | 16-core ARM (dedicated) | 64 GB | 480 | 3000 | -| 8XL | $1,860 | 32-core ARM (dedicated) | 128 GB | 490 | 6000 | -| 12XL | $2,790 | 48-core ARM (dedicated) | 192 GB | 500 | 9000 | -| 16XL | $3,720 | 64-core ARM (dedicated) | 256 GB | 500 | 12,000 | +| Plan | Hourly Price USD | Monthly Price USD | CPU | Memory | Connections: Direct | Connections: Pooler | +| ------- | ---------------- | ----------------- | ----------------------- | ------ | ------------------- | ------------------- | +| Starter | $0.01344 | ~$10 | 2-core ARM (shared) | 1 GB | 60 | 200 | +| Small | $0.0206 | ~$15 | 2-core ARM (shared) | 2 GB | 90 | 200 | +| Medium | $0.0822 | ~$60 | 2-core ARM (shared) | 4 GB | 120 | 200 | +| Large | $0.1517 | ~$110 | 2-core ARM (dedicated) | 8 GB | 160 | 300 | +| XL | $0.2877 | ~$210 | 4-core ARM (dedicated) | 16 GB | 240 | 700 | +| 2XL | $0.562 | ~$410 | 8-core ARM (dedicated) | 32 GB | 380 | 1500 | +| 4XL | $1.32 | ~$960 | 16-core ARM (dedicated) | 64 GB | 480 | 3000 | +| 8XL | $2.562 | ~$1,870 | 32-core ARM (dedicated) | 128 GB | 490 | 6000 | +| 12XL | $3.836 | ~$2,800 | 48-core ARM (dedicated) | 192 GB | 500 | 9000 | +| 16XL | $5.12 | ~$3,730 | 64-core ARM (dedicated) | 256 GB | 500 | 12,000 | Number of connections above are recommended values. +We charge hourly for additional compute based on your usage. Read more about [usage-based billing for compute](/docs/guides/platform/org-based-billing#usage-based-billing-for-compute). + [Contact us](https://supabase.com/contact/enterprise) if you require a custom plan. ## Dedicated vs. shared CPU @@ -37,18 +39,18 @@ When considering compute upgrades, assess whether your bottlenecks are hardware- SSD Disks are attached to your servers and the disk performance depends on the compute add-on of your instance. Disk IO refers to two metrics: throughput (Megabits per Second) and IOPS (Input/Output Operations per Second). -| Plan | Pricing | Max Disk Throughput | Baseline Disk Throughput | Max IOPS | Baseline IOPS | -| --------------- | ------- | ------------------- | ------------------------ | ----------- | ------------- | -| Free (Included) | $0 | 2,085 Mbps | 87 Mbps | 11,800 IOPS | 500 IOPS | -| Small | $5 | 2,085 Mbps | 174 Mbps | 11,800 IOPS | 1,000 IOPS | -| Medium | $50 | 2,085 Mbps | 347 Mbps | 11,800 IOPS | 2,000 IOPS | -| Large | $100 | 4,750 Mbps | 630 Mbps | 20,000 IOPS | 3,600 IOPS | -| XL | $200 | 4,750 Mbps | 1,188 Mbps | 20,000 IOPS | 6,000 IOPS | -| 2XL | $400 | 4,750 Mbps | 2,375 Mbps | 20,000 IOPS | 12,000 IOPS | -| 4XL | $950 | 4,750 Mbps | 4,750 Mbps | 20,000 IOPS | 20,000 IOPS | -| 8XL | $1,860 | 9,500 Mbps | 9,500 Mbps | 40,000 IOPS | 40,000 IOPS | -| 12XL | $2,790 | 14,250 Mbps | 14,250 Mbps | 50,000 IOPS | 50,000 IOPS | -| 16XL | $3,720 | 19,000 Mbps | 19,000 Mbps | 80,000 IOPS | 80,000 IOPS | +| Plan | Max Disk Throughput | Baseline Disk Throughput | Max IOPS | Baseline IOPS | +| ------- | ------------------- | ------------------------ | ----------- | ------------- | +| Starter | 2,085 Mbps | 87 Mbps | 11,800 IOPS | 500 IOPS | +| Small | 2,085 Mbps | 174 Mbps | 11,800 IOPS | 1,000 IOPS | +| Medium | 2,085 Mbps | 347 Mbps | 11,800 IOPS | 2,000 IOPS | +| Large | 4,750 Mbps | 630 Mbps | 20,000 IOPS | 3,600 IOPS | +| XL | 4,750 Mbps | 1,188 Mbps | 20,000 IOPS | 6,000 IOPS | +| 2XL | 4,750 Mbps | 2,375 Mbps | 20,000 IOPS | 12,000 IOPS | +| 4XL | 4,750 Mbps | 4,750 Mbps | 20,000 IOPS | 20,000 IOPS | +| 8XL | 9,500 Mbps | 9,500 Mbps | 40,000 IOPS | 40,000 IOPS | +| 12XL | 14,250 Mbps | 14,250 Mbps | 50,000 IOPS | 50,000 IOPS | +| 16XL | 19,000 Mbps | 19,000 Mbps | 80,000 IOPS | 80,000 IOPS | [Contact us](https://supabase.com/contact/enterprise) if you require a custom plan. diff --git a/apps/docs/pages/guides/platform/migrating-and-upgrading-projects.mdx b/apps/docs/pages/guides/platform/migrating-and-upgrading-projects.mdx index f425d5d260d..38272bbf5c8 100644 --- a/apps/docs/pages/guides/platform/migrating-and-upgrading-projects.mdx +++ b/apps/docs/pages/guides/platform/migrating-and-upgrading-projects.mdx @@ -132,6 +132,10 @@ const NEW_PROJECT_SERVICE_KEY = 'new-project-service-key-yyy' })() ``` +### Transfer to a different organization + +Note that project migration is for transferring your projects to different regions. If you need to move your project to a different organization without touching the infrastrusture, see [project transfers](/docs/guides/platform/project-transfer). + export const Page = ({ children }) => export default Page diff --git a/apps/docs/pages/guides/platform/org-based-billing.mdx b/apps/docs/pages/guides/platform/org-based-billing.mdx index a63986576c4..deca224bf12 100644 --- a/apps/docs/pages/guides/platform/org-based-billing.mdx +++ b/apps/docs/pages/guides/platform/org-based-billing.mdx @@ -123,7 +123,7 @@ If you launch a second or third instance on your paid plan, we add the additiona | 12XL | $3.836 | ~$2800 | | 16XL | $5.12 | ~$3730 | -With Legacy Billing, when you upgraded the [Compute Add-On](/docs/guides/platform/compute-add-ons), you were immediately charged the prorated amount (days left in your current billing cycle) and when your billing cycle reset you were charged upfront for the entire month. When you downgraded, you got the appropriate credits for unused time. +With Legacy Billing, when you upgraded the [Compute Add-On](/docs/guides/platform/compute-add-ons), you were immediately charged the prorated amount (days remaining in your current billing cycle) and when your billing cycle reset you were charged upfront for the entire month. When you downgraded, you got the appropriate credits for unused time. ### Free plan diff --git a/apps/docs/pages/guides/realtime/realtime-with-nextjs.mdx b/apps/docs/pages/guides/realtime/realtime-with-nextjs.mdx index e60afb4f74a..fd9e8d98675 100644 --- a/apps/docs/pages/guides/realtime/realtime-with-nextjs.mdx +++ b/apps/docs/pages/guides/realtime/realtime-with-nextjs.mdx @@ -7,8 +7,8 @@ export const meta = { sidebar_label: 'Videos', } -In this guide we explore the best ways to receive realtime Postgres changes with your Next.js application. -We'll show both client and serverside updates, and explore the which option is best. +In this guide, we explore the best ways to receive real-time Postgres changes with your Next.js application. +We'll show both client and server side updates, and explore which option is best.