Remove 'Enterprise' mentions from v25.1 docs + rename 'basic' to 'Sinkless'

Author: katmayb

src/current/_data/redirects.yml

@@ -253,7 +253,7 @@
 
 - destination: how-does-a-changefeed-work.md
   sources: ['how-does-an-enterprise-changefeed-work.md']
-  versions: ['v25.2']
+  versions: ['v25.2', 'v25.1']
 
 - destination: kubernetes-overview.md
   sources: ['operate-cockroachdb-kubernetes.md']

src/current/_includes/releases/v25.2/deprecations.md

@@ -1,3 +1,4 @@
 The following deprecations are announced in v25.2.
 
-- The [`ui.display_timezone` cluster setting]({% link v25.2/cluster-settings.md %}#setting-ui-display-timezone) is now deprecated and will be removed in a future release. If it has been set, its value will automatically be applied to the new setting `ui.default_timezone`, which takes precedence. For further detail, refer to [DB Console timezone configuration]({% link v25.2/ui-overview.md %}#db-console-timezone-configuration).
+- The [`ui.display_timezone` cluster setting]({% link v25.2/cluster-settings.md %}#setting-ui-display-timezone) is now deprecated and will be removed in a future release. If it has been set, its value will automatically be applied to the new setting `ui.default_timezone`, which takes precedence. For further detail, refer to [DB Console timezone configuration]({% link v25.2/ui-overview.md %}#db-console-timezone-configuration).
+- The [`EXPERIMENTAL CHANGEFEED FOR`]({% link v25.2/changefeed-for.md %}) SQL statement is now deprecated and will be removed in a future release. Instead, create a sinkless changefeed that emits messages directly to a SQL client with the [`CREATE CHANGEFEED`]({% link v25.2/create-changefeed.md %}#create-a-sinkless-changefeed) statement. 

src/current/_includes/v25.1/cdc/cdc-schema-locked-example.md

@@ -1,4 +1,4 @@
-Use the `schema_locked` [storage parameter]({% link {{ page.version.version }}/with-storage-parameter.md %}) to disallow [schema changes]({% link {{ page.version.version }}/online-schema-changes.md %}) on a watched table, which allows the changefeed to take a fast path that avoids checking if there are schema changes that could require synchronization between [changefeed aggregators]({% link {{ page.version.version }}/how-does-an-enterprise-changefeed-work.md %}). This helps to decrease the latency between a write committing to a table and it emitting to the [changefeed's sink]({% link {{ page.version.version }}/changefeed-sinks.md %}). Enabling `schema_locked` 
+Use the `schema_locked` [storage parameter]({% link {{ page.version.version }}/with-storage-parameter.md %}) to disallow [schema changes]({% link {{ page.version.version }}/online-schema-changes.md %}) on a watched table, which allows the changefeed to take a fast path that avoids checking if there are schema changes that could require synchronization between [changefeed aggregators]({% link {{ page.version.version }}/how-does-a-changefeed-work.md %}). This helps to decrease the latency between a write committing to a table and it emitting to the [changefeed's sink]({% link {{ page.version.version }}/changefeed-sinks.md %}). Enabling `schema_locked` 
 
 Enable `schema_locked` on the watched table with the [`ALTER TABLE`]({% link {{ page.version.version }}/alter-table.md %}) statement:
 

src/current/_includes/v25.1/cdc/create-core-changefeed-avro.md renamed to src/current/_includes/v25.1/cdc/create-sinkless-changefeed-avro.md

@@ -28,9 +28,9 @@ In this example, you'll set up a basic changefeed for a single-node cluster that
     $ cockroach sql --url="postgresql://[email protected]:26257?sslmode=disable" --format=csv
     ~~~
 
-    {% include {{ page.version.version }}/cdc/core-url.md %}
+    {% include {{ page.version.version }}/cdc/sinkless-url.md %}
 
-    {% include {{ page.version.version }}/cdc/core-csv.md %}
+    {% include {{ page.version.version }}/cdc/sinkless-csv.md %}
 
 1. Enable the `kv.rangefeed.enabled` [cluster setting]({% link {{ page.version.version }}/cluster-settings.md %}):
 

src/current/_includes/v25.1/cdc/create-core-changefeed.md renamed to src/current/_includes/v25.1/cdc/create-sinkless-changefeed.md

@@ -19,9 +19,9 @@ In this example, you'll set up a basic changefeed for a single-node cluster.
     --format=csv
     ~~~
 
-    {% include {{ page.version.version }}/cdc/core-url.md %}
+    {% include {{ page.version.version }}/cdc/sinkless-url.md %}
 
-    {% include {{ page.version.version }}/cdc/core-csv.md %}
+    {% include {{ page.version.version }}/cdc/sinkless-csv.md %}
 
 1. Enable the `kv.rangefeed.enabled` [cluster setting]({% link {{ page.version.version }}/cluster-settings.md %}):
 

src/current/_includes/v25.1/cdc/lagging-ranges.md

@@ -5,7 +5,7 @@ Use the `changefeed.lagging_ranges` metric to track the number of [ranges]({% li
 - `lagging_ranges_polling_interval` sets the interval rate for when lagging ranges are checked and the `lagging_ranges` metric is updated. Polling adds latency to the `lagging_ranges` metric being updated. For example, if a range falls behind by 3 minutes, the metric may not update until an additional minute afterward.
     - **Default:** `1m`
 
-Use the `changefeed.total_ranges` metric to monitor the number of ranges that are watched by [aggregator processors]({% link {{ page.version.version }}/how-does-an-enterprise-changefeed-work.md %}) participating in the changefeed job. If you're experiencing lagging ranges, `changefeed.total_ranges` may indicate that the number of ranges watched by aggregator processors in the job is unbalanced. You may want to try [pausing]({% link {{ page.version.version }}/pause-job.md %}) the changefeed and then [resuming]({% link {{ page.version.version }}/resume-job.md %}) it, so that the changefeed replans the work in the cluster. `changefeed.total_ranges` shares the same polling interval as the `changefeed.lagging_ranges` metric, which is controlled by the `lagging_ranges_polling_interval` option.
+Use the `changefeed.total_ranges` metric to monitor the number of ranges that are watched by [aggregator processors]({% link {{ page.version.version }}/how-does-a-changefeed-work.md %}) participating in the changefeed job. If you're experiencing lagging ranges, `changefeed.total_ranges` may indicate that the number of ranges watched by aggregator processors in the job is unbalanced. You may want to try [pausing]({% link {{ page.version.version }}/pause-job.md %}) the changefeed and then [resuming]({% link {{ page.version.version }}/resume-job.md %}) it, so that the changefeed replans the work in the cluster. `changefeed.total_ranges` shares the same polling interval as the `changefeed.lagging_ranges` metric, which is controlled by the `lagging_ranges_polling_interval` option.
 
 {{site.data.alerts.callout_success}}
 You can use the [`metrics_label`]({% link {{ page.version.version }}/monitor-and-debug-changefeeds.md %}#using-changefeed-metrics-labels) option to track the `lagging_ranges` and `total_ranges` metric per changefeed.

src/current/_includes/v25.1/cdc/core-csv.md renamed to src/current/_includes/v25.1/cdc/sinkless-csv.md

@@ -139,9 +139,9 @@
     "title": "Technical Overview",
     "items": [
         {
-          "title": "How Does an Enterprise Changefeed Work?",
+          "title": "How Does a Changefeed Work?",
           "urls": [
-            "/${VERSION}/how-does-an-enterprise-changefeed-work.html"
+            "/${VERSION}/how-does-a-changefeed-work.html"
           ]
         }
       ]

src/current/_includes/v25.1/cdc/core-url.md renamed to src/current/_includes/v25.1/cdc/sinkless-url.md

@@ -284,7 +284,7 @@ This is the usage for any data leaving CockroachDB such as SQL data being sent t
 
 ### Change data capture (changefeeds)
 
-For change data capture (CDC), all CockroachDB {{ site.data.products.cloud }} clusters can use [Enterprise changefeeds]({% link {{ site.current_cloud_version}}/how-does-a-changefeed-work.md %}).
+For change data capture (CDC), all CockroachDB {{ site.data.products.cloud }} clusters can use [changefeeds]({% link {{ site.current_cloud_version}}/how-does-a-changefeed-work.md %}).
 
 <section class="filter-content" markdown="1" data-scope="basic">
 

src/current/_includes/v25.1/sidebar-data/stream-data.json

@@ -63,13 +63,13 @@ Adjusting `kv.closed_timestamp.target_duration` could have a detrimental impact
 
 `kv.closed_timestamp.target_duration` controls the target [closed timestamp]({% link {{ page.version.version }}/architecture/transaction-layer.md %}#closed-timestamps) lag duration, which determines how far behind the current time CockroachDB will attempt to maintain the closed timestamp. For example, with the default value of `3s`, if the current time is `12:30:00` then CockroachDB will attempt to keep the closed timestamp at `12:29:57` by possibly retrying or aborting ongoing writes that are below this time.
 
-A changefeed aggregates checkpoints across all ranges, and once the timestamp on all the ranges advances, the changefeed can then [checkpoint]({% link {{ page.version.version }}/how-does-an-enterprise-changefeed-work.md %}). In the context of changefeeds, `kv.closed_timestamp.target_duration` affects how old the checkpoints will be, which will determine the latency before changefeeds can consider the history of an event complete.
+A changefeed aggregates checkpoints across all ranges, and once the timestamp on all the ranges advances, the changefeed can then [checkpoint]({% link {{ page.version.version }}/how-does-a-changefeed-work.md %}). In the context of changefeeds, `kv.closed_timestamp.target_duration` affects how old the checkpoints will be, which will determine the latency before changefeeds can consider the history of an event complete.
 
 #### `kv.rangefeed.closed_timestamp_refresh_interval`
 
 **Default:** `3s`
 
-This setting controls the interval at which [closed timestamp]({% link {{ page.version.version }}/architecture/transaction-layer.md %}#closed-timestamps) updates are delivered to [rangefeeds]({% link {{ page.version.version }}/create-and-configure-changefeeds.md %}#enable-rangefeeds) and in turn emitted as a [changefeed checkpoint]({% link {{ page.version.version }}/how-does-an-enterprise-changefeed-work.md %}).
+This setting controls the interval at which [closed timestamp]({% link {{ page.version.version }}/architecture/transaction-layer.md %}#closed-timestamps) updates are delivered to [rangefeeds]({% link {{ page.version.version }}/create-and-configure-changefeeds.md %}#enable-rangefeeds) and in turn emitted as a [changefeed checkpoint]({% link {{ page.version.version }}/how-does-a-changefeed-work.md %}).
 
 Increasing the interval value will lengthen the delay between each checkpoint, which will increase the latency of changefeed checkpoints, but reduce the impact on SQL latency due to [overload]({% link {{ page.version.version }}/admission-control.md %}#use-cases-for-admission-control) on the cluster. This happens because every range with a rangefeed has to emit a checkpoint event with this `3s` interval. As an example, 1 million ranges would result in 330,000 events per second, which would use more CPU resources.
 
@@ -117,7 +117,7 @@ Before tuning these settings, we recommend reading details on our [changefeed at
 
 ### Pausing changefeeds and garbage collection
 
-By default, [protected timestamps]({% link {{ page.version.version }}/architecture/storage-layer.md %}#protected-timestamps) will protect changefeed data from [garbage collection]({% link {{ page.version.version }}/architecture/storage-layer.md %}#garbage-collection) up to the time of the [_checkpoint_]({% link {{ page.version.version }}/how-does-an-enterprise-changefeed-work.md %}). Protected timestamps will protect changefeed data from garbage collection if the downstream [changefeed sink]({% link {{ page.version.version }}/changefeed-sinks.md %}) is unavailable until you either [cancel]({% link {{ page.version.version }}/cancel-job.md %}) the changefeed or the sink becomes available once again.
+By default, [protected timestamps]({% link {{ page.version.version }}/architecture/storage-layer.md %}#protected-timestamps) will protect changefeed data from [garbage collection]({% link {{ page.version.version }}/architecture/storage-layer.md %}#garbage-collection) up to the time of the [_checkpoint_]({% link {{ page.version.version }}/how-does-a-changefeed-work.md %}). Protected timestamps will protect changefeed data from garbage collection if the downstream [changefeed sink]({% link {{ page.version.version }}/changefeed-sinks.md %}) is unavailable until you either [cancel]({% link {{ page.version.version }}/cancel-job.md %}) the changefeed or the sink becomes available once again.
 
 However, if the changefeed lags too far behind, the protected changes could lead to an accumulation of garbage. This could result in increased disk usage and degraded performance for some workloads.
 
@@ -175,7 +175,7 @@ When designing a system that needs to emit a lot of changefeed messages, whether
 
 When a changefeed emits a [resolved]({% link {{ page.version.version }}/create-changefeed.md %}#resolved) message, it force flushes all outstanding messages that have buffered, which will diminish your changefeed's throughput while the flush completes. Therefore, if you are aiming for higher throughput, we suggest setting the duration higher (e.g., 10 minutes), or **not** using the `resolved` option.
 
-If you are setting the `resolved` option when you are aiming for high throughput, you must also consider the [`min_checkpoint_frequency`]({% link {{ page.version.version }}/create-changefeed.md %}#min-checkpoint-frequency) option, which defaults to `30s`. This option controls how often nodes flush their progress to the [coordinating changefeed node]({% link {{ page.version.version }}/how-does-an-enterprise-changefeed-work.md %}). As a result, `resolved` messages will not be emitted more frequently than the configured `min_checkpoint_frequency`. Set this option to at least as long as your `resolved` option duration.
+If you are setting the `resolved` option when you are aiming for high throughput, you must also consider the [`min_checkpoint_frequency`]({% link {{ page.version.version }}/create-changefeed.md %}#min-checkpoint-frequency) option, which defaults to `30s`. This option controls how often nodes flush their progress to the [coordinating changefeed node]({% link {{ page.version.version }}/how-does-a-changefeed-work.md %}). As a result, `resolved` messages will not be emitted more frequently than the configured `min_checkpoint_frequency`. Set this option to at least as long as your `resolved` option duration.
 
 ### Batching and buffering messages
 

src/current/cockroachcloud/costs.md

@@ -63,7 +63,7 @@ Function                  | Description
 --------------------------+----------------------
 `changefeed_creation_timestamp()` | Returns the decimal MVCC timestamp when the changefeed was created. Use this function to build CDC queries that restrict emitted events by time. `changefeed_creation_timestamp()` can serve a similar purpose to the [`now()` time function]({% link {{ page.version.version }}/functions-and-operators.md %}#date-and-time-functions), which is not supported with CDC queries.
 `event_op()`              | Returns a string describing the type of event. If a changefeed is running with the [`diff`]({% link {{ page.version.version }}/create-changefeed.md %}#diff) option, then this function returns `'insert'`, `'update'`, or `'delete'`. If a changefeed is running without the `diff` option, it is not possible to determine an update from an insert, so `event_op()` returns [`'upsert'`](https://www.cockroachlabs.com/blog/sql-upsert/) or `'delete'`.
-`event_schema_timestamp()` | Returns the timestamp of [schema change]({% link {{ page.version.version }}/online-schema-changes.md %}) events that cause a [changefeed message]({% link {{ page.version.version }}/changefeed-messages.md %}) to emit. When the schema change event does not result in a table backfill or scan, `event_schema_timestamp()` will return the event's timestamp. When the schema change event does result in a table backfill or scan, `event_schema_timestamp()` will return the timestamp at which the backfill/scan is read — the [high-water mark time]({% link {{ page.version.version }}/how-does-an-enterprise-changefeed-work.md %}) of the changefeed.
+`event_schema_timestamp()` | Returns the timestamp of [schema change]({% link {{ page.version.version }}/online-schema-changes.md %}) events that cause a [changefeed message]({% link {{ page.version.version }}/changefeed-messages.md %}) to emit. When the schema change event does not result in a table backfill or scan, `event_schema_timestamp()` will return the event's timestamp. When the schema change event does result in a table backfill or scan, `event_schema_timestamp()` will return the timestamp at which the backfill/scan is read — the [high-water mark time]({% link {{ page.version.version }}/how-does-a-changefeed-work.md %}) of the changefeed.
 
 You can also use the following functions in CDC queries: