CockroachDB 25.1 changes DDL transaction boundaries and replication pacing

A migration script can use familiar SQL while relying on transaction behavior that another database does not provide. CockroachDB 25.1 changes its default response to schema changes inside a transaction. It commits the current transaction before running the schema change separately, making the boundary explicit through a session setting.

The February 18 release notes cover SQL changes alongside replication controls and changefeed improvements. The common practical concern is how work moves between execution contexts. A schema change does not necessarily share a transaction with the DML before it, and a returning replica does not need to consume catch-up writes at the same rate as foreground traffic.

I like CockroachDB's serializable default because it makes consistency an architectural commitment. That does not mean every SQL operation belongs to one unrestricted transaction model. The 25.1 DDL change is important precisely because a database's isolation guarantee and the boundaries of an individual transaction are separate questions.

A schema statement commits preceding work by default

The 25.1 compatibility notes set autocommit_before_ddl to true by default. A schema statement sent during a transaction commits that transaction and runs the schema change in a separate transaction. The notes connect the decision to CockroachDB's incomplete support for multiple schema changes within one transaction.

This alters the meaning of a script that assumes an outer transaction makes every contained operation atomic. If preceding DML commits before a schema statement, a later failure cannot undo that earlier commit through the original transaction. The observation follows from the documented boundary, without requiring a particular migration framework or failure scenario.

The setting is a session variable, even though a feature-summary paragraph calls it a cluster setting. The compatibility section provides the role-default command for retaining the previous behavior:

ALTER ROLE ALL SET autocommit_before_ddl = false;

Changing this default preserves the earlier handling. It does not add general transactional support for combinations that CockroachDB already limits. The choice therefore concerns how unsupported or restricted combinations are encountered, as well as which statements can commit before another statement begins. For a migration runner, a transaction delimiter alone is no longer sufficient evidence that earlier changes remain reversible. The runner needs to account for the database committing at the schema statement, since its later error handling cannot restore atomicity across an already completed commit.

Type changes become an ordinary supported schema operation

The SQL feature summary marks ALTER COLUMN TYPE generally available. It describes compatibility with default values and virtual columns, and removes the need for a session variable to enable the capability. These changes reduce the extra setup associated with a common schema operation.

The ALTER TABLE reference documents changing a column's type through ALTER COLUMN. This is useful for migration authors because it provides a database operation with a defined syntax, rather than requiring every type adjustment to be modeled as an application-managed replacement column.

General availability does not make a type change part of every surrounding transaction. The new autocommit default still determines the boundary when the statement arrives during an active transaction. Support for an individual schema operation and support for composing several operations atomically need to be evaluated independently.

That separation matters even when the script contains no unusual SQL. Its author may be relying on the location of a commit more than on a particular type-conversion detail. The version's compatibility notes make that reliance something that can be reviewed directly in the migration's execution model.

Replication admission control distinguishes foreground and catch-up work

The admission-control reference describes pacing SQL writes at replica-quorum speed while pacing background replication at the slowest replica's speed. A replica returning after disconnection needs missed Raft entries, but sending them without pacing can overload the returning node.

The updated control separates these traffic classes. Foreground writes need the required quorum to progress. Background catch-up work needs to move at a rate the recovering replica can absorb. Making every write proceed at the slowest replica's rate would impose that replica's condition on a different class of work.

This is an availability concern within a system that already replicates correctly. Consensus describes which writes can commit, while admission control governs when resources are made available to process work. A returning node can require valid replication traffic and still be unable to ingest an unrestricted burst efficiently.

The KV feature summary identifies SQL-write admission control as a 25.1 capability. The useful claim is therefore about pacing during node restarts or joins. It does not remove the coordination required by replicated writes or turn a slow disk into a faster one.

I accept the latency of consensus because the consistency cost is visible. Admission control addresses another part of that tradeoff by deciding how competing work uses finite resources. It can preserve progress for useful work without pretending the system has unlimited write capacity.

Leader leases remain a preview with a different liveness basis

The replication-layer documentation describes leader leases as a preview. They use shared store-level failure detection and establish a fortified Raft leader as the leaseholder. A quorum of stores in the Raft group supports the leader's store liveness.

This changes the dependency used to determine whether lease authority can continue. The documentation describes a previous failure case where a leaseholder lost communication with followers but could still heartbeat the node-liveness range. Leader leases tie the relevant liveness support to the range's participating stores.

The distinction is architectural. Raft leadership and permission to serve requests need compatible failure assumptions. Making them coincide under a store-liveness mechanism allows the implementation to avoid reasoning about some combinations where the two authorities reside separately. The release summary's preview label remains part of the capability's status on this date.

Changefeed progress becomes easier to correlate with wall time

The changefeed feature summary adds a human-readable representation of the high-water timestamp to SHOW CHANGEFEED JOBS. The original numeric timestamp remains available. This changes how progress can be inspected without removing its existing representation.

The SHOW JOBS reference explains the high-water guarantee. All changes at or before that time have been emitted. It is consequently a progress boundary, rather than a claim that every individual consumer has completed its own downstream processing.

That interpretation matters when comparing a changefeed with another system's state. A readable time makes the boundary easier to understand, but it does not expand what the boundary guarantees. The operator still needs to distinguish emission by the changefeed from any later processing performed after the sink receives a message.

Database logic and feature activation have separate scopes

Version 25.1 also expands stored procedures and user-defined functions. Its SQL summary includes common table expressions inside routines, table-returning SQL functions and anonymous PL/pgSQL blocks. The DO reference supplies the syntax for running a block without creating a persistent routine.

For example, a small block can emit a notice using the documented form. It demonstrates block execution without claiming to perform a migration or measure database performance:

DO $$
BEGIN
    RAISE NOTICE 'Routine compatibility check';
END $$;

These additions reduce some differences encountered when moving database-side logic. They do not establish that every PostgreSQL routine is compatible. Each supported language construct still has its documented behavior, and transaction composition remains subject to the database's own restrictions.

The upgrade-finalization notes separately identify capabilities that require finalization, including the generally available type-change work and jobs-system changes. They also require an Enterprise or trial license before finalizing this upgrade. Installing binaries and enabling every new capability are therefore distinct stages.

The February release makes several operating decisions more explicit. Migration execution needs the intended DDL commit boundary, and recovering replicas need a paced path back into service. Those are concrete behaviors to carry into an upgrade design, alongside the particular SQL constructs that 25.1 makes available.