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
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.