[DOC-1080][2025.2] Updated defaults for EPCM flags

docs/content/stable/additional-features/parallel-query.md

@@ -26,6 +26,10 @@ To enable and configure parallel queries, set the following configuration parame
 | yb_parallel_range_rows | The number of rows to plan per parallel worker. To enable parallel query, set this to a value other than 0. (Recommended: 10000) | 0 |
 | yb_parallel_range_size | Approximate size of parallel range for DocDB relation scans. | 1MB |
 
+For new universes running v2025.2 or later, parallel append is enabled by default when you deploy using yugabyted, YugabyteDB Anywhere, or YugabyteDB Aeon.
+
+In addition, when upgrading a deployment to v2025.2 or later, if the universe has the cost-based optimizer enabled (`on`), YugabyteDB will enable parallel append.
+
 In addition, you can use the following PostgreSQL configuration parameters to configure parallel queries:
 
 - Optimize the number of workers used by the parallel query.

docs/content/stable/architecture/design-goals.md

@@ -56,7 +56,7 @@ YugabyteDB supports single-row linearizable writes. Linearizability is one of th
 
 YugabyteDB supports multi-row transactions with three isolation levels: Serializable, Snapshot (also known as repeatable read), and Read Committed isolation.
 
-- The [YSQL API](../../api/ysql/) supports Serializable, Snapshot (default), and Read Committed isolation using the PostgreSQL isolation level syntax of `SERIALIZABLE`, `REPEATABLE READ`, and `READ COMMITTED` respectively. For more details, see [Isolation levels](#transaction-isolation-levels).
+- The [YSQL API](../../api/ysql/) supports Serializable, Snapshot, and Read Committed isolation using the PostgreSQL isolation level syntax of `SERIALIZABLE`, `REPEATABLE READ`, and `READ COMMITTED` respectively. For more details, see [Isolation levels](#transaction-isolation-levels).
 - The [YCQL API](../../api/ycql/) supports only Snapshot isolation (default) using the [BEGIN TRANSACTION](../../api/ycql/dml_transaction/) syntax.
 
 ## Partition Tolerance - CAP

docs/content/stable/architecture/transactions/_index.md

@@ -82,10 +82,10 @@ To learn how YugabyteDB decides which transactions should be aborted in case of
 
 ## Read committed
 
-Read Committed is the isolation level in which, clients do not need to retry or handle serialization errors (40001) in application logic.
+Read Committed is the isolation level in which clients do not need to retry or handle serialization errors (40001) in application logic.
 
 {{<lead link="read-committed/">}}
-To understand how Read committed is implement and how to use it, see [Read committed](read-committed/).
+To understand how Read committed is implemented and how to use it, see [Read committed](read-committed/).
 {{</lead>}}
 
 ## Read restart error

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

@@ -26,7 +26,11 @@ Transaction isolation level support differs between the YSQL and YCQL APIs:
 
 Similarly to PostgreSQL, you can specify Read Uncommitted for YSQL, but it behaves the same as Read Committed.
 
-Read Committed is supported only if the YB-TServer flag `yb_enable_read_committed_isolation` is set to `true`. By default, this flag is `false`, in which case the Read Committed isolation level of YugabyteDB's transactional layer falls back to the stricter Snapshot isolation. The default isolation level for the YSQL API is essentially Snapshot because Read Committed, which is the YSQL API and PostgreSQL syntactic default, maps to Snapshot isolation.
+Read Committed is supported only if the YB-TServer flag `yb_enable_read_committed_isolation` is set to `true`.
+
+For new universes running v2025.2 or later, Read Committed is enabled by default when you deploy using yugabyted, YugabyteDB Anywhere, or YugabyteDB Aeon.
+
+In versions of YugabyteDB prior to v2025.2, or for manually deployed universes, `yb_enable_read_committed_isolation` is `false` (the default), and the Read Committed isolation level of YugabyteDB's transactional layer falls back to the stricter Snapshot isolation. This makes the default isolation level for the YSQL API effectively Snapshot because Read Committed, which is the YSQL API and PostgreSQL syntactic default, maps to Snapshot isolation.
 
 ## Internal locking in DocDB
 

docs/content/stable/architecture/transactions/read-committed.md

@@ -23,7 +23,11 @@ Note that retries for the statement in YugabyteDB's Read Committed isolation are
 
 {{< tip title="Enable Read Committed" >}}
 
-To enable Read Committed isolation, set the YB-TServer flag [yb_enable_read_committed_isolation](../../../reference/configuration/yb-tserver/#yb-enable-read-committed-isolation) to `true`. By default this flag is `false` and in this case the Read Committed isolation level of the YugabyteDB 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 is supported only if the YB-TServer flag `yb_enable_read_committed_isolation` is set to `true`.
+
+For new universes running v2025.2 or later, Read Committed is enabled by default when you deploy using yugabyted, YugabyteDB Anywhere, or YugabyteDB Aeon.
+
+In versions of YugabyteDB prior to v2025.2, or for manually deployed universes, `yb_enable_read_committed_isolation` is `false` (the default), and the Read Committed isolation level of YugabyteDB's transactional layer falls back to the stricter Snapshot isolation. This makes the default isolation level for the YSQL API effectively Snapshot because Read Committed, which is the YSQL API and PostgreSQL syntactic default, maps to Snapshot isolation.
 
 Refer to [Usage](#usage) to start a Read Committed transaction after enabling the flag.
 {{< /tip >}}
@@ -342,7 +346,7 @@ The retries for serialization errors are done at the statement level. Each retry
 
 ## Usage
 
-To use Read Committed isolation, first set the YB-TServer flag `yb_enable_read_committed_isolation=true`; this maps the syntactic Read Committed isolation in YSQL to the Read Committed implementation in DocDB. (When set to `false`, syntactic Read Committed in YSQL is mapped to Snapshot isolation in DocDB, meaning it behaves as Repeatable Read.)
+To use Read Committed isolation, ensure the YB-TServer flag `yb_enable_read_committed_isolation=true`; this maps the syntactic Read Committed isolation in YSQL to the Read Committed implementation in DocDB. (When set to `false`, syntactic Read Committed in YSQL is mapped to Snapshot isolation in DocDB, meaning it behaves as Repeatable Read.)
 
 Assuming the flag has been set, you can start a Read Committed transaction in the following ways:
 
@@ -1409,7 +1413,7 @@ Read Committed interacts with the following feature:
 
 ## Limitations
 
-* A `SET TRANSACTION ISOLATION LEVEL ...` statement immediately issued after `BEGIN;` or `BEGIN TRANSACTION ISOLATION LEVEL READ COMMITTED;` will fail if the YB-TServer GFlag `yb_enable_read_committed_isolation=true`, and the following error will be issued:
+* A `SET TRANSACTION ISOLATION LEVEL ...` statement immediately issued after `BEGIN;` or `BEGIN TRANSACTION ISOLATION LEVEL READ COMMITTED;` will fail if the YB-TServer flag `yb_enable_read_committed_isolation=true`, and the following error will be issued:
 
     ```output
     ERROR:  SET TRANSACTION ISOLATION LEVEL must not be called in a subtransaction

docs/content/stable/best-practices-operations/ysql-yb-enable-cbo.md

@@ -26,7 +26,9 @@ You configure CBO using the [yb_enable_cbo](../../reference/configuration/yb-tse
 
 ## New deployments
 
-For new YSQL deployments, or when migrating from another system, to enable CBO, add the parameter to [ysql_pg_conf_csv](../../reference/configuration/yb-tserver/#ysql-pg-conf-csv) as follows:
+For new universes running v2025.2 or later, CBO is enabled by default when you deploy using yugabyted, YugabyteDB Anywhere, or YugabyteDB Aeon.
+
+For older YSQL deployments, or when deploying manually, to enable CBO, add the parameter to [ysql_pg_conf_csv](../../reference/configuration/yb-tserver/#ysql-pg-conf-csv) as follows:
 
 ```sh
 --ysql_pg_conf_csv=yb_enable_cbo=on
@@ -53,6 +55,14 @@ When upgrading a deployment to a version of YugabyteDB that supports the `yb_ena
 
 You should migrate existing deployments from using `legacy_mode` or `legacy_stats_mode` to either `on` (recommended) or, if you do not want to use CBO, `off`.
 
+Note that when upgrading a deployment to v2025.2 or later, if the universe has the cost-based optimizer enabled (`on`), YugabyteDB will enable the following features:
+
+- Auto Analyze: ysql_enable_auto_analyze is set to true.
+- Bitmap scans: yb_enable_bitmapscan is set to true.
+- Parallel append: yb_enable_parallel_append is set to true.
+
+For more information on these features, see [Enhanced PostgreSQL Compatibility](../../reference/configuration/postgresql-compatibility/).
+
 <!--## Recommended settings
 
 | Scenario | Tables analyzed | Setting |

docs/content/stable/deploy/manual-deployment/start-masters.md

@@ -75,6 +75,8 @@ The number of comma-separated addresses in `--master_addresses` should equal the
 
 You can specify multiple directories using the [`--fs_data_dirs`](../../../reference/configuration/yb-master/#fs-data-dirs) flag. Replace the [`--rpc_bind_addresses`](../../../reference/configuration/yb-master/#rpc-bind-addresses) value with the private IP address of the host, and set the `placement_cloud`, `placement_region`, and `placement_zone` values appropriately. For single zone deployment, use the same value for the `placement_zone` flag.
 
+If you are running YSQL, for enhanced PostgreSQL compatibility, you can enable [Enhanced PostgreSQL Compatibility Mode](../../../reference/configuration/postgresql-compatibility/) (recommended).
+
 {{<tags/feature/tp idea="1807">}} Highly accurate clocks can be configured by specifying `--time_source=clockbound`. Requires [system configuration](../system-config#set-up-time-synchronization).
 
 For the full list of configuration flags, see the [YB-Master reference](../../../reference/configuration/yb-master/).

docs/content/stable/explore/transactions/isolation-levels.md

@@ -39,11 +39,13 @@ YugabyteDB supports three isolation levels in the transactional layer:
 
 The default isolation level for the YSQL API is effectively Snapshot (that is, the same as PostgreSQL's `REPEATABLE READ`) because, by default, Read committed, which is the YSQL API and PostgreSQL _syntactic_ default, maps to Snapshot isolation.
 
-To enable Read committed, you must set the YB-TServer flag `yb_enable_read_committed_isolation` to `true`. By default this flag is `false` and the Read committed isolation level of the YugabyteDB 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).
+However, for new universes running v2025.2 or later, Read Committed is enabled by default when you deploy using yugabyted, YugabyteDB Anywhere, or YugabyteDB Aeon.
+
+In versions of YugabyteDB prior to v2025.2, or for manually deployed universes, to enable Read committed, you must set the YB-TServer flag `yb_enable_read_committed_isolation` to `true`. By default this flag is `false` , and the Read Committed isolation level of YugabyteDB's transactional layer falls back to the stricter Snapshot isolation. This makes the default isolation level for the YSQL API effectively Snapshot because Read Committed, which is the YSQL API and PostgreSQL syntactic default, maps to Snapshot isolation.
 
 {{< tip title="Tip" >}}
 
-To avoid serializable errors, that is, to run applications with no retry logic, keep the default `READ COMMITTED` isolation (`--ysql_default_transaction_isolation`), and set the YB-TServer `--yb_enable_read_committed_isolation` flag to true. This enables read committed isolation.
+To avoid serializable errors (that is, to run applications with no retry logic), keep the default `READ COMMITTED` isolation (`--ysql_default_transaction_isolation`), and set the YB-TServer `--yb_enable_read_committed_isolation` flag to true. This enables read committed isolation.
 
 {{< /tip >}}
 
@@ -229,7 +231,7 @@ Snapshot isolation detects only write-write conflicts; it does not detect read-w
 
 Applications using this level must be prepared to retry transactions due to serialization failures.
 
-Consider an example of transactions' behavior under the Snapshot isolation level (mapped to PostgreSQL's Repeatable Read level).
+Consider an example of transactions' behavior under the Snapshot isolation level.
 
 Create a table with sample data, as follows:
 
@@ -249,10 +251,10 @@ Next, connect to the universe using two independent ysqlsh instances, referred t
   <tr>
     <td>
 
-Begin a transaction in session #1. This is Snapshot isolation by default, meaning it will work against a snapshot of the database as of this point:
+Begin a transaction in session #1 with the Snapshot isolation level, meaning it will work against a snapshot of the database as of this point:
 
 ```sql
-BEGIN TRANSACTION;
+BEGIN TRANSACTION ISOLATION LEVEL SNAPSHOT;
 ```
 
   </td>
@@ -290,6 +292,7 @@ SELECT * FROM example;
 Insert a different row. Verify that the row inserted in the transaction in session #1 is not visible in this session, as follows:
 
 ```sql
+BEGIN TRANSACTION ISOLATION LEVEL SNAPSHOT;
 INSERT INTO example VALUES (2);
 SELECT * FROM example;
 ```
@@ -374,10 +377,10 @@ Connect to the universe using two independent ysqlsh instances, referred to as s
   <tr>
     <td>
 
-By default, the YB-TServer flag `yb_enable_read_committed_isolation` is false. In this case, Read committed maps to Snapshot isolation at the transactional layer. So, `READ COMMITTED` of YSQL API in turn maps to Snapshot Isolation:
+Begin a transaction in session #1. (Note that because the universe was deployed using yugabyted, YugabyteDB Anywhere, or YugabyteDB Aeon, Read Committed is the default isolation level.)
 
 ```sql
-BEGIN TRANSACTION ISOLATION LEVEL READ COMMITTED;
+BEGIN TRANSACTION;
 SELECT * FROM test;
 ```
 
@@ -417,22 +420,6 @@ SELECT * FROM test;
 COMMIT;
 ```
 
-```output
- k | v
----+---
- 1 | 2
-(1 row)
-```
-
-The inserted row (2, 3) is not visible because Read committed is disabled at the transactional layer and maps to Snapshot in which the whole transaction sees a consistent snapshot of the database.
-
-Set the YB-TServer flag `yb_enable_read_committed_isolation` to `true`:
-
-```sql
-BEGIN TRANSACTION ISOLATION LEVEL READ COMMITTED;
-SELECT * FROM test;
-```
-
 ```output
  k | v
 ---+---
@@ -441,44 +428,7 @@ SELECT * FROM test;
 (2 rows)
 ```
 
-  </td>
-    <td>
-    </td>
-  </tr>
-
-  <tr>
-    <td>
-    </td>
-    <td>
-
-Insert a new row, as follows:
-
-```sql
-INSERT INTO test VALUES (3, 4);
-```
-
-  </td>
-  </tr>
-
-  <tr>
-    <td>
-
-Perform the read again in the same transaction, as follows:
-
-```sql
-SELECT * FROM test;
-```
-
-```output
- k | v
----+---
- 1 | 2
- 2 | 3
- 3 | 4
-(3 rows)
-```
-
-This time, the statement can see the row (3, 4) that was committed after this transaction had been started but before the statement has been issued.
+Unlike snapshot isolation, the statement can see the row (2, 3) that was committed after this transaction had been started but before the statement has been issued.
 
   </td>
     <td>

docs/content/stable/manage/upgrade-deployment.md

@@ -62,7 +62,13 @@ To upgrade YugabyteDB to a version based on a different version of PostgreSQL (f
   - If you have PITR enabled, you must disable it before performing an upgrade. Re-enable it only after the upgrade is either finalized or rolled back.
   - After the upgrade, PITR cannot be done to a time before the upgrade.
 
-- For more information, refer to [Upgrade FAQ](/stable/faq/operations-faq/#upgrade).
+- YSQL
+
+  - For additional information on upgrading universes that have Enhanced PostgreSQL Compatibility Mode, refer to [Enhanced PostgreSQL Compatibility Mode](../../reference/configuration/postgresql-compatibility/).
+
+  - For information on upgrading or enabling cost-based optimizer, refer to [Enable cost-based optimizer](../../best-practices-operations/ysql-yb-enable-cbo/).
+
+For more information, refer to [Upgrade FAQ](/stable/faq/operations-faq/#upgrade).
 
 ## Upgrade YugabyteDB cluster
 

docs/content/stable/reference/configuration/postgresql-compatibility.md

@@ -18,7 +18,11 @@ rightNav:
 
 YugabyteDB is a [PostgreSQL-compatible](https://www.yugabyte.com/tech/postgres-compatibility/) distributed database that supports the majority of PostgreSQL syntax. YugabyteDB is methodically expanding its features to deliver PostgreSQL-compatible performance that can substantially improve your application's efficiency.
 
-To test and take advantage of features developed for enhanced PostgreSQL compatibility in YugabyteDB that are currently in {{<tags/feature/ea>}}, you can enable Enhanced PostgreSQL Compatibility Mode (EPCM). When this mode is turned on, YugabyteDB is configured to use all the latest features developed for feature and performance parity. EPCM is available in [v2024.1](/stable/releases/ybdb-releases/v2024.1/) and later. The following features are part of EPCM.
+To test and take advantage of features developed for enhanced PostgreSQL compatibility in YugabyteDB that are in {{<tags/feature/ea>}}, you can enable Enhanced PostgreSQL Compatibility Mode (EPCM). When this mode is turned on, YugabyteDB is configured to use all the latest features developed for feature and performance parity. EPCM is available in [v2024.1](/stable/releases/ybdb-releases/v2024.1/) and later.
+
+For new universes running v2025.2 or later, all the features in EPCM are enabled by default when you deploy using yugabyted, YugabyteDB Anywhere, or YugabyteDB Aeon.
+
+The following features are part of EPCM.
 
 | Feature | Flag/Configuration Parameter | EA | GA |
 | :--- | :--- | :--- | :--- |
@@ -37,12 +41,24 @@ After turning this mode on, as you upgrade universes, YugabyteDB will automatica
 
 As features included in the PostgreSQL compatibility mode transition from {{<tags/feature/ea>}} to {{<tags/feature/ga>}} in subsequent versions of YugabyteDB, they become enabled by default on new universes, and are no longer managed under EPCM on your existing universes after the upgrade.
 
+In v2025.2 and later, all the features in EPCM are enabled by default when you deploy using yugabyted, YugabyteDB Anywhere, or YugabyteDB Aeon.
+
 {{<note title="Note">}}
 If you have set these features independent of EPCM, you cannot use EPCM.
 
 Conversely, if you are using EPCM on a universe, you cannot set any of the features independently.
 {{</note>}}
 
+### Upgrading
+
+If you upgrade a universe with EPCM to v2025.2 or later, YugabyteDB will automatically enable all EPCM features. Going forward, use individual flags to set features.
+
+When upgrading a universe that does not have EPCM, YugabyteDB does not enable features automatically. If the universe has the [cost based optimizer](#cost-based-optimizer) enabled, however, YugabyteDB will enable the following features:
+
+- Auto Analyze: ysql_enable_auto_analyze is set to true.
+- Bitmap scans: yb_enable_bitmapscan is set to true.
+- Parallel append: yb_enable_parallel_append is set to true.
+
 ## Released features
 
 The following features are currently available in EPCM.
@@ -131,6 +147,10 @@ To learn about parallel queries, see [Parallel queries](../../../additional-feat
 
 ## Enable EPCM
 
+In v2025.2 and later, all the features in EPCM are enabled by default in new universes when you deploy using yugabyted, YugabyteDB Anywhere, or YugabyteDB Aeon.
+
+For versions prior to v2025.2 (or when deploying manually), you can enable EPCM as follows.
+
 ### YugabyteDB
 
 To enable EPCM in YugabyteDB:

docs/content/stable/reference/configuration/yb-master.md

@@ -1066,6 +1066,7 @@ See also [Auto Analyze Service TServer flags](../yb-tserver/#auto-analyze-servic
 
 {{<tags/feature/ea idea="590">}}Enable the Auto Analyze service, which automatically runs ANALYZE to update table statistics for tables that have changed more than a configurable threshold.
 
+
 Default: false
 
 ## Advisory lock flags