Hi team and @Rocky, what do you usually use for schema migrations on StarRocks? I’ve used Flyway for other databases, but it seems not to support StarRocks (or at least it’s incompatible when connecting via the StarRocks MySQL endpoint. Flyway fails on MySQL system-variable checks like

foreign_key_checks

). Curious what the recommended / standard approach is here (Liquibase, Alembic, custom runner, etc.).

While Flyway is a popular choice for traditional RDBMS, it often runs into compatibility issues with StarRocks because it attempts to set MySQL-specific session variables (like

foreign_key_checks

or

storage_engine

) that StarRocks does not support or requires for its own internal logic. For schema migrations and version control on StarRocks, the following approaches are standard and recommended: *1. Liquibase (with StarRocks Extension)* Liquibase is highly recommended because there is a dedicated community-supported extension:

liquibase-starrocks

. • Why it works: Unlike the generic MySQL connector, the StarRocks extension understands StarRocks-specific syntax (like

DISTRIBUTED BY

,

PROPERTIES

, etc.) and avoids attempting to set incompatible MySQL system variables. • How to use: You can find the extension on GitHub (search for

StarRocks/liquibase-starrocks

). You add the JAR to your Liquibase

lib

folder and use the

starrocks

database type in your connection string. *2. dbt (data build tool)* If your "migrations" are primarily about evolving your data warehouse schema (tables, views, materialized views),

dbt-starrocks

is the most common approach in the StarRocks ecosystem. • Why it works: dbt treats your schema as code. Instead of incremental "up/down" migration scripts, you define the desired state of your models, and dbt handles the creation/replacement of tables. • Best for: Environments where you are doing heavy data transformation and want to keep your schema in sync with your logic. *3. Alembic (Python / SQLAlchemy)* If you are coming from a Python background, you can use Alembic along with the

sqlalchemy-starrocks

dialect. • This allows you to write migrations in Python and handles the translation to StarRocks-compatible SQL. *4. Flyway (Workaround)* If you must use Flyway, you can try to bypass the system variable checks by using the Flyway "Script" config or a custom database type, but it is often uphill work. The failure you see (

foreign_key_checks

) is because StarRocks does not enforce foreign keys (though it allows declaring them for optimization in v3.2+), and it doesn't support the

SET foreign_key_checks

session variable. *5. Custom SQL Runner (CI/CD)* Many teams opt for a simple, custom approach using a CI/CD pipeline (GitHub Actions, GitLab CI) that executes

.sql

scripts via the standard

mysql

CLI client. • You maintain a

migrations

folder with files like

V1*init.sql

,

V2*add_column.sql

. • A simple wrapper script tracks which files have been executed in a metadata table (e.g.,

schema_version

). Summary Recommendation * For Java/Generic DevOps: Use Liquibase with the

starrocks

extension. * For Analytics/Data Engineering: Use dbt with the

dbt-starrocks

adapter. * For Python apps: Use Alembic with the StarRocks SQLAlchemy dialect. References • sql-reference/System_variable.md • sql-reference/sql-functions/Window_function.md • sql-reference/information_schema/verbose_session_variables.md