docs: upstream

planetscale/www@b8e94f7

docs/concepts/access-control.md

@@ -1,7 +1,7 @@
 ---
 title: 'Access control'
 subtitle: 'Explore roles, permissions, and access control options at an organization and database level.'
-date: '2022-08-01'
+date: '2024-04-26'
 ---
 
 ## Organization access control
@@ -26,13 +26,13 @@ An `Organization Administrator` can perform all actions in an organization, as w
 
 ### Organization Member
 
-An `Organization Member` can only perform limited actions within an organization and on all databases in that organization.
+An `Organization Member` can only perform limited actions within an organization and on all databases in that organization. By default, all users added to an organization have this role.
 
 ### Database Administrator
 
 A `Database Administrator` can perform all actions on the database for which they were assigned the `Databases Administrator` role.
 
-This role is assigned at the **database level** and therefore **does not** have any organization-level permissions. If you want to [grant a member _full_ access to manage one or several databases](#assign-roles-at-a-database-level) but not the organization, then this is the role you want.
+This role is assigned at the **database level** and gives elevated permissions for the particular database that an organization member is the `Database Administrator` of. If you want to [grant a member _full_ access to manage one or several databases](#assign-roles-at-a-database-level) but not full `Organization Administrator` access, then this is the role you want. Please note, a user that is granted this role must be a member of the organization of which the database exists in, so they will have the permissions associated with `Organization Member` as well.
 
 ## Organization-level permissions
 

docs/concepts/deploy-requests.md

@@ -1,7 +1,7 @@
 ---
 title: 'Deploy requests'
 subtitle: 'Learn how to create and revert non-blocking schema changes with PlanetScale deploy requests.'
-date: '2024-02-14'
+date: '2024-04-26'
 ---
 
 ## Overview
@@ -169,3 +169,9 @@ If you have an open Gated Deployment, you cannot deploy another deploy request u
 {% /callout %}
 
 For more information about this process and why we built it, check out the [Gated Deployments: Addressing the complexity of schema deployments at scale](/blog/gated-deployments-addressing-the-complexity-of-schema-deployments-at-scale) blog post.
+
+## Temporary tables
+
+When using deploy requests, you may notice some additional tables in your database ending with a `_vrepl` suffix. These are temporary tables that [VReplication](https://vitess.io/docs/reference/vreplication/vreplication/) creates while running your online schema changes.
+
+We clean them up automatically and they do not count against the storage limits of your selected plan. If you want to learn more about how we perform online schema changes, please refer to our [Online schema change tools article](/docs/learn/how-online-schema-change-tools-work#initializing-the-ghost-table-schema).

docs/reference/planetscale-system-limits.md

@@ -1,7 +1,7 @@
 ---
 title: 'PlanetScale system limits'
 subtitle: 'Learn about system limits that PlanetScale puts in place to protect your database.'
-date: '2023-03-17'
+date: '2024-04-26'
 ---
 
 ## Table limits
@@ -59,5 +59,9 @@ While it is possible to bypass these safety limits using `OLAP` mode (`SET workl
 
 When the use of OLAP queries is strictly unavoidable, we recommend:
 
-- Where possible, sending those queries to a replica.
+- Where possible, sending those queries to a replica. Every PlanetScale database comes with at least two replicas. Learn how to send queries to replicas using [global replica credentials](/docs/concepts/replicas#how-to-query-replicas).
 - Carefully and regularly reviewing the performance of those queries with [PlanetScale Insights](/docs/concepts/query-insights).
+
+{% callout %}
+Please note that if you choose to use OLAP mode, you need to be prepared to handle errors if the connection to PlanetScale gets interrupted for any reason.
+{% /callout %}