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 Group:
The following people are permanent members of the Database Group:
| Person | Role |
|---|---|
| Craig Gomes | Backend Engineering Manager, Database |
| Andreas Brandl | Staff Backend Engineer, Database |
| Patrick Bair | Senior Backend Engineer, Database |
| Yannis Roussos | Senior Backend Engineer, Database |
The following members of other functional teams are our stable counterparts:
| Person | Role |
|---|
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.
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. For the foreseeable future, the team will be focusing on database partitioning and sharding. 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.
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 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 mileston 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 milesone.
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.
