[docs] Add beta tags to read committed and colocated (yugabyte#15190)

* Add beta tags to read committed and colocated

* minor edit

* couple more beta notes

* review comments

docs/content/preview/api/ysql/the-sql-language/statements/ddl_create_database.md

@@ -87,8 +87,11 @@ Specify `false` to only superusers or the owner of the database can clone it.
 
 ### COLOCATED
 
+Colocated table support is currently in [Beta](/preview/faq/general/#what-is-the-definition-of-the-beta-feature-tag).
+
 Specify `true` if all tables for this database should be colocated on a single tablet. See [colocated tables architecture](https://github.com/yugabyte/yugabyte-db/blob/master/architecture/design/ysql-colocated-tables.md) for details on when colocated tables are useful.
-Default value is `false` and every table in the database will have its own set of tablets.
+
+Default is `false` and every table in the database will have its own set of tablets.
 
 ## Examples
 

docs/content/preview/api/ysql/the-sql-language/statements/ddl_create_matview.md

@@ -47,12 +47,15 @@ Use the `CREATE MATERIALIZED VIEW` statement to create a materialized view.
 Create a materialized view named *matview_name*. If `matview_name` already exists in the specified database, an error will be raised unless the `IF NOT EXISTS` clause is used.
 
 ### Tablespace
+
 Used to specify the tablespace for the materialized view.
 
 ### Storage parameters
 
 COLOCATED
 
+Colocated table support is currently in [Beta](/preview/faq/general/#what-is-the-definition-of-the-beta-feature-tag).
+
 Specify `COLOCATED = true` for the materialized view to be colocated. The default value of this option is false.
 
 ## Examples
@@ -66,7 +69,7 @@ yugabyte=# CREATE MATERIALIZED VIEW m1 AS SELECT * FROM t1 WHERE a = 3;
 yugabyte=# SELECT * FROM t1;
 ```
 
-```
+```output
  a | b
 ---+---
  3 | 4
@@ -78,7 +81,7 @@ yugabyte=# SELECT * FROM t1;
 yugabyte=# SELECT * FROM m1;
 ```
 
-```
+```output
  a | b
 ---+---
  3 | 4

docs/content/preview/api/ysql/the-sql-language/statements/ddl_create_table.md

@@ -130,7 +130,10 @@ In the example above, there are three split points and so four tablets will be c
 
 ### COLOCATED
 
+Colocated table support is currently in [Beta](/preview/faq/general/#what-is-the-definition-of-the-beta-feature-tag).
+
 For colocated databases, specify `false` to opt this table out of colocation. This means that the table won't be stored on the same tablet as the rest of the tables for this database, but instead, will have its own set of tablets.
+
 Use this option for large tables that need to be scaled out. See [colocated tables architecture](https://github.com/yugabyte/yugabyte-db/blob/master/architecture/design/ysql-colocated-tables.md) for more details on when colocation is useful.
 
 Note that `COLOCATED = true` has no effect if the database that this table is part of is not colocated since colocation today is supported only at the database level.

docs/content/preview/api/ysql/the-sql-language/statements/txn_begin.md

@@ -60,9 +60,9 @@ Add optional keyword — has no effect.
 
 ### *transaction_mode*
 
-Supports Serializable, Snapshot and Read Committed Isolation<sup>$</sup> using the PostgreSQL isolation level syntax of `SERIALIZABLE`, `REPEATABLE READ` and `READ COMMITTED` respectively. PostgreSQL's `READ UNCOMMITTED` also maps to Read Committed Isolation.
+Supports Serializable, Snapshot, and Read Committed Isolation<sup>$</sup> using the PostgreSQL isolation level syntax of `SERIALIZABLE`, `REPEATABLE READ`, and `READ COMMITTED` respectively. PostgreSQL's `READ UNCOMMITTED` also maps to Read Committed Isolation.
 
-<sup>$</sup> Read Committed Isolation is supported only if the gflag `yb_enable_read_committed_isolation` is set to `true`. By default this gflag is `false` and in this case the Read Committed isolation level of Yugabyte's transactional layer falls back to the stricter Snapshot Isolation (in which case `READ COMMITTED` and `READ UNCOMMITTED` of YSQL also in turn use Snapshot Isolation). Read Committed support is currently in [Beta](/preview/faq/general/#what-is-the-definition-of-the-beta-feature-tag).
+<sup>$</sup> Read Committed support is currently in [Beta](/preview/faq/general/#what-is-the-definition-of-the-beta-feature-tag). Read Committed Isolation is supported only if the gflag `yb_enable_read_committed_isolation` is set to `true`. By default this gflag is `false` and in this case the Read Committed isolation level of Yugabyte's transactional layer falls back to the stricter Snapshot Isolation (in which case `READ COMMITTED` and `READ UNCOMMITTED` of YSQL also in turn use Snapshot Isolation).
 
 ## Examples
 

docs/content/preview/api/ysql/the-sql-language/statements/txn_set.md

@@ -69,9 +69,11 @@ Maps to Snapshot Isolation of YugabyteDB.
 
 #### READ COMMITTED
 
+Read Committed support is currently in [Beta](/preview/faq/general/#what-is-the-definition-of-the-beta-feature-tag).
+
 Default in PostgreSQL and YSQL.
 
-If `yb_enable_read_committed_isolation=true`, `READ COMMITTED` is mapped to Read Committed of YugabyteDB's transactional layer (i.e., a statement will see all rows that are committed before it begins). But, by default `yb_enable_read_committed_isolation=false` and in this case Read Committed of YugabyteDB's transactional layer falls back to the stricter Snapshot Isolation. Read Committed support is currently in [Beta](/preview/faq/general/#what-is-the-definition-of-the-beta-feature-tag).
+If `yb_enable_read_committed_isolation=true`, `READ COMMITTED` is mapped to Read Committed of YugabyteDB's transactional layer (i.e., a statement will see all rows that are committed before it begins). But, by default `yb_enable_read_committed_isolation=false` and in this case Read Committed of YugabyteDB's transactional layer falls back to the stricter Snapshot Isolation.
 
 Essentially this boils down to the fact that Snapshot Isolation is the default in YSQL.
 

docs/content/preview/api/ysql/the-sql-language/statements/txn_show.md

@@ -45,9 +45,9 @@ Use the `SHOW TRANSACTION ISOLATION LEVEL` statement to show the current transac
 
 ## Semantics
 
-Supports Serializable, Snapshot and Read Committed Isolation<sup>$</sup> using the PostgreSQL isolation level syntax of `SERIALIZABLE`, `REPEATABLE READ` and `READ COMMITTED` respectively. PostgreSQL's `READ UNCOMMITTED` also maps to Read Committed Isolation.
+Supports Serializable, Snapshot, and Read Committed Isolation<sup>$</sup> using the PostgreSQL isolation level syntax of `SERIALIZABLE`, `REPEATABLE READ`, and `READ COMMITTED` respectively. PostgreSQL's `READ UNCOMMITTED` also maps to Read Committed Isolation.
 
-<sup>$</sup> Read Committed Isolation is supported only if the gflag `yb_enable_read_committed_isolation` is set to `true`. By default this gflag is `false` and in this case the Read Committed isolation level of Yugabyte's transactional layer falls back to the stricter Snapshot Isolation (in which case `READ COMMITTED` and `READ UNCOMMITTED` of YSQL also in turn use Snapshot Isolation). Read Committed support is currently in [Beta](/preview/faq/general/#what-is-the-definition-of-the-beta-feature-tag).
+<sup>$</sup> Read Committed support is currently in [Beta](/preview/faq/general/#what-is-the-definition-of-the-beta-feature-tag). Read Committed Isolation is supported only if the gflag `yb_enable_read_committed_isolation` is set to `true`. By default this gflag is `false` and in this case the Read Committed isolation level of Yugabyte's transactional layer falls back to the stricter Snapshot Isolation (in which case `READ COMMITTED` and `READ UNCOMMITTED` of YSQL also in turn use Snapshot Isolation).
 
 ### TRANSACTION ISOLATION LEVEL
 

docs/content/preview/architecture/docdb-sharding/colocated-tables.md

@@ -3,6 +3,7 @@ title: Colocated tables
 headerTitle: Colocated tables
 linkTitle: Colocated tables
 description: Learn about how colocated tables aggregate data into a single tablet.
+beta: /preview/faq/general/#what-is-the-definition-of-the-beta-feature-tag
 aliases:
   - /preview/architecture/docdb/colocated_tables/
 menu:
@@ -13,7 +14,7 @@ menu:
 type: docs
 ---
 
-In workloads that need lower throughput and have a small data set, the bottleneck shifts from CPU/disk/network to the number of tablets that should be hosted per node. Since each table by default requires at least one tablet per node, a YugabyteDB cluster with 5000 relations (which includes tables and indexes) will result in 5000 tablets per node. There are practical limitations to the number of tablets that YugabyteDB can handle per node since each tablet adds some CPU, disk, and network overhead. If most or all of the tables in YugabyteDB cluster are small tables, then having separate tablets for each table unnecessarily adds pressure on CPU, network and disk.
+In workloads that need lower throughput and have a small data set, the bottleneck shifts from CPU/disk/network to the number of tablets that should be hosted per node. Because each table by default requires at least one tablet per node, a YugabyteDB cluster with 5000 relations (which includes tables and indexes) will result in 5000 tablets per node. There are practical limitations to the number of tablets that YugabyteDB can handle per node because each tablet adds some CPU, disk, and network overhead. If most or all of the tables in a YugabyteDB cluster are small tables, then having separate tablets for each table unnecessarily adds pressure on CPU, network, and disk.
 
 To help accommodate such relational tables and workloads, YugabyteDB supports colocating SQL tables. Colocating tables puts all of their data into a single tablet, called the colocation tablet. This can dramatically increase the number of relations (tables, indexes, etc) that can be supported per node while keeping the number of tablets per node low. Note that all the data in the colocation tablet is still replicated across three nodes (or whatever the replication factor is). Large tablets can be dynamically split at a future date if there is need to serve more throughput over a larger data set.
 
@@ -41,7 +42,7 @@ In this scenario, it is undesirable to have the small dataset spread across mult
 this might affect performance of certain queries due to more network hops (for example, joins).
 
 **Example:** User identity service for a global application. The user dataset size may not be too
-large, but is accessed in a relational manner, requires high availability and might need to be
+large, but is accessed in a relational manner, requires high availability, and might need to be
 geo-distributed for low latency access.
 
 ### Large datasets - a few large tables with many small tables
@@ -59,7 +60,8 @@ In this scenario, only the few large tables would need to be sharded and scaled
 ### Scaling the number of databases, each database with a small dataset
 
 There may be scenarios where the number of databases grows rapidly, while the dataset of each database is small.
-This is characteristic of a microservices-oriented architecture, where each microservice needs its own database. These microservices are hosted in dev, test, staging, production and other environments. The net result is a lot of small databases, and the need to be able to scale the number of databases hosted. Colocated tables allow for the entire dataset in each database to be hosted in one tablet, enabling scalability of the number of databases in a cluster by simply adding more nodes.
+
+This is characteristic of a microservices-oriented architecture, where each microservice needs its own database. These microservices are hosted in dev, test, staging, production, and other environments. The net result is a lot of small databases, and the need to be able to scale the number of databases hosted. Colocated tables allow for the entire dataset in each database to be hosted in one tablet, enabling scalability of the number of databases in a cluster by simply adding more nodes.
 
 **Example:** Multi-tenant SaaS services where one database is created per customer. As new customers are rapidly on-boarded, it becomes necessary to add more databases quickly while maintaining high-availability and fault-tolerance of each database.
 

docs/content/preview/architecture/transactions/isolation-levels.md

@@ -15,7 +15,7 @@ type: docs
 
 Transaction isolation is foundational to handling concurrent transactions in databases. The [SQL-92 standard](https://en.wikipedia.org/wiki/SQL-92) defines four levels of transaction isolation. These are, in decreasing order of strictness: SERIALIZABLE, REPEATABLE READ, READ COMMITTED, and READ UNCOMMITTED.
 
-YugabyteDB supports the three strictest transaction isolation levels: Read Committed, Serializable (both map to the SQL isolation level of the same name) and Snapshot (which maps to the SQL Repeatable Read isolation level). Thus, YugabyteDB supports the three strictest of the four SQL isolation levels:
+YugabyteDB supports the three strictest transaction isolation levels: Read Committed<sup>$</sup>, Serializable (both map to the SQL isolation level of the same name), and Snapshot (which maps to the SQL Repeatable Read isolation level). Thus, YugabyteDB supports the three strictest of the four SQL isolation levels:
 
 - [Serializable isolation](https://en.wikipedia.org/wiki/Isolation_(database_systems)#Serializable) guarantees that transactions run in a way equivalent to a serial (sequential) schedule.
 
@@ -28,7 +28,7 @@ Note that transaction isolation level support differs between the YSQL and YCQL
 - [YSQL](../../../api/ysql/) supports Serializable, Snapshot, and Read Committed<sup>$</sup> isolation levels (the PostgreSQL isolation level syntax of Serializable, Repeatable Read, and Read Committed map to these three, respectively).
 - [YCQL](../../../api/ycql/dml_transaction/) supports only Snapshot isolation using the `BEGIN TRANSACTION` syntax.
 
-<sup>$</sup> Read Committed Isolation is supported only if the gflag `yb_enable_read_committed_isolation` is set to true. By default this gflag is false and in this case the Read Committed isolation level of Yugabyte's transactional layer falls back to the stricter Snapshot isolation (in which case YSQL's Read Committed and Read Uncommitted also in turn use Snapshot isolation). Read Committed support is currently in [Beta](/preview/faq/general/#what-is-the-definition-of-the-beta-feature-tag).
+<sup>$</sup> Read Committed support is currently in [Beta](/preview/faq/general/#what-is-the-definition-of-the-beta-feature-tag). Read Committed Isolation is supported only if the gflag `yb_enable_read_committed_isolation` is set to true. By default this gflag is false and in this case the Read Committed isolation level of Yugabyte's transactional layer falls back to the stricter Snapshot isolation (in which case YSQL's Read Committed and Read Uncommitted also in turn use Snapshot isolation).
 
 {{< note title="Note" >}}