From 290525263ff58c875a53383d885639ed2ee21e75 Mon Sep 17 00:00:00 2001
From: 0xflotus <0xflotus@gmail.com>
Date: Tue, 8 Aug 2023 00:30:10 +0200
Subject: [PATCH 01/58] chore: fixed some small errors in blogpost
---
apps/www/_blog/2023-08-07-hugging-face-supabase.mdx | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/apps/www/_blog/2023-08-07-hugging-face-supabase.mdx b/apps/www/_blog/2023-08-07-hugging-face-supabase.mdx
index d421d8918c8..f383c9b53c7 100644
--- a/apps/www/_blog/2023-08-07-hugging-face-supabase.mdx
+++ b/apps/www/_blog/2023-08-07-hugging-face-supabase.mdx
@@ -212,7 +212,7 @@ We’re in the early stages of development, and we have some exciting ideas to o
### Reducing cold starts
-Cold-starts are the time it takes for the “initial load” of an Edge Function. Because the model needs to be downloaded to the Edge Function, could starts can take anywhere from ~2-6s (based on the model). Loading the initial model and building the pipeline usually contributes to it. We are experimenting with the idea of attaching a “read-only disk” of models to our [Edge Runtime](https://github.com/supabase/edge-runtime) which mitigate any download penalties. We’ll share more details about these optimizations in a future blog post.
+Cold-starts are the time it takes for the “initial load” of an Edge Function. Because the model needs to be downloaded to the Edge Function, cold starts can take anywhere from ~2-6s (based on the model). Loading the initial model and building the pipeline usually contributes to it. We are experimenting with the idea of attaching a “read-only disk” of models to our [Edge Runtime](https://github.com/supabase/edge-runtime) which mitigate any download penalties. We’ll share more details about these optimizations in a future blog post.
### Handling heavier workloads
@@ -228,7 +228,7 @@ Images have the same challenge. Models like CLIP, which can generate embeddings
## Getting started
-If you’re a Python Dev, check out our [Hello World notebook](https://supabase.com/docs/guides/ai/quickstarts/hello-world). If you’re a JavaScript developer, check out our our [Text Embeddings docs](https://supabase.com/docs/guides/ai/quickstarts/generate-text-embeddings).
+If you’re a Python Dev, check out our [Hello World notebook](https://supabase.com/docs/guides/ai/quickstarts/hello-world). If you’re a JavaScript developer, check out our [Text Embeddings docs](https://supabase.com/docs/guides/ai/quickstarts/generate-text-embeddings).
And no matter your language preference, remember to jump into the [Hugging Face community](https://github.com/huggingface) and show your support.
From cc1fc84cb69e7d1ee687ed300c6272df31f90245 Mon Sep 17 00:00:00 2001
From: 0xflotus <0xflotus@gmail.com>
Date: Tue, 8 Aug 2023 15:18:39 +0200
Subject: [PATCH 02/58] Update 2023-08-07-hugging-face-supabase.mdx
---
apps/www/_blog/2023-08-07-hugging-face-supabase.mdx | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/apps/www/_blog/2023-08-07-hugging-face-supabase.mdx b/apps/www/_blog/2023-08-07-hugging-face-supabase.mdx
index f383c9b53c7..fcc912fb525 100644
--- a/apps/www/_blog/2023-08-07-hugging-face-supabase.mdx
+++ b/apps/www/_blog/2023-08-07-hugging-face-supabase.mdx
@@ -212,7 +212,7 @@ We’re in the early stages of development, and we have some exciting ideas to o
### Reducing cold starts
-Cold-starts are the time it takes for the “initial load” of an Edge Function. Because the model needs to be downloaded to the Edge Function, cold starts can take anywhere from ~2-6s (based on the model). Loading the initial model and building the pipeline usually contributes to it. We are experimenting with the idea of attaching a “read-only disk” of models to our [Edge Runtime](https://github.com/supabase/edge-runtime) which mitigate any download penalties. We’ll share more details about these optimizations in a future blog post.
+Cold starts are the time it takes for the “initial load” of an Edge Function. Because the model needs to be downloaded to the Edge Function, cold starts can take anywhere from ~2-6s (based on the model). Loading the initial model and building the pipeline usually contributes to it. We are experimenting with the idea of attaching a “read-only disk” of models to our [Edge Runtime](https://github.com/supabase/edge-runtime) which mitigate any download penalties. We’ll share more details about these optimizations in a future blog post.
### Handling heavier workloads
From cbec48032f7e269b5fa466a20aa696dac0aa9e25 Mon Sep 17 00:00:00 2001
From: egor-romanov
Date: Thu, 10 Aug 2023 13:47:33 +0300
Subject: [PATCH 03/58] add limitations block to realtime docs
---
.../guides/realtime/postgres-changes.mdx | 25 +++++++++++++++++++
1 file changed, 25 insertions(+)
diff --git a/apps/docs/pages/guides/realtime/postgres-changes.mdx b/apps/docs/pages/guides/realtime/postgres-changes.mdx
index 57b1d355830..9194b347419 100644
--- a/apps/docs/pages/guides/realtime/postgres-changes.mdx
+++ b/apps/docs/pages/guides/realtime/postgres-changes.mdx
@@ -531,6 +531,31 @@ For example, if you're using the `supabase-js` `v2` client then you can pass you
supabase.realtime.setAuth('fresh-token')
```
+## Limitations
+
+Realtime's Postgres Changes feature has the following limitations in terms of performance at the current time. There is a bottleneck on the database side that limits the number of messages that can be streamed to subscribed clients.
+
+The polling query that fetches the changes can only work in a single thread. This means that if you have a lot of changes happening in your database, the polling query will be blocked and will not be able to fetch the changes fast enough. This will result in a delay in the changes being sent to the subscribed clients until you will get timeouted. Additionally, the polling query works per each subscribed client, this means that each unique pair of `filters` and `JWT token` (logged-in user) will affect the performance of the polling query. In other words, RLS and filters can further limit the number of messages that can be streamed to subscribed clients.
+
+From our testing and observation of the performance of the polling query, we have found that the following limits are safe to use:
+
+| Database Add-on | Filters | RLS Usage | Concurrent Clients | Records per second per client | Messages per second (total) | Latency p95 (ms) |
+| ---------------- | ------- | --------- | ------------------ | ----------------------------- | --------------------------- | ---------------- |
+| micro < > medium | 🚫 | 🚫 | 500 | 10 | 5,000 | 257 |
+| micro < > medium | 🚫 | 🚫 | 1,000 | 10 | 10,000 | 800 |
+| micro < > medium | 🚫 | 🚫 | 5,000 | 2 | 10,000 | 1,120 |
+| large and above | 🚫 | 🚫 | 1,000 | 10 | 10,000 | 261 |
+| large and above | 🚫 | 🚫 | 5,000 | 2 | 10,000 | 952 |
+| large and above | 🚫 | 🚫 | 10,000 | 1 | 10,000 | 949 |
+| large and above | 🚫 | 🚫 | 200,000 | 0.04 (1 in 25 seconds) | 8,000 | 15,709 |
+| large and above | ✅ | ✅ | 500 | 2 | 1,000 | 262 |
+| large and above | ✅ | ✅ | 1,000 | 1 | 1,000 | 431 |
+| large and above | ✅ | ✅ | 5,000 | 0.2 (1 in 5 seconds) | 1,000 | 702 |
+
+If you want to use Realtime's Postgres Changes feature you should be aware of these limitations. And if you are planning to use this feature at scale, you should consider using separate table without RLS and filters for the purpose of streaming changes to subscribed clients. Another option is to use it on the server side only and restream the changes to your clients using a Realtime Broadcast because it does not have these limitations.
+
+We have ideas on how to improve Realtime's Postgres Changes in the future. Follow Supabase to stay up to date with the latest news and updates on this feature.
+
## More Realtime Quickstarts
- [Broadcast Quickstart](/docs/guides/realtime/broadcast)
From eda23408c80781e98808deee0cb8362696605e8f Mon Sep 17 00:00:00 2001
From: TzeYiing
Date: Thu, 10 Aug 2023 18:50:27 +0800
Subject: [PATCH 04/58] docs: remove bigquery setup in local development docs
---
.../pages/guides/cli/local-development.mdx | 32 +++----------------
1 file changed, 4 insertions(+), 28 deletions(-)
diff --git a/apps/docs/pages/guides/cli/local-development.mdx b/apps/docs/pages/guides/cli/local-development.mdx
index 1682de48d8c..161d08a73e1 100644
--- a/apps/docs/pages/guides/cli/local-development.mdx
+++ b/apps/docs/pages/guides/cli/local-development.mdx
@@ -423,39 +423,15 @@ If you have additional triggers or RLS policies defined on your `auth` schema, y
supabase db remote commit --schema auth
```
-### Enabling Local Logging
+### Local Logging
-Local logs rely on the Supabase Analytics Server. This can be enabled via the CLI configuration, and requires a Google Cloud project and BigQuery access.
+Local logs rely on the Supabase Analytics Server, and are available in the Studio automatically.
- The Google Cloud project must have billing enabled. The dataset created and managed by Analytics
- will be within the US. Read more about this requirement
- [here](https://supabase.com/docs/reference/self-hosting-analytics/introduction#bigquery).
+ For advanced logs analysis using the Logs Explorer, it is advised to use the BigQuery backend instead of the default Postgres backend. Read about the steps [here](https://supabase.com/docs/reference/self-hosting-analytics/introduction#bigquery).
-Requirements:
-
-1. Google Cloud project number
-2. Google Cloud project ID
-3. Google Cloud Service Account Key, obtained through [Google Cloud IAM dashboard](https://console.cloud.google.com/iam-admin/iam), with BigQuery Admin role assigned to the service account.
-
-Once you have these 3 items, follow these steps:
-
-First, update your project's `supabase/config.toml`:
-
-```bash
-[analytics]
-enabled = true
-gcp_project_number = "123456"
-gcp_project_id = "my-project-id"
-gcp_jwt_path = "supabase/gcloud.json"
-```
-
-Next, place your service account key (a JSON file) at the corresponding path and ensure that it is correctly named.
-
-Last, start your local stack using `supabase start`
-
-This will switch the logging drivers and will direct logs to the Analytics server. You will be able to view and query your logs via the Studio Logs Explorer and Logs UI.
+Logs will be directed to the Analytics server instead of the docker logging driver. All logs will be stored in the local database under the `_analytics` schema.
## Limitations and considerations
From 7a682b01173634ce55aa6b69cc3a7a3f0589693f Mon Sep 17 00:00:00 2001
From: Michel Pelletier
Date: Thu, 10 Aug 2023 06:51:35 -0700
Subject: [PATCH 05/58] update to column encryption docs with more explanations
of risk/reward and key get/set through API.
---
.../guides/database/column-encryption.mdx | 44 +++++++++++++++++--
1 file changed, 41 insertions(+), 3 deletions(-)
diff --git a/apps/docs/pages/guides/database/column-encryption.mdx b/apps/docs/pages/guides/database/column-encryption.mdx
index d750f6c33b1..9746544ad09 100644
--- a/apps/docs/pages/guides/database/column-encryption.mdx
+++ b/apps/docs/pages/guides/database/column-encryption.mdx
@@ -9,9 +9,27 @@ export const meta = {
video: 'https://www.youtube.com/v/J9mTPY8rIXE',
}
-Supabase provides a secure method for encrypting columns using [Vault](/docs/guides/database/vault), our Postgres secrets manager. Vault is a Postgres extension with an integrated UI intended to act as a secure global secrets management for your project.
+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 intended to act as a secure global secrets management for your project.
-Vault enables an advanced feature called Transparent Column Encryption (TCE) which provides a safe way to encrypt your data so that it 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 doesn'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.
+
+ - Encryption and decryption both take time, inserting and selecting encrypted data takes more time than a "plain" column of data. Queries that must load a lot of rows with encrypted columns will be slower than those that are not encrypted.
+
+ - Encrypted columns should never be indexed. This is because the index must store the unencrypted value of a column to be useful, which would defeat the purpose of storing values encrypted. To look up an encrypted column, you must first look up its row by some other unencrypted column, like a primary key.
+
+ - Encrypted columns can be queried in a `WHERE` clause, but this can also have some negative performance consequences, since the value must be decrypted in order to matched to any `WHERE` qualifiers. For small result sets this is not a big deal, but broad queries that match many rows will have to be scanned and each row decrypted in order to check against the `WHERE` clause. Worst case is the entire table must be scanned and decrypted to check against a `WHERE`.
+
+ - While you can encrypt multiple columns in the same table, each column must go through a full encryption cycle, so two columns will take twice the time as one, three columns three time as long, and so on. It is usually better to break up large tables into smaller tables with at most one or two encrypted columns, and associated them with [foreign keys](https://www.postgresql.org/docs/current/tutorial-fk.html) that can be used to JOIN them when necessary.
+
+In general, it is a bad idea to over-use column encryption for mundane data or data that you need to search against such as names, user or account types, addresses, country codes, etc. Column encryption is intended to be used for very sensitive data that would cause serious issues if it were to leak, such as API keys, payment keys, highly sensitive personal information, etc.
+
+## Encryption Keys
+
+Encryption requires keys, but keeping the keys in the same database as the encrypted data doesn't make any sense, it would be like leaving a key in a door lock, a door lock only makes sense when the lock and key can be separated. So similarly, the encryption keys in Supabse are kept separate from the database.
+
+Supabase column encryption and the Vault both use a low level Postgres extension library called [pgsodium](https://github.com/michelp/pgsodium/). This library in turn wraps a very popular encryption library called [libsodium](https://doc.libsodium.org/). These libraries provide functionaly for doing something called [Key Derivation](https://libsodium.gitbook.io/doc/key_derivation). Supabase uses key derivation to *derive* the encryption keys used by column encryption. These keys are derived from a *Root Key* that is stored by Supabase, outside the database. If you need to migrate encrypted data from one system to another, you must ensure that this root key is copied over as well. There is a [REST API for getting the root key for a project](https://supabase.com/docs/reference/api/gets-projects-pgsodium-config).
## Encrypting columns
@@ -23,15 +41,19 @@ Once you've created an encrypted column, you can insert data into the table like

+Note that, as mentioned above, indexing an encrypted column serves no purpose and has a detrimental effect on performance. Indexing encrypted values is not useful since the index needs to store the unencrypted value to be usable, and that would defeat the purpose of storing encrypted data. Do not create indexes on encrypted columns.
+
## Decrypting data
Decrypted data is accessed using a special view that is automatically created after adding an encrypted column to a table. This view decrypts the data row-by-row as you access it. By default, this view is called `decrypted_`. In the example below, the decryption view for the `profiles` table is called `decrypted_profiles`. Notice there is a new column in the view called `decrypted_emails` that contains the decrypted email value.

+As mentioned above, accessing decrypted data is slower than accessing unencrypted data. Any row you query from this view will go through a decryption function, which takes some time and can be a significant performance pentalty if your query loads lots of rows. It's always advisable to look up rows by some indexed unencrypted key first, like a primary key, so that only one row is decrypted at a time.
+
## Using an Encrypted Table
-Now that you have TCE setup for a table, it's easy to use by simply inserting data into the table, and querying that data by looking at its generated view. The view is named `decrypted_` and by default is in the same schema as your table:
+Now that you have column encryption setup for a table, it's easy to use by simply inserting data into the table, and querying that data by looking at its generated view. The view is named `decrypted_` and by default is in the same schema as your table:
```sql
insert into secrets
@@ -67,6 +89,22 @@ nonce | \x300a14aa721184ff7cf0f6bf088da267
Notice how there is a new column called `decrypted_secret`. This column is not stored in database or on disk at all, it is generated “on-the-fly” as you select from the view. Database dumps do not contain this information, only the view itself, and most importantly, **raw decryption keys are never stored**.
+## Granting API Access to encrypted columns
+
+When you create an encrypted column in the `public` database schema, then that column and the decryption view that is created for it are given *public access via the PostgREST API*. In general it is not recommended to encrypt columns in the public schema, as this adds some additional security considerations that you need to think about, but it is still possible and useful in some cases depending on your level of security comfort. Only you can decide the risks and rewards of making decrypted data available to public API access. It is very strongly recommended that you must protect your public encrypted columns with a Row Level Security (RLS) Policy.
+
+Even though objects created in the `public` schema default to public access, There is an additional layer of security with pgsodium that must be enabled in order for decryption to work with the PostgREST API. The permissions necessary to call pgsodium functions must be granted to one of the API role that is accessing the public objects.
+
+There are three roles available for API access with Supabase, The `anon` role represents unauthenticated anonymous users and should *never* be granted access to pgsodium, you do so at your own risk. The `service_role` which is meant to be used by other services in your system, and whose token should never be exposed publicly, and the `authenticated` role which represents authenticated users who present a valid JWT token and are identified by the system as a known user.
+
+By default, only the `service_user` role is granted access to the column encryption functions. If you wish to make encrypted columns available to your authenticated users, then you must run `GRANT pgsodium_keyiduser TO authenticated;` from the Supabase console or logged in as the `postgres` role. This table shows the default permission settings for API roles accessing the pgsodium encryption functions:
+
+|Role | pgsodium_keyiduser | pgsodium_keymaker |
+|---|---|---|
+| anon | X | X |
+| authenticated | X | X |
+| service_role | Y | X |
+
## How Key Derivation Works
The current state-of-the-art in encryption libraries is [libsodium](https://doc.libsodium.org/).
From 3f0a3dbad604cc57767720ee6bc965410bd0dce6 Mon Sep 17 00:00:00 2001
From: Rodrigo Mansueli Nunes
Date: Thu, 10 Aug 2023 11:25:34 -0300
Subject: [PATCH 06/58] Prettier + typo fix
---
.../guides/database/column-encryption.mdx | 26 +++++++++----------
1 file changed, 13 insertions(+), 13 deletions(-)
diff --git a/apps/docs/pages/guides/database/column-encryption.mdx b/apps/docs/pages/guides/database/column-encryption.mdx
index 9746544ad09..b3873f253f6 100644
--- a/apps/docs/pages/guides/database/column-encryption.mdx
+++ b/apps/docs/pages/guides/database/column-encryption.mdx
@@ -23,13 +23,13 @@ Column Encryption comes with tradeoffs that need to be considered before using i
- While you can encrypt multiple columns in the same table, each column must go through a full encryption cycle, so two columns will take twice the time as one, three columns three time as long, and so on. It is usually better to break up large tables into smaller tables with at most one or two encrypted columns, and associated them with [foreign keys](https://www.postgresql.org/docs/current/tutorial-fk.html) that can be used to JOIN them when necessary.
-In general, it is a bad idea to over-use column encryption for mundane data or data that you need to search against such as names, user or account types, addresses, country codes, etc. Column encryption is intended to be used for very sensitive data that would cause serious issues if it were to leak, such as API keys, payment keys, highly sensitive personal information, etc.
+In general, it is a bad idea to over-use column encryption for mundane data or data that you need to search against such as names, user or account types, addresses, country codes, etc. Column encryption is intended to be used for very sensitive data that would cause serious issues if it were to leak, such as API keys, payment keys, highly sensitive personal information, etc.
## Encryption Keys
Encryption requires keys, but keeping the keys in the same database as the encrypted data doesn't make any sense, it would be like leaving a key in a door lock, a door lock only makes sense when the lock and key can be separated. So similarly, the encryption keys in Supabse are kept separate from the database.
-Supabase column encryption and the Vault both use a low level Postgres extension library called [pgsodium](https://github.com/michelp/pgsodium/). This library in turn wraps a very popular encryption library called [libsodium](https://doc.libsodium.org/). These libraries provide functionaly for doing something called [Key Derivation](https://libsodium.gitbook.io/doc/key_derivation). Supabase uses key derivation to *derive* the encryption keys used by column encryption. These keys are derived from a *Root Key* that is stored by Supabase, outside the database. If you need to migrate encrypted data from one system to another, you must ensure that this root key is copied over as well. There is a [REST API for getting the root key for a project](https://supabase.com/docs/reference/api/gets-projects-pgsodium-config).
+Supabase column encryption and the Vault both use a low level Postgres extension library called [pgsodium](https://github.com/michelp/pgsodium/). This library in turn wraps a very popular encryption library called [libsodium](https://doc.libsodium.org/). These libraries provide functionaly for doing something called [Key Derivation](https://libsodium.gitbook.io/doc/key_derivation). Supabase uses key derivation to _derive_ the encryption keys used by column encryption. These keys are derived from a _Root Key_ that is stored by Supabase, outside the database. If you need to migrate encrypted data from one system to another, you must ensure that this root key is copied over as well. There is a [REST API for getting the root key for a project](https://supabase.com/docs/reference/api/gets-projects-pgsodium-config).
## Encrypting columns
@@ -41,7 +41,7 @@ Once you've created an encrypted column, you can insert data into the table like

-Note that, as mentioned above, indexing an encrypted column serves no purpose and has a detrimental effect on performance. Indexing encrypted values is not useful since the index needs to store the unencrypted value to be usable, and that would defeat the purpose of storing encrypted data. Do not create indexes on encrypted columns.
+Note that, as mentioned above, indexing an encrypted column serves no purpose and has a detrimental effect on performance. Indexing encrypted values is not useful since the index needs to store the unencrypted value to be usable, and that would defeat the purpose of storing encrypted data. Do not create indexes on encrypted columns.
## Decrypting data
@@ -49,7 +49,7 @@ Decrypted data is accessed using a special view that is automatically created af

-As mentioned above, accessing decrypted data is slower than accessing unencrypted data. Any row you query from this view will go through a decryption function, which takes some time and can be a significant performance pentalty if your query loads lots of rows. It's always advisable to look up rows by some indexed unencrypted key first, like a primary key, so that only one row is decrypted at a time.
+As mentioned above, accessing decrypted data is slower than accessing unencrypted data. Any row you query from this view will go through a decryption function, which takes some time and can be a significant performance pentalty if your query loads lots of rows. It's always advisable to look up rows by some indexed unencrypted key first, like a primary key, so that only one row is decrypted at a time.
## Using an Encrypted Table
@@ -91,19 +91,19 @@ Notice how there is a new column called `decrypted_secret`. This column is not s
## Granting API Access to encrypted columns
-When you create an encrypted column in the `public` database schema, then that column and the decryption view that is created for it are given *public access via the PostgREST API*. In general it is not recommended to encrypt columns in the public schema, as this adds some additional security considerations that you need to think about, but it is still possible and useful in some cases depending on your level of security comfort. Only you can decide the risks and rewards of making decrypted data available to public API access. It is very strongly recommended that you must protect your public encrypted columns with a Row Level Security (RLS) Policy.
+When you create an encrypted column in the `public` database schema, then that column and the decryption view that is created for it are given _public access via the PostgREST API_. In general it is not recommended to encrypt columns in the public schema, as this adds some additional security considerations that you need to think about, but it is still possible and useful in some cases depending on your level of security comfort. Only you can decide the risks and rewards of making decrypted data available to public API access. It is very strongly recommended that you must protect your public encrypted columns with a Row Level Security (RLS) Policy.
-Even though objects created in the `public` schema default to public access, There is an additional layer of security with pgsodium that must be enabled in order for decryption to work with the PostgREST API. The permissions necessary to call pgsodium functions must be granted to one of the API role that is accessing the public objects.
+Even though objects created in the `public` schema default to public access, There is an additional layer of security with pgsodium that must be enabled in order for decryption to work with the PostgREST API. The permissions necessary to call pgsodium functions must be granted to one of the API role that is accessing the public objects.
-There are three roles available for API access with Supabase, The `anon` role represents unauthenticated anonymous users and should *never* be granted access to pgsodium, you do so at your own risk. The `service_role` which is meant to be used by other services in your system, and whose token should never be exposed publicly, and the `authenticated` role which represents authenticated users who present a valid JWT token and are identified by the system as a known user.
+There are three roles available for API access with Supabase, The `anon` role represents unauthenticated anonymous users and should _never_ be granted access to pgsodium, you do so at your own risk. The `service_role` which is meant to be used by other services in your system, and whose token should never be exposed publicly, and the `authenticated` role which represents authenticated users who present a valid JWT token and are identified by the system as a known user.
-By default, only the `service_user` role is granted access to the column encryption functions. If you wish to make encrypted columns available to your authenticated users, then you must run `GRANT pgsodium_keyiduser TO authenticated;` from the Supabase console or logged in as the `postgres` role. This table shows the default permission settings for API roles accessing the pgsodium encryption functions:
+By default, only the `service_user` role is granted access to the column encryption functions. If you wish to make encrypted columns available to your authenticated users, then you must run `GRANT pgsodium_keyiduser TO authenticated;` from the Supabase console or logged in as the `postgres` role. This table shows the default permission settings for API roles accessing the pgsodium encryption functions:
-|Role | pgsodium_keyiduser | pgsodium_keymaker |
-|---|---|---|
-| anon | X | X |
-| authenticated | X | X |
-| service_role | Y | X |
+| Role | pgsodium_keyiduser | pgsodium_keymaker |
+| ------------- | ------------------ | ----------------- |
+| anon | X | X |
+| authenticated | X | X |
+| service_role | Y | X |
## How Key Derivation Works
From 70f2e46040b959bdfdf0dac40783bd57d65ba531 Mon Sep 17 00:00:00 2001
From: Rodrigo Mansueli Nunes
Date: Thu, 10 Aug 2023 11:27:40 -0300
Subject: [PATCH 07/58] Update column-encryption.mdx
---
apps/docs/pages/guides/database/column-encryption.mdx | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/apps/docs/pages/guides/database/column-encryption.mdx b/apps/docs/pages/guides/database/column-encryption.mdx
index b3873f253f6..30b803b7572 100644
--- a/apps/docs/pages/guides/database/column-encryption.mdx
+++ b/apps/docs/pages/guides/database/column-encryption.mdx
@@ -29,7 +29,7 @@ In general, it is a bad idea to over-use column encryption for mundane data or d
Encryption requires keys, but keeping the keys in the same database as the encrypted data doesn't make any sense, it would be like leaving a key in a door lock, a door lock only makes sense when the lock and key can be separated. So similarly, the encryption keys in Supabse are kept separate from the database.
-Supabase column encryption and the Vault both use a low level Postgres extension library called [pgsodium](https://github.com/michelp/pgsodium/). This library in turn wraps a very popular encryption library called [libsodium](https://doc.libsodium.org/). These libraries provide functionaly for doing something called [Key Derivation](https://libsodium.gitbook.io/doc/key_derivation). Supabase uses key derivation to _derive_ the encryption keys used by column encryption. These keys are derived from a _Root Key_ that is stored by Supabase, outside the database. If you need to migrate encrypted data from one system to another, you must ensure that this root key is copied over as well. There is a [REST API for getting the root key for a project](https://supabase.com/docs/reference/api/gets-projects-pgsodium-config).
+Supabase column encryption and the Vault both use a low level Postgres extension library called [pgsodium](https://github.com/michelp/pgsodium/). This library in turn wraps a very popular encryption library called [libsodium](https://doc.libsodium.org/). These libraries provide functionally for doing something called [Key Derivation](https://libsodium.gitbook.io/doc/key_derivation). Supabase uses key derivation to _derive_ the encryption keys used by column encryption. These keys are derived from a _Root Key_ that is stored by Supabase, outside the database. If you need to migrate encrypted data from one system to another, you must ensure that this root key is copied over as well. There is a [REST API for getting the root key for a project](https://supabase.com/docs/reference/api/gets-projects-pgsodium-config).
## Encrypting columns
From 9bebecc2b09efa4c93e32bc83f35ce81526456ec Mon Sep 17 00:00:00 2001
From: Michel Pelletier
Date: Thu, 10 Aug 2023 09:42:57 -0700
Subject: [PATCH 08/58] Update
apps/docs/pages/guides/database/column-encryption.mdx
Co-authored-by: Oliver Rice
---
apps/docs/pages/guides/database/column-encryption.mdx | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/apps/docs/pages/guides/database/column-encryption.mdx b/apps/docs/pages/guides/database/column-encryption.mdx
index 30b803b7572..2ed12615f4a 100644
--- a/apps/docs/pages/guides/database/column-encryption.mdx
+++ b/apps/docs/pages/guides/database/column-encryption.mdx
@@ -9,7 +9,7 @@ export const meta = {
video: 'https://www.youtube.com/v/J9mTPY8rIXE',
}
-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 intended to act as a secure global secrets management for your project.
+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.
From 697d48ac1beab96574d255b0432470f2cc4f0742 Mon Sep 17 00:00:00 2001
From: Michel Pelletier
Date: Thu, 10 Aug 2023 09:45:31 -0700
Subject: [PATCH 09/58] Update
apps/docs/pages/guides/database/column-encryption.mdx
Co-authored-by: Oliver Rice
---
apps/docs/pages/guides/database/column-encryption.mdx | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/apps/docs/pages/guides/database/column-encryption.mdx b/apps/docs/pages/guides/database/column-encryption.mdx
index 2ed12615f4a..cb944f48d6d 100644
--- a/apps/docs/pages/guides/database/column-encryption.mdx
+++ b/apps/docs/pages/guides/database/column-encryption.mdx
@@ -17,7 +17,7 @@ Column Encryption comes with tradeoffs that need to be considered before using i
- Encryption and decryption both take time, inserting and selecting encrypted data takes more time than a "plain" column of data. Queries that must load a lot of rows with encrypted columns will be slower than those that are not encrypted.
- - Encrypted columns should never be indexed. This is because the index must store the unencrypted value of a column to be useful, which would defeat the purpose of storing values encrypted. To look up an encrypted column, you must first look up its row by some other unencrypted column, like a primary key.
+ - Encrypted columns should never be indexed. This is because the index will store the encrypted value of a column, which would not be useful. To look up an encrypted column, you must first look up its row by some other unencrypted column, like a primary key.
- Encrypted columns can be queried in a `WHERE` clause, but this can also have some negative performance consequences, since the value must be decrypted in order to matched to any `WHERE` qualifiers. For small result sets this is not a big deal, but broad queries that match many rows will have to be scanned and each row decrypted in order to check against the `WHERE` clause. Worst case is the entire table must be scanned and decrypted to check against a `WHERE`.
From 35552848e08afac97c3a8171180bbce6f1b14f4c Mon Sep 17 00:00:00 2001
From: Michel Pelletier
Date: Thu, 10 Aug 2023 09:46:12 -0700
Subject: [PATCH 10/58] Update
apps/docs/pages/guides/database/column-encryption.mdx
Co-authored-by: Oliver Rice
---
apps/docs/pages/guides/database/column-encryption.mdx | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/apps/docs/pages/guides/database/column-encryption.mdx b/apps/docs/pages/guides/database/column-encryption.mdx
index cb944f48d6d..fc817569f90 100644
--- a/apps/docs/pages/guides/database/column-encryption.mdx
+++ b/apps/docs/pages/guides/database/column-encryption.mdx
@@ -19,7 +19,7 @@ Column Encryption comes with tradeoffs that need to be considered before using i
- Encrypted columns should never be indexed. This is because the index will store the encrypted value of a column, which would not be useful. To look up an encrypted column, you must first look up its row by some other unencrypted column, like a primary key.
- - Encrypted columns can be queried in a `WHERE` clause, but this can also have some negative performance consequences, since the value must be decrypted in order to matched to any `WHERE` qualifiers. For small result sets this is not a big deal, but broad queries that match many rows will have to be scanned and each row decrypted in order to check against the `WHERE` clause. Worst case is the entire table must be scanned and decrypted to check against a `WHERE`.
+ - Encrypted columns can be queried in a `WHERE` clause, but this can also have some negative performance consequences, since the value must be decrypted in order to matched to any `WHERE` qualifiers. For small result sets the impact is small, but queries that match many rows will cause each row to be decrypted in order to check against the `WHERE` clause. In the worst case, the entire table must be scanned and decrypted to check against a `WHERE` clause.
- While you can encrypt multiple columns in the same table, each column must go through a full encryption cycle, so two columns will take twice the time as one, three columns three time as long, and so on. It is usually better to break up large tables into smaller tables with at most one or two encrypted columns, and associated them with [foreign keys](https://www.postgresql.org/docs/current/tutorial-fk.html) that can be used to JOIN them when necessary.
From b7e1d97e8a78c9375a4c18daaf143e072d5f4e1c Mon Sep 17 00:00:00 2001
From: Michel Pelletier
Date: Thu, 10 Aug 2023 09:46:46 -0700
Subject: [PATCH 11/58] Update
apps/docs/pages/guides/database/column-encryption.mdx
Co-authored-by: Oliver Rice
---
apps/docs/pages/guides/database/column-encryption.mdx | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/apps/docs/pages/guides/database/column-encryption.mdx b/apps/docs/pages/guides/database/column-encryption.mdx
index fc817569f90..fc2ac5c8480 100644
--- a/apps/docs/pages/guides/database/column-encryption.mdx
+++ b/apps/docs/pages/guides/database/column-encryption.mdx
@@ -27,7 +27,7 @@ In general, it is a bad idea to over-use column encryption for mundane data or d
## Encryption Keys
-Encryption requires keys, but keeping the keys in the same database as the encrypted data doesn't make any sense, it would be like leaving a key in a door lock, a door lock only makes sense when the lock and key can be separated. So similarly, the encryption keys in Supabse are kept separate from the database.
+Encryption requires keys. Keeping the keys in the same database as the encrypted data would be unsafe. It would be like leaving a key in a door lock. For that reason, encryption keys are kept separate from the database.
Supabase column encryption and the Vault both use a low level Postgres extension library called [pgsodium](https://github.com/michelp/pgsodium/). This library in turn wraps a very popular encryption library called [libsodium](https://doc.libsodium.org/). These libraries provide functionally for doing something called [Key Derivation](https://libsodium.gitbook.io/doc/key_derivation). Supabase uses key derivation to _derive_ the encryption keys used by column encryption. These keys are derived from a _Root Key_ that is stored by Supabase, outside the database. If you need to migrate encrypted data from one system to another, you must ensure that this root key is copied over as well. There is a [REST API for getting the root key for a project](https://supabase.com/docs/reference/api/gets-projects-pgsodium-config).
From d62a7fb9c4d6ff047679825f5fa86f28edf654e9 Mon Sep 17 00:00:00 2001
From: Michel Pelletier
Date: Thu, 10 Aug 2023 09:47:02 -0700
Subject: [PATCH 12/58] Update
apps/docs/pages/guides/database/column-encryption.mdx
Co-authored-by: Oliver Rice
---
apps/docs/pages/guides/database/column-encryption.mdx | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/apps/docs/pages/guides/database/column-encryption.mdx b/apps/docs/pages/guides/database/column-encryption.mdx
index fc2ac5c8480..938ed2ff736 100644
--- a/apps/docs/pages/guides/database/column-encryption.mdx
+++ b/apps/docs/pages/guides/database/column-encryption.mdx
@@ -49,7 +49,7 @@ Decrypted data is accessed using a special view that is automatically created af

-As mentioned above, accessing decrypted data is slower than accessing unencrypted data. Any row you query from this view will go through a decryption function, which takes some time and can be a significant performance pentalty if your query loads lots of rows. It's always advisable to look up rows by some indexed unencrypted key first, like a primary key, so that only one row is decrypted at a time.
+Accessing decrypted data is slower than accessing unencrypted data. Any row you query from this view will go through a decryption function, which takes some time and can be a significant performance pentalty if your query loads lots of rows. It's always advisable to look up rows by some indexed unencrypted key first, like a primary key, so that only one row is decrypted at a time.
## Using an Encrypted Table
From 307fc3ad0a574ed602375f7aad4760832e63c80b Mon Sep 17 00:00:00 2001
From: Michel Pelletier
Date: Thu, 10 Aug 2023 09:47:28 -0700
Subject: [PATCH 13/58] Update
apps/docs/pages/guides/database/column-encryption.mdx
Co-authored-by: Oliver Rice
---
apps/docs/pages/guides/database/column-encryption.mdx | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/apps/docs/pages/guides/database/column-encryption.mdx b/apps/docs/pages/guides/database/column-encryption.mdx
index 938ed2ff736..6f4b3a58dc1 100644
--- a/apps/docs/pages/guides/database/column-encryption.mdx
+++ b/apps/docs/pages/guides/database/column-encryption.mdx
@@ -41,7 +41,7 @@ Once you've created an encrypted column, you can insert data into the table like

-Note that, as mentioned above, indexing an encrypted column serves no purpose and has a detrimental effect on performance. Indexing encrypted values is not useful since the index needs to store the unencrypted value to be usable, and that would defeat the purpose of storing encrypted data. Do not create indexes on encrypted columns.
+As mentioned above, indexing an encrypted column serves no purpose and has a detrimental effect on performance. Indexing encrypted values is not useful since the index needs to store the unencrypted value to be usable, and that would defeat the purpose of storing encrypted data. Do not create indexes on encrypted columns.
## Decrypting data
From 4734ac6a52a19ae19608fdc6e9b9963c0435cbdb Mon Sep 17 00:00:00 2001
From: Michel Pelletier
Date: Thu, 10 Aug 2023 09:47:44 -0700
Subject: [PATCH 14/58] Update
apps/docs/pages/guides/database/column-encryption.mdx
Co-authored-by: Oliver Rice
---
apps/docs/pages/guides/database/column-encryption.mdx | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/apps/docs/pages/guides/database/column-encryption.mdx b/apps/docs/pages/guides/database/column-encryption.mdx
index 6f4b3a58dc1..d36b9685473 100644
--- a/apps/docs/pages/guides/database/column-encryption.mdx
+++ b/apps/docs/pages/guides/database/column-encryption.mdx
@@ -91,7 +91,7 @@ Notice how there is a new column called `decrypted_secret`. This column is not s
## Granting API Access to encrypted columns
-When you create an encrypted column in the `public` database schema, then that column and the decryption view that is created for it are given _public access via the PostgREST API_. In general it is not recommended to encrypt columns in the public schema, as this adds some additional security considerations that you need to think about, but it is still possible and useful in some cases depending on your level of security comfort. Only you can decide the risks and rewards of making decrypted data available to public API access. It is very strongly recommended that you must protect your public encrypted columns with a Row Level Security (RLS) Policy.
+When you create an encrypted column in the `public` database schema, then that column and the decryption view that is created for it are given _public access via the PostgREST API_. In general it is not recommended to encrypt columns in the public schema, as this adds some additional security considerations that you need to think about, but it is still possible and useful in some cases depending on your level of security comfort. Only you can decide the risks and rewards of making decrypted data available to public API access. It is very strongly recommended that you must protect your public encrypted columns with a [Row Level Security (RLS) Policy](docs/guides/auth/row-level-security).
Even though objects created in the `public` schema default to public access, There is an additional layer of security with pgsodium that must be enabled in order for decryption to work with the PostgREST API. The permissions necessary to call pgsodium functions must be granted to one of the API role that is accessing the public objects.
From 1292cd29dc20179475c97e6a77378835312076c2 Mon Sep 17 00:00:00 2001
From: Michel Pelletier
Date: Thu, 10 Aug 2023 09:48:47 -0700
Subject: [PATCH 15/58] Update
apps/docs/pages/guides/database/column-encryption.mdx
Co-authored-by: Oliver Rice
---
apps/docs/pages/guides/database/column-encryption.mdx | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/apps/docs/pages/guides/database/column-encryption.mdx b/apps/docs/pages/guides/database/column-encryption.mdx
index d36b9685473..1734d88a6af 100644
--- a/apps/docs/pages/guides/database/column-encryption.mdx
+++ b/apps/docs/pages/guides/database/column-encryption.mdx
@@ -95,7 +95,7 @@ When you create an encrypted column in the `public` database schema, then that c
Even though objects created in the `public` schema default to public access, There is an additional layer of security with pgsodium that must be enabled in order for decryption to work with the PostgREST API. The permissions necessary to call pgsodium functions must be granted to one of the API role that is accessing the public objects.
-There are three roles available for API access with Supabase, The `anon` role represents unauthenticated anonymous users and should _never_ be granted access to pgsodium, you do so at your own risk. The `service_role` which is meant to be used by other services in your system, and whose token should never be exposed publicly, and the `authenticated` role which represents authenticated users who present a valid JWT token and are identified by the system as a known user.
+There are three roles available for API access with Supabase, The `anon` role represents unauthenticated anonymous users and should _never_ be granted access to pgsodium. The `service_role` which is meant to be used by other services in your system, and whose token should never be exposed publicly, and the `authenticated` role which represents authenticated users who present a valid JWT token and are identified by the system as a known user.
By default, only the `service_user` role is granted access to the column encryption functions. If you wish to make encrypted columns available to your authenticated users, then you must run `GRANT pgsodium_keyiduser TO authenticated;` from the Supabase console or logged in as the `postgres` role. This table shows the default permission settings for API roles accessing the pgsodium encryption functions:
From d8e07497c635be5e489f910b9d00cba72bb8222d Mon Sep 17 00:00:00 2001
From: egor-romanov
Date: Fri, 11 Aug 2023 01:31:37 +0300
Subject: [PATCH 16/58] add link to support form
---
apps/docs/pages/guides/realtime/postgres-changes.mdx | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/apps/docs/pages/guides/realtime/postgres-changes.mdx b/apps/docs/pages/guides/realtime/postgres-changes.mdx
index 9194b347419..ebf20553d5a 100644
--- a/apps/docs/pages/guides/realtime/postgres-changes.mdx
+++ b/apps/docs/pages/guides/realtime/postgres-changes.mdx
@@ -552,10 +552,12 @@ From our testing and observation of the performance of the polling query, we hav
| large and above | ✅ | ✅ | 1,000 | 1 | 1,000 | 431 |
| large and above | ✅ | ✅ | 5,000 | 0.2 (1 in 5 seconds) | 1,000 | 702 |
-If you want to use Realtime's Postgres Changes feature you should be aware of these limitations. And if you are planning to use this feature at scale, you should consider using separate table without RLS and filters for the purpose of streaming changes to subscribed clients. Another option is to use it on the server side only and restream the changes to your clients using a Realtime Broadcast because it does not have these limitations.
+If you want to use Realtime's Postgres Changes feature you should be aware of these limitations. And if you are planning to use this feature at scale, you should consider using separate table without RLS and filters for the purpose of streaming changes to subscribed clients. Another option is to use it on the server side only and restream the changes to your clients using a Realtime Broadcast because it does not have these limitations. And don't forget to run your own benchmarks to make sure that the performance is acceptable for your use case.
We have ideas on how to improve Realtime's Postgres Changes in the future. Follow Supabase to stay up to date with the latest news and updates on this feature.
+And if you are uncertain about the performance of your use case, please reach out using [Support Form](https://supabase.com/dashboard/support/new) and we will be happy to help you. We have a whole team of engineers that can advise you the solution that will work best for your usage scenario.
+
## More Realtime Quickstarts
- [Broadcast Quickstart](/docs/guides/realtime/broadcast)
From e3c5a5c43a25e9420506bbbf9258bbe5a1d236f7 Mon Sep 17 00:00:00 2001
From: Chase Granberry
Date: Thu, 10 Aug 2023 17:07:03 -0700
Subject: [PATCH 17/58] docs: init some Supavisor docs
---
.../guides/database/connecting-to-postgres.mdx | 14 ++++++++++++++
1 file changed, 14 insertions(+)
diff --git a/apps/docs/pages/guides/database/connecting-to-postgres.mdx b/apps/docs/pages/guides/database/connecting-to-postgres.mdx
index 3b6ba626626..c338d4fb118 100644
--- a/apps/docs/pages/guides/database/connecting-to-postgres.mdx
+++ b/apps/docs/pages/guides/database/connecting-to-postgres.mdx
@@ -51,6 +51,20 @@ Every Supabase project comes with PgBouncer for connection pooling. A connection
/>
+## Supavisor
+
+Supavisor is a new connection pooler by Supabase. It can provide a more scalable connection pool than PgBouncer, and runs on a highly available cluster not on your database.
+
+This can free up some CPU cycles for your database to use for queries. It also makes connecting to Postgres in a serverless environment much easier.
+
+Using Supavisor for your project should be no different than using PgBouncer.
+
+To use Supavisor [contact support](https://supabase.com/dashboard/support/new) and we will expose the connection string in your project dashboard.
+
+Supavisor is open source and compatible with any Postgres deployment.
+
+Check out [the Github repository](https://github.com/supabase/supavisor).
+
## Choosing a connection method
- The Serverless APIs provide programmatic access and have [built-in connection pooling](https://postgrest.org/en/stable/references/connection_pool.html). You can use these for all browser and application interactions. We recommend using these wherever possible.
From 38b1681d3a12d9deca35c6b52de72cf8f3729e97 Mon Sep 17 00:00:00 2001
From: Joshen Lim
Date: Fri, 11 Aug 2023 11:14:43 +0800
Subject: [PATCH 18/58] Hide fields in pg bouncer config if supavisor enabled
---
.../Settings/Database/ConnectionPooling.tsx | 20 +++++++++++++------
1 file changed, 14 insertions(+), 6 deletions(-)
diff --git a/studio/components/interfaces/Settings/Database/ConnectionPooling.tsx b/studio/components/interfaces/Settings/Database/ConnectionPooling.tsx
index c477c4e46ae..69eab110073 100644
--- a/studio/components/interfaces/Settings/Database/ConnectionPooling.tsx
+++ b/studio/components/interfaces/Settings/Database/ConnectionPooling.tsx
@@ -34,6 +34,7 @@ const ConnectionPooling = () => {
'ignore_startup_parameters',
'pool_mode',
'pgbouncer_enabled',
+ 'supavisor_enabled',
'max_client_conn',
'connectionString',
]
@@ -109,6 +110,7 @@ interface ConfigProps {
pgbouncer_enabled: boolean
max_client_conn: number
connectionString: string
+ supavisor_enabled: boolean
}
connectionInfo: {
db_host: string
@@ -127,6 +129,8 @@ export const PgbouncerConfig = ({ projectRef, bouncerInfo, connectionInfo }: Con
'projects'
)
+ console.log({ bouncerInfo })
+
const [updates, setUpdates] = useState({
pool_mode: bouncerInfo.pool_mode || 'transaction',
default_pool_size: bouncerInfo.default_pool_size || undefined,
@@ -232,12 +236,16 @@ export const PgbouncerConfig = ({ projectRef, bouncerInfo, connectionInfo }: Con
.
-
-
-
-
-
-
+ {!bouncerInfo.supavisor_enabled && (
+ <>
+
+
+
+
+
+
+ >
+ )}
>
)}
From 91f8673630879a3e38ffc385dbbc904364968aee Mon Sep 17 00:00:00 2001
From: Joshen Lim
Date: Fri, 11 Aug 2023 11:15:05 +0800
Subject: [PATCH 19/58] remove console
---
.../interfaces/Settings/Database/ConnectionPooling.tsx | 2 --
1 file changed, 2 deletions(-)
diff --git a/studio/components/interfaces/Settings/Database/ConnectionPooling.tsx b/studio/components/interfaces/Settings/Database/ConnectionPooling.tsx
index 69eab110073..64482db4edc 100644
--- a/studio/components/interfaces/Settings/Database/ConnectionPooling.tsx
+++ b/studio/components/interfaces/Settings/Database/ConnectionPooling.tsx
@@ -129,8 +129,6 @@ export const PgbouncerConfig = ({ projectRef, bouncerInfo, connectionInfo }: Con
'projects'
)
- console.log({ bouncerInfo })
-
const [updates, setUpdates] = useState({
pool_mode: bouncerInfo.pool_mode || 'transaction',
default_pool_size: bouncerInfo.default_pool_size || undefined,
From 9a759d1071cfd53c14918e2a1826cecb6bd60ab8 Mon Sep 17 00:00:00 2001
From: Joshen Lim
Date: Fri, 11 Aug 2023 11:18:31 +0800
Subject: [PATCH 20/58] Temp check supavisor_enabled from connectionString
---
.../interfaces/Settings/Database/ConnectionPooling.tsx | 8 +++++++-
1 file changed, 7 insertions(+), 1 deletion(-)
diff --git a/studio/components/interfaces/Settings/Database/ConnectionPooling.tsx b/studio/components/interfaces/Settings/Database/ConnectionPooling.tsx
index 64482db4edc..a3e1317f30e 100644
--- a/studio/components/interfaces/Settings/Database/ConnectionPooling.tsx
+++ b/studio/components/interfaces/Settings/Database/ConnectionPooling.tsx
@@ -89,7 +89,13 @@ const ConnectionPooling = () => {
) : (
)}
From d541b224e5e4466e02a4b8a49dd723fe7e8c089e Mon Sep 17 00:00:00 2001
From: Div Arora
Date: Fri, 11 Aug 2023 13:00:52 +0800
Subject: [PATCH 21/58] chore: update network restriction limitations re:
supavisor
---
apps/docs/pages/guides/platform/network-restrictions.mdx | 1 +
1 file changed, 1 insertion(+)
diff --git a/apps/docs/pages/guides/platform/network-restrictions.mdx b/apps/docs/pages/guides/platform/network-restrictions.mdx
index 8d7fe089fcb..cb86b8008fd 100644
--- a/apps/docs/pages/guides/platform/network-restrictions.mdx
+++ b/apps/docs/pages/guides/platform/network-restrictions.mdx
@@ -68,6 +68,7 @@ Restrictions applied successfully: true
- The current iteration of Network Restrictions applies to connections to Postgres and PgBouncer and doesn't currently apply to APIs offered over HTTPS (e.g., PostgREST, Storage, and Auth).
- Network Restrictions should not be used if you need to connect to your Postgres database using Edge Functions.
+- [Supavisor](https://github.com/supabase/supavisor/) does not currently support Network Restrictions.
export const Page = ({ children }) =>
From f74241c38967a91832f9102fe07b05bfde56c41e Mon Sep 17 00:00:00 2001
From: delgado3d <27228526+delgado3d@users.noreply.github.com>
Date: Fri, 11 Aug 2023 10:52:37 +0530
Subject: [PATCH 22/58] chore: network restrictions limitations for supavisor
in studio
---
.../Database/NetworkRestrictions/AddRestrictionModal.tsx | 4 ++--
.../Database/NetworkRestrictions/DisallowAllModal.tsx | 4 ++--
2 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/studio/components/interfaces/Settings/Database/NetworkRestrictions/AddRestrictionModal.tsx b/studio/components/interfaces/Settings/Database/NetworkRestrictions/AddRestrictionModal.tsx
index 383ddf4bf1a..ae3b84e5135 100644
--- a/studio/components/interfaces/Settings/Database/NetworkRestrictions/AddRestrictionModal.tsx
+++ b/studio/components/interfaces/Settings/Database/NetworkRestrictions/AddRestrictionModal.tsx
@@ -125,8 +125,8 @@ const AddRestrictionModal = ({
your database. Only IPv4 addresses are supported at the moment.
From 46934dc406a1436f809c1b365bde92c90a53bc68 Mon Sep 17 00:00:00 2001
From: Copple <10214025+kiwicopple@users.noreply.github.com>
Date: Fri, 11 Aug 2023 10:20:34 +0200
Subject: [PATCH 25/58] Update
apps/docs/pages/guides/database/connecting-to-postgres.mdx
---
apps/docs/pages/guides/database/connecting-to-postgres.mdx | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/apps/docs/pages/guides/database/connecting-to-postgres.mdx b/apps/docs/pages/guides/database/connecting-to-postgres.mdx
index c338d4fb118..2140019c23b 100644
--- a/apps/docs/pages/guides/database/connecting-to-postgres.mdx
+++ b/apps/docs/pages/guides/database/connecting-to-postgres.mdx
@@ -57,7 +57,7 @@ Supavisor is a new connection pooler by Supabase. It can provide a more scalable
This can free up some CPU cycles for your database to use for queries. It also makes connecting to Postgres in a serverless environment much easier.
-Using Supavisor for your project should be no different than using PgBouncer.
+We're building compatibility with PgBouncer. It won't require any application changes to switch from PgBouncer to Supavisor.
To use Supavisor [contact support](https://supabase.com/dashboard/support/new) and we will expose the connection string in your project dashboard.
From 0353ff8b59513d7e081a4865bd66875838b9f1e8 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Ramiro=20Nu=C3=B1ez=20Dosio?=
Date: Fri, 11 Aug 2023 11:01:41 +0100
Subject: [PATCH 26/58] D5 - Community
---
...-11-launch-week-8-community-highlights.mdx | 111 ++++++++++++++++++
1 file changed, 111 insertions(+)
create mode 100644 apps/www/_blog/2023-08-11-launch-week-8-community-highlights.mdx
diff --git a/apps/www/_blog/2023-08-11-launch-week-8-community-highlights.mdx b/apps/www/_blog/2023-08-11-launch-week-8-community-highlights.mdx
new file mode 100644
index 00000000000..3f4c4010c3f
--- /dev/null
+++ b/apps/www/_blog/2023-08-11-launch-week-8-community-highlights.mdx
@@ -0,0 +1,111 @@
+---
+title: 'Launch Week 8 Community Highlights'
+description: WIP.
+launchweek: 8
+tags:
+ - launch-week
+date: '2023-08-11'
+published_at:
+toc_depth: 3
+author: paul_copplestone
+image: WIP
+thumb: WIP
+---
+
+
+## Ecosystem partners
+
+We’ve seen a lot of new partners and big updates in the ecosystem since our last Launch Week. Here are a few of the highlights.
+
+### Integrations Marketplace
+
+We’ve been running our Integrations Marketplace in “stealth mode” for about a year now, and has now grown to [over 60 integrations](https://supabase.com/partners/integrations). In the last couple of months we’ve added amazing products like [N8N](https://supabase.com/partners/integrations/n8n), [Passage by 1 Password](https://supabase.com/partners/integrations/passageidentity), [Refine](https://supabase.com/partners/integrations/refine_dev). This Launch Week we’ve made it easy to [build an integration](https://supabase.com/docs/guides/platform/oauth-apps/build-a-supabase-integration#create-an-oauth-app) using OAuth2 and the Management API in the new [Supabase Integrations Marketplace](https://supabase.com/blog/supabase-integrations-marketplace). We've started with a few partners to help us build and test the OAuth functionality, including [Cloudflare](https://supabase.com/partners/integrations/cloudflare-workers), [Resend](https://supabase.com/partners/integrations/resend), [Snaplet](https://supabase.com/partners/integrations/snaplet), [Trigger.dev](https://supabase.com/partners/integrations/triggerdotdev), [Windmill](https://supabase.com/partners/integrations/vercel), and [Vercel](https://supabase.com/partners/integrations/windmill).
+
+### pgvector
+
+[pgvector](github.com/pgvector/pgvector/) adds vector capabilities to Postgres. We continue to work with the pgvector creator, [Andrew Kane](https://twitter.com/andrewkane), and others contributing to the project. In the past few months we’ve added robust benchmarks to show how to [scale your ivfflat workloads](https://supabase.com/blog/pgvector-performance) and established guidance on the [best models](https://supabase.com/blog/fewer-dimensions-are-better-pgvector) to use with pgvectors. With v0.5.0 coming soon, we’re extremely excited about the improved HNSW index. Performance and recall improvement are looking [significantly better](https://jkatz05.com/post/postgres/pgvector-hnsw-performance/) than the current ivfflat index in pgvector.
+
+### PostgREST
+
+Last month we rolled out support across the platform [PostgREST 11.1](https://supabase.com/blog/postgrest-11-1-release). A huge shoutout to [Steve Chavez](https://twitter.com/_steve_chavez) for his continued support as the primary maintainer of the project. [PostgREST 11.2](https://github.com/PostgREST/postgrest/releases/tag/v11.2.0) was released yesterday, adding [Domain Representations](https://postgrest.org/en/v11.2/references/api/domain_representations.html), and we’ll roll it out to platform soon.
+
+### LlamaIndex
+
+In one of the most community-driven contributions ever, a tweet from [us](https://twitter.com/kiwicopple/status/1664377669935349760?s=20), and a tweet from [LlamaIndex](https://twitter.com/jerryjliu0/status/1664413942045904896), led to a contribution from [a16z](https://twitter.com/stuffyokodraws/status/1664532449815302145?s=20). And a few days later we had a [Supabase Vector Store implementation in LlamaIndex](https://gpt-index.readthedocs.io/en/stable/examples/vector_stores/SupabaseVectorIndexDemo.html).
+
+### Transloadit
+
+The team at Transloadit are commited to building an open protocol for resumable uploads, to make it the standard for file uploads on the internet. We used two of their [tus-node-server](https://github.com/tus/tus-node-server/) for our recent [updates to Storage](https://supabase.com/blog/storage-v3-resumable-uploads), and contributed back a few important changes as a result. **[Check out their post about our collaboration](https://transloadit.com/blog/2023/08/casestudy-supabase/)**
+
+### Mozilla
+
+We are huge fans of Mozilla at Supabase, so it was an honour when chose [Supabase Vector](https://supabase.com/vector) to build AI Help, a ChatGPT-like interface to the most popular developer docs on the internet: **[MDN](https://developer.mozilla.org/en-US/)**. [Learn more in their official announcement](https://developer.mozilla.org/en-US/blog/introducing-ai-help/).
+
+## Framework support
+
+### Next.js Supabase Starter template
+
+We added support for Next.js 13’s App router, including Cookie-based Auth; Nicely styled authentication form with Tailwind CSS; Examples for Client Components, Server Components, Route Handlers, and Server Actions; and - of course - 100% TypeScript. Get started with one simple command:
+
+```bash
+npx create-next-app -e with-supabase
+```
+
+### Nuxt Supabase module
+
+The team at Nuxt [added support](https://twitter.com/_larbish/status/1687044609522778112) for the PKCE Auth Flow in their [Supabase x Nuxt module](https://supabase.nuxtjs.org/), making it even more secure. This module is a simple wrapper around [supabase-js](https://github.com/supabase/supabase-js) to enable usage and integration within Nuxt.
+
+### Tamagui Takeout
+
+The Tamagui team launched [TakeOut](https://tamagui.dev/takeout), a web and mobile starter that takes featuring everything you need to launch - including a nice backend, powered by Supabase.
+
+### PowerSync
+
+The team at PowerSync just dropped [an (extremely attractive) integration](https://docs.powersync.co/integration-guides/supabase-+-powersync) for building offline-first Flutter apps. This uses Postgres’ built-in Publication functionality to track changes, which are then synced to an offline cache.
+
+## State of the community
+
+### Stack Overflow Survey
+![IMAGE GOES HERE]()
+
+This was the first year that Supabase appeared on the Stack Overflow survey for [Databases](https://survey.stackoverflow.co/2023/#most-popular-technologies-database) as the 17th “most used”. As a bonus, Postgres took the #1 spot for the first time, and we hope we can continue to contribute to that trend.
+
+### Community Meetups
+
+![IMAGE GOES HERE]()
+
+Supabase started as a remote company, and almost everything we’ve done so far has been digital. This Launch Week added in-person meetups throughout the world, 100% organized by the community. We had meetups in 5 countries, with hundreds of attendees across the world. It has been a successful experiment, something we’ll keep for next time. Thanks to Fatuma, Isheanesu, Daniel, Philip, and Thor for organizing!
+
+### Modern Full Stack
+
+Probably the most comprehensive Supabase resource on the internet, the team at Modern Full Stack just released a 7 chapter, 21 lesson [course on Supabase](https://modernfullstack.com/course/mfs401). The course includes:
+
+1. **Supabase Foundations**
+2. **Supabase Authentication**
+3. **A Masterclass on Supabase Databases**
+4. **Exploring the Supabase Storage API**
+5. **Supabase Realtime**
+6. **Unleashing Supabase’s Edge Functions**
+7. **Achieving Mastery of Supabase**
+
+[Get started with Modern Full Stack.](https://modernfullstack.com/course/mfs401)
+
+### EggHead: Build a 𝕏witter clone
+
+Our very own (and very talented) [Jon Meyers](https://twitter.com/jonmeyers_io) has released a new EggHead course that steps you through the process of creating a [Twitter clone with Next.js App Router and Supabase](https://egghead.io/courses/build-a-twitter-clone-with-the-next-js-app-router-and-supabase-19bebadb). The course includes:
+
+1. Cookie-based Auth
+2. Generating Typescript definitions from your PostgreSQL schema
+- Tailwind CSS
+- Optimistic UI
+- Realtime subscriptions
+
+[Get started on EggHead.](https://egghead.io/courses/build-a-twitter-clone-with-the-next-js-app-router-and-supabase-19bebadb)
+
+## Contributors
+
+We also want to highlight all the humans who have made meaningful contributions to the Supabase ecosystem since our last Launch Week:
+
+- We’ve continued growing our [community maintainers](https://github.com/orgs/supabase-community/teams), with a particular focus on Mobile. We now have docs for [Swift](https://supabase.com/docs/reference/swift/introduction) and [Kotlin](https://supabase.com/docs/reference/kotlin/introduction).
+- [kamilogorek](https://github.com/kamilogorek) and [adiologydev](https://github.com/adiologydev) for integrating Schema Visualizer into the Studio. And another shoutout to the legend, [Zernonia](https://twitter.com/zernonia), for providing the inspiration for this great new feature!
+- As always, a big shoutout to [Gary](https://github.com/GaryAustin1) and [Olyno](https://github.com/olyno) - official moderators of our [Discord](https://discord.supabase.com/) and overall incredibly helpful people. The community would not be the same without them.
From 7833243fccd7289f8434d4e9be8f7ab5c080003f Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Ramiro=20Nu=C3=B1ez=20Dosio?=
Date: Fri, 11 Aug 2023 11:20:55 +0100
Subject: [PATCH 27/58] Added images.
---
...8-11-launch-week-8-community-highlights.mdx | 13 +++++++------
.../community-highlights-OG.jpg | Bin 0 -> 51826 bytes
.../community-highlights-thumbs.jpg | Bin 0 -> 39957 bytes
.../day-5-community/launch-week-8-meetups.png | Bin 0 -> 427785 bytes
.../day-5-community/stack-overflow-survey.png | Bin 0 -> 172692 bytes
5 files changed, 7 insertions(+), 6 deletions(-)
create mode 100644 apps/www/public/images/blog/launch-week-8/day-5-community/community-highlights-OG.jpg
create mode 100644 apps/www/public/images/blog/launch-week-8/day-5-community/community-highlights-thumbs.jpg
create mode 100644 apps/www/public/images/blog/launch-week-8/day-5-community/launch-week-8-meetups.png
create mode 100644 apps/www/public/images/blog/launch-week-8/day-5-community/stack-overflow-survey.png
diff --git a/apps/www/_blog/2023-08-11-launch-week-8-community-highlights.mdx b/apps/www/_blog/2023-08-11-launch-week-8-community-highlights.mdx
index 3f4c4010c3f..45db730f0f6 100644
--- a/apps/www/_blog/2023-08-11-launch-week-8-community-highlights.mdx
+++ b/apps/www/_blog/2023-08-11-launch-week-8-community-highlights.mdx
@@ -8,8 +8,8 @@ date: '2023-08-11'
published_at:
toc_depth: 3
author: paul_copplestone
-image: WIP
-thumb: WIP
+image: launch-week-8/day-5-community/community-highlights-OG.jpg
+thumb: launch-week-8/day-5-community/community-highlights-thumbs.jpg
---
@@ -35,11 +35,11 @@ In one of the most community-driven contributions ever, a tweet from [us](https:
### Transloadit
-The team at Transloadit are commited to building an open protocol for resumable uploads, to make it the standard for file uploads on the internet. We used two of their [tus-node-server](https://github.com/tus/tus-node-server/) for our recent [updates to Storage](https://supabase.com/blog/storage-v3-resumable-uploads), and contributed back a few important changes as a result. **[Check out their post about our collaboration](https://transloadit.com/blog/2023/08/casestudy-supabase/)**
+The team at Transloadit are committed to building an open protocol for resumable uploads, to make it the standard for file uploads on the internet. We used two of their [tus-node-server](https://github.com/tus/tus-node-server/) for our recent [updates to Storage](https://supabase.com/blog/storage-v3-resumable-uploads), and contributed back a few important changes as a result. **[Check out their post about our collaboration](https://transloadit.com/blog/2023/08/casestudy-supabase/)**
### Mozilla
-We are huge fans of Mozilla at Supabase, so it was an honour when chose [Supabase Vector](https://supabase.com/vector) to build AI Help, a ChatGPT-like interface to the most popular developer docs on the internet: **[MDN](https://developer.mozilla.org/en-US/)**. [Learn more in their official announcement](https://developer.mozilla.org/en-US/blog/introducing-ai-help/).
+We are huge fans of Mozilla at Supabase, so it was an honor when chose [Supabase Vector](https://supabase.com/vector) to build AI Help, a ChatGPT-like interface to the most popular developer docs on the internet: **[MDN](https://developer.mozilla.org/en-US/)**. [Learn more in their official announcement](https://developer.mozilla.org/en-US/blog/introducing-ai-help/).
## Framework support
@@ -66,13 +66,14 @@ The team at PowerSync just dropped [an (extremely attractive) integration](https
## State of the community
### Stack Overflow Survey
-![IMAGE GOES HERE]()
+
+
This was the first year that Supabase appeared on the Stack Overflow survey for [Databases](https://survey.stackoverflow.co/2023/#most-popular-technologies-database) as the 17th “most used”. As a bonus, Postgres took the #1 spot for the first time, and we hope we can continue to contribute to that trend.
### Community Meetups
-![IMAGE GOES HERE]()
+
Supabase started as a remote company, and almost everything we’ve done so far has been digital. This Launch Week added in-person meetups throughout the world, 100% organized by the community. We had meetups in 5 countries, with hundreds of attendees across the world. It has been a successful experiment, something we’ll keep for next time. Thanks to Fatuma, Isheanesu, Daniel, Philip, and Thor for organizing!
diff --git a/apps/www/public/images/blog/launch-week-8/day-5-community/community-highlights-OG.jpg b/apps/www/public/images/blog/launch-week-8/day-5-community/community-highlights-OG.jpg
new file mode 100644
index 0000000000000000000000000000000000000000..e9cb09fb906f0f7177af57e80ebd8e05fd299fa2
GIT binary patch
literal 51826
zcmb4qi$9ZZ`2Rx`lN!yGQfRb|5v4vI)Qr`PYGxbT97+_^^hv3xBw0B`j1h&AX*P3e
zhmdrTa>!wfm_sEAol)uddwjmX?;r4e9&2lRZTEd&_jSFm_jS1cKL7gyfD(7P?E*A3
z06+u0fxl|N1z4b|IsXS#mK(y1VDmqsu>kyzmbR|8wk}LxPapPwzWzQ040INlX;m)JFaR_S
zG!__W{A~nG=clTiTK
z3!vafe-4~;YRS^P&(ZWzUCUu{Al21!6-~nQrVSmY4a&mHX|ENuUT<1ymPE1k&fVEA
zgZR-+E3cLB`|U^o{S&;d9diVc1NYT|yyQSmQ-x(p0j@h%k(M
zWR^r6$)naXBYJE0TsfxhR`IArc~+b%R!lS6Q_gtrzbSJWhFdKcY6FW9N2c@k%8fX{5
zMvmoZ!T=69+PtvMvGd~s5G`~gxPAl=Xw$NBU*Y0B_ZLVbKMVy0<9q-o5{Z(Jv`mQI
z#Tj&}azJ6tK791RnJ4?aFVY4aFpQ05vGM^XR*$*3<-}$@u<$Ma0#>lZCG^JRW}yaQ
z{^vDeT1WuO2VX%;A`XNAB=8*#gs93a(G6;-k)8kRFVL)+LBNB;XPRKC3hKgrL0Jbnum<@>>Sm_LxTl1;
zI(hkr-DwlG;BXoc9TFCTi-W@!$wpJcE3Qw7H1-vJ8GE_)#3TcN;o^+U7_LQ@y4rLE
z)|D_lQZVOgUUJ)nW3GYK?sR2RnC_8CrpQ;uw!K~Uxc+C~UQJ_+&?bFG3@F%Jdg?=k_;d-R%g#Z994hHTn3eYw~O>P+vV6Z1I9=kCy
zTi%#=#ucdz06KIFQChV_R-9!5Zf*OYGp{pOpbo`iu@D9%LC#~`yz{R*PAWd3V6J`t
z>-gvJpO5w?J!86y=|*fn&+sg&pqL?7kv`;Iq)W7^Fk@$D0#)Kn+hTjNKbOtI2yhn+
zh4Xu@0l|`RvEbuk@Qqisze!r#z8o_R!*c)w^!>PWvUZR&N^4!-ukoi0GEjPiSQ#4{
zDDXkkDHv1Pt8Q(Pn60=ml>0vHmQXI~Vq@e3QW@KmEst$cTd0{)(L9v^J|N;Vs7Xjt
zk*wup>$s~RTE`H0HYZ%Wm4Jj
zuJrWUlwHr66i?b)CRSjw7R_0N{&0IEW7txMitYp!-#mXK>i38LR1Xw_259Nv(~%8Z
zX`{}XbQ)k$L_cW3Wd>c&`!&*(3zNbU