Developing solutions for scalability, application performance, data growth and developer enablement especially where it concerns interactions with the database.
Focusing on the database, our mission is to provide solutions that allow us to scale to our customer's demands. To provide tooling to proactively identify performance bottlenecks to inform developers early in the development lifecycle. To increase the number of database maintainers and provide database best practices to the community contributors and development teams within GitLab.
The following people are permanent members of the Database Team:
| Person | Role |
|---|---|
| Craig Gomes | Backend Engineering Manager, Database and Sharding |
| Alex Ives | Senior Backend Engineer, Database |
| Andreas Brandl | Staff Backend Engineer, Database |
| Diogo Frazão | Backend Engineer, Database |
| Krasimir Angelov | Senior Backend Engineer, Database |
| Patrick Bair | Senior Backend Engineer, Database |
| Simon Tomlinson | Senior Backend Engineer, Database |
The following members of other functional teams are our stable counterparts:
| Person | Role |
|---|---|
| Fabian Zimmer | Principal Product Manager, Geo |
The Database Group is often called upon to provide consulting to other groups. To more efficiently support these requests we have created this stable counterparts table.
Whenever possible, we prefer to communicate asynchronously using issues, merge requests, and Slack. However, face-to-face meetings are useful to establish personal connection and to address items that would be more efficiently discussed synchronously such as blockers.
~infradev issues requiring reviews, then we focus on weekly priorities.We follow the GitLab engineering workflow guidelines. To bring an issue to our attention please create an issue in the relevant project. Add the ~"group::database" label along with any other relevant labels. If it is an urgent issue, please reach out to the Product Manager or Engineering Manager listed in the Stable Counterparts section above.
The team is responsible for the PostgreSQL application interactions to enable high performance queries while offering features to support scalability and strengthen availability. PostgreSQL is the heart of Rails application, and there is no shortage of work to make GitLab more performant, scalable, and highly available from database perspective. Some of the current priorities include implementing partitioning to improve query performance and creating tooling to enable development teams to implement their own partitioning strategies more easily. We are working on tools that will help developers "shift left" in their migration testing prior to deployment. We are always looking for ways to continuously care for the performance of our databsae and improve our developer documentation. For more in-depth details of what we are working on please review our Roadmap section below.
We use a planning issue to discuss priorities and commitments for the milestone. This happens largely asynchronously, but when we do need to discuss synchronously we discuss during the Tuesday team meeting timeslot.
We have a fairly simple triage rotation. Each week one team member is dedicated to triaging incoming issues for the database group. This allows for the rest of the team to focus on their current priorities with fewer interruptions. During the first sync meeting of the week the current team member on triage rotation will hand off triage to the next team member. We order the triage rotation by alpha-order based on first name to keep it very simple.
Issues needing triage can come in through many different paths. Some common areas to monitor while on triage:
~database label that are not assigned to a group. Example search~group::database but do not have the ~database::active or ~database::triage labels. Example search~database::triage and have not previously been reviewedWhen the triage team member discovers an issue requiring team attention some of the possible outcomes are:
~database::triage label and review during team sync meeting~database::active issue and escalateThe goal is to keep the number of issues for triage low and manageable.
Tip: In order to remove closed issues from the triage board, use this search and edit multiple issues at once to remove the ~database::triage label.
Database by Milestone The Milestone board gives us a "big picture" view of issues planned in each milestone.
Database: Build · Boards · GitLab.org · GitLab The build board gives you an overview of the current state of work for group::database. These issues have already gone through validation and are on the Product Development Build Track. Issues are added to this board by adding the database::active and group::database labels. Issues in the workflow::ready for development column are ordered in priority order (top down). Team members use this column to select the next item to work on.
Database: Validation The validation board is a queue for incoming issues for the Product Manager to review. A common scenario for the Database Team validation board is when an issue is created that requires further definition before it can be prioritized. The issue typically states a big picture idea but is not yet detailed enough to take action. The Database Team will then go through a refinement process to break down the issue into actionable steps, create exit criteria and prioritize against ongoing efforts. If an issue becomes too large, it will be promoted to an epic and small sub-issues will be created.
Database: Triage The triage board is for incoming issues that require further investigation for team assignment, prioritization, previously existing issues, etc. Within the Database Group we have implemented a weekly triage rotation where one team member is responsible for monitoring this board for timely responses.
We use the ~Deliverable label to track our Say/Do ratio. At the beginning of each milestone, during a Database Group Weekly meeting, we review the issues and determine those issues we are confident we can deliver within the milestone. The issue will be marked with the ~Deliverable label. At the end of the milestone the successfully completed issues with the ~Deliverable label are tracked in two places. We have a dashboard in Sisense that will calculate how many were delivered within the milestone and account for issues that were moved. Additionally, our milestone retro issue lists all of the ~Deliverable issues shipped along with those that missed the milestone.
The Database Group Roadmap gives a view of what is currently in flight as well as projects that have been prioritized for the next 3+ months.
We document our insights, road maps and other relevant material in this section.
