Prettier + typo fix

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
 
 ![Encrypted data](/docs/img/guides/database/vault-encrypted-data.png)
 
-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
 
 ![Decrypted data](/docs/img/guides/database/vault-decrypted-data.png)
 
-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