Hi team, is there way to commit multiple table schema change operation in a single transaction? Currently, our cluster has a lot of long-running streaming load operations, this makes schema change operation has a very limited window to be processed (instead, stuck in WAITING_TXN state). This makes delivery of multiple schema change statements in one go rather difficult, as alembic has to retry indefinitely, in order for multiple schema change statements to be sent to Starrocks. • Next schema change operation is pending on pervious statement to be completely, previous alter statement is pending on on-going transactions. In general, we don't care how long for the schema change to finish, but rather for Alembic to be able to submit multiple statements to Starrocks without having to manually retrying to deliver subsequent alter statements. Is this somehow possible with the current Starrocks (e.g. 4.0.x)?

Hi @Tiasnu Based on the latest StarRocks 4.0.x documentation, the current limitation is that each table can only have one ongoing schema change operation at a time. Reference: ALTER TABLE | StarRocks

One table can have only one ongoing schema change operation at a time. You cannot run two schema change commands on a table at the same time.

This means schema changes must be executed sequentially. However, if you're not currently using "fast_schema_evolution" = "true", enabling this property can significantly reduce the time spent on each schema change operation, thereby improving your overall migration workflow. Important Notes: • Fast Schema Evolution was introduced in StarRocks v3.2 for shared-nothing clusters • If you're using a shared-data architecture (Lake Table), this feature is automatically enabled by default - no manual configuration needed • v4.0+ includes an optimization that retains history schemas until all dependent ingestion jobs are finished, providing better stability during schema changes with concurrent data loading For shared-nothing clusters running v3.2+, you can enable this feature at table creation: CREATE TABLE example (...) PROPERTIES ("fast_schema_evolution" = "true");

Thanks, Edward. We are on shared-data, so I think the feature as you have mentioned, is already enabled. I have a rough idea on overcoming this on alembic side, by altering operation generation workflow and adding waiting and retry mechanism on the execution path as well, to make the process as painless as possible.

Hi @Tiasnu, That sounds like a solid approach on the Alembic side! Just one important thing to note: There's been active development on FSE v2 for shared-data mode on the

main

branch (PR #66774, along with supporting PRs #66699, #67443, #67456). With FSE v2, simple ADD/DROP COLUMN operations update only FE metadata instantly — no schema change job is created, the table state stays

NORMAL

, and consecutive ALTERs can be submitted immediately. Thanks.

Thanks, thats indeed a great improvement. We quite often have to update table order key, indexes, etc. during performance tuning, so I think the alembic tweaking is still needed for now. The PRs you have shared indeed would bring these kind of overheads down to a minimal 🚀