diff --git a/050-Manage/030-migrations.mdx b/050-Manage/030-migrations.mdx index 464b73c0..dfb5111d 100644 --- a/050-Manage/030-migrations.mdx +++ b/050-Manage/030-migrations.mdx @@ -73,11 +73,11 @@ Migration files should not be modified. If externally modified, the record will Migrations must be ordered. Ordering is guaranteed by the `parent` and the ledger file, which is stored in `.xata/migrations/.ledger`. The ledger file is an append only file that lists all migration files in the correct order. -## Multi-version Schema (Postgres enabled branches only) +## Multi-version Schema Migrations (Postgres enabled branches only) -For Postgres enabled branches, the Web UI provides a Migration Editor to create [multi-version schema](https://xata.io/blog/schema-multi-version-launch-week) using [pgroll](https://github.com/xataio/pgroll) operations. +For Postgres enabled branches, the Web UI provides a Migration Editor to create [multi-version schema migrations](https://xata.io/blog/schema-multi-version-launch-week) using [pgroll](https://github.com/xataio/pgroll) operations. -Multi-version schema address the pain point of having to keep your application code in sync with your database schema by allowing you two active database schemas at once. With multi-version schema migrations, running a migration means being able to preview the new version of your schema alongside the old one. Reading and writing data in both schemas continues to work normally. As a result of having two active schema versions, rollbacks become seamless operations which is particularly useful in the case of an unwanted schema change or backfill. +Multi-version schema migrations address the pain point of having to keep your application code in sync with your database schema by allowing you two active database schemas at once. With multi-version schema migrations, running a migration means being able to preview the new version of your schema alongside the old one. Reading and writing data in both schemas continues to work normally. As a result of having two active schema versions, rollbacks become seamless operations which is particularly useful in the case of an unwanted schema change or backfill. Currently multi-version schema migrations are only supported via the Migration Editor in the UI. Migrations made via