Commit 2a09c693 authored by Niko Belokolodov's avatar Niko Belokolodov 1️⃣
Browse files

Self-Managed Database Experience: add migration testing to scope, update stage page text

parent 65aee009
Loading
Loading
Loading
Loading
+5 −4
Changes for content/handbook/engineering/data-engineering/database-excellence/_index.md: 5 added lines, 4 removed lines.
Original line number Diff line number Diff line
@@ -29,13 +29,14 @@ Priorities:

### Self-Managed Database Experience

The [Self-Managed Database Experience](/handbook/engineering/data-engineering/database-excellence/self-managed-database-experience/) group provides the monitoring, observability, and health frameworks that keep databases healthy across both GitLab.com and self-managed deployments, including shift-left identification of saturation points.
The [Self-Managed Database Experience](/handbook/engineering/data-engineering/database-excellence/self-managed-database-experience/) group gives self-managed customers visibility into the state of their database, faster database migrations, and a clear upgrade path.

Priorities:

* Maintaining operational runway by proactively managing database saturation points
* Providing visibility into database health across all deployment types
* Optimizing database resource utilization and cost efficiency
* Checking database integrity before an upgrade, and database health between upgrades
* Testing every migration against data before it reaches customers
* Showing administrators their upgrade path, based on the data of their own instance
* Shortening upgrades by running migrations in dependency order, without intermediate stops

{{< group-by-slugs nbelokolodov amsingh6 imanpalsingh krasimirangelov >}}

+6 −2
Changes for content/handbook/engineering/data-engineering/database-excellence/self-managed-database-experience/_index.md: 6 added lines, 2 removed lines.
Original line number Diff line number Diff line
@@ -11,14 +11,18 @@ The Self-Managed Database Experience team formed in September 2026 from the self

We give self-managed administrators visibility into the state of their database, so they can upgrade with confidence and keep the database healthy between upgrades. Before an upgrade, we check the integrity of the database, its objects, and its configuration. Between upgrades, we check the performance and operation of the database. We make the database health and the severity of each problem available in the product, in one place for administrators and support. Detection is our commitment. Where possible, we also guide administrators to fix the problems we find, or fix them automatically. The result is fewer failed upgrades, fewer database incidents, and fewer database-related support tickets.

### Dependency graph migrations
### Migration testing

We speed up database migrations and reduce the time an upgrade takes for self-managed customers. Migrations run in the correct order, and independent migrations run at the same time. We move most of the migration work to before the maintenance window, so the downtime is short. Customers upgrade directly to their target version, without stops at intermediate versions. We make sure that the data stays correct after each upgrade.
We make sure that every migration is tested against data before it reaches customers. The multi-version upgrade test restores the database of the latest required stop and runs every newer migration against it. A migration that changes a table with no data in that database passes without being tested. We work with the feature teams that own the tables, so that every table has fixture data, and new tables cannot merge without it. The result is fewer migrations that fail for the first time during a customer upgrade.

### Upgrade path

We help self-managed administrators plan their upgrade. We show the upgrade path in the product, together with the migrations that the upgrade runs and how complex they are. We base this information on the data of the instance itself, not on general estimates, so administrators know how long the migrations can take and which migrations can affect performance. Administrators can then plan the maintenance window with confidence. The result is fewer unexpected delays during upgrades and fewer upgrade-related support tickets.

### Dependency graph migrations

We speed up database migrations and reduce the time an upgrade takes for self-managed customers. Migrations run in the correct order, and independent migrations run at the same time. We move most of the migration work to before the maintenance window, so the downtime is short. Customers upgrade directly to their target version, without stops at intermediate versions. We make sure that the data stays correct after each upgrade.

## Team

The team is composed of backend engineers with deep PostgreSQL and Rails migration experience. Regardless of role, all team members share stage-level responsibilities including database reviews, oncall rotations, and operational needs alongside the other Database Excellence teams.