Self-Managed Database Experience Team

The Self-Managed Database Experience team formed in September 2026 from the self-managed half of the Database Health team and the upgrade and migration work that had been planned for a separate Database Migrations team.

Scope

Database state visibility

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

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.

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.

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.

Name	Role
Niko Belokolodov	Senior Backend Engineer, Database Health
Amandeep Singh	Intermediate Backend Engineer, Database
Imanpal Singh	Backend Engineer, Database
Krasimir Angelov	Staff Backend Engineer, Database

Project management process

Our team uses a hybrid of Scrum to manage projects. This process follows the GitLab monthly milestone release cycle.

• We work only from issue boards. The issue boards are our single source of truth.
• We move issues to the next workflow stage continuously.
• We work on both product and engineering initiatives.
• We prioritize and estimate all issues that we work on.
• We plan each monthly milestone before it starts.
• We do weekly check-ins to share updates in the team.

Workflow

We use these build stage labels from the Product Development Flow:

Milestone planning and timeline

We follow the Product Development Timeline, because our work ships in the GitLab self-managed release cycle. We plan the next milestone in the last two weeks of the current milestone. Development starts when the next milestone starts.

Planning and breakdown phase

This phase starts two weeks before the end of the current milestone.

1. Initial planning
   1. PM: Creates the milestone planning issue and adds the objective and theme of the milestone.
   2. PM: Adds and prioritizes product issues.
   3. EM: Adds and prioritizes engineering issues and high-priority bugs.
   4. EM and PM: Make sure that only the issues in the planning issue are in the milestone.
2. Breakdown and weighing
   1. EM: Removes weights that are older than six months, and moves unweighed issues to ~"workflow::planning breakdown".
   2. Engineers: Add a solution proposal if there is none, add their estimation, ask questions, link blockers, and break down issues if necessary.
   3. EM: Moves estimated issues to ~"workflow::ready for development".
3. Final planning
   1. EM: Adds issues that will probably carry over from the current milestone.
   2. EM and PM: Add or remove issues based on weights.
   3. EM: Prioritizes the issues on the next milestone board.
   4. EM and PM: Present the plan in the last team sync of the current milestone.

Development phase

This phase starts on the first day of the new milestone.

• Engineers assign themselves to issues on the current milestone board in priority order, based on interest and experience.
• When no issues are left, engineers first help with issues that other engineers have. If there is nothing to help with, they tell the EM, who adds issues from the next milestone.

Milestone commitment

The milestone commitment is the list of issues that we aim to complete in the milestone. We plan ambitiously, so we do not always deliver everything.

Due dates

We sometimes add a due date to an issue to tell stakeholders when we expect to deliver it. A due date does not put pressure on the team. We also use due dates to timebox iterations. For example, a due date of one week instead of one month helps us find a smaller iteration.

Estimation

We estimate issues async. Each issue scheduled for an upcoming milestone gets an initial weight.

• Each issue needs two estimations. A ➕ reaction to an estimation counts as agreement. Exceptions are issues that come up during the milestone, or issues where only one engineer has the necessary knowledge.
• If the two estimations agree, the second engineer sets the weight. If they do not agree, the second engineer mentions the first engineer to resolve it.
• An estimation includes a proposed solution if the issue has none, or if the estimation suggests a different one. Spikes are an exception, and get a weight of 8 by default.
• If an issue has many unknowns, we estimate high.

We value velocity over predictability. Estimation helps us focus on the MVC and find blind spots. We aim for 70% predictability, not 90%.

See the unweighed upcoming issues.

Estimation examples

Estimation template

Engineers can use this template when they add an estimation to an issue.

### Refinement / Weighing

**Ready for Development**: Yes/No

<!--
Is the issue clear? Is it small enough, or can we break it into smaller issues? If so, how?
-->

**Weight**: X

**Reasoning**:

<!--
How can we break down this issue? Which code changes does it need? Link to prior art and similar examples.
-->

**Iteration MR/Issues Count**: Y

<!--
Can we split the issue into smaller issues or MRs? List them, and note any caveats.
-->

**Documentation required**: Yes/No

<!--
Do we need to add or change documentation?
-->

View page source - Edit this page - please contribute.