Data Access Sub Department

Vision

Provide other groups with well-designed interfaces and patterns for efficient data access that is scalable, reliable, performant, and sustainable for the long term.

All Team Members

The following people are permanent members of teams that belong to the Data Access Sub-department:

Database Framework

The [Database Framework]((/handbook/engineering/infrastructure-platforms/data-access/database-framework/) team develops solutions for scalability, application performance, data growth and developer enablement especially where it concerns interactions with the database.

Name Role
Alex IvesAlex Ives Backend Engineering Manager, Database
Backend EngineerBackend Engineer Backend Engineer, Database
Jon JenkinsJon Jenkins Senior Backend Engineer, Database
Krasimir AngelovKrasimir Angelov Staff Backend Engineer, Database
Leonardo da RosaLeonardo da Rosa Backend Engineer, Database
Matt KasaMatt Kasa Staff Backend Engineer, Database
Maxime OreficeMaxime Orefice Senior Backend Engineer, Database
Prabakaran MurugesanPrabakaran Murugesan Senior Backend Engineer, Database
Simon TomlinsonSimon Tomlinson Staff Backend Engineer, Database

Database Operations

The Database Operations team builds, runis, and owns the entire lifecycle of the PostgreSQL database engine for GitLab.com.

Name Role
Rick MarRick Mar Engineering Manager, Database Reliability
Alexander SosnaAlexander Sosna Senior Database Reliability Engineer
Biren ShahBiren Shah Senior Database Reliability Engineer
Jon SissonJon Sisson Senior Site Reliability Engineer
Rafael HenchenRafael Henchen Senior Database Reliability Engineer

Durability

The Durability team is dedicated to safeguarding and securing customer data that is stored by the GitLab application and set guidelines for data access. We strive to build and maintain resilient infrastructure and improve the management of Redis, Sidekiq, and Gitaly.

Name Role
John 'Jarv' JarvisJohn 'Jarv' Jarvis Staff Site Reliability Engineer

Gitaly

The Gitaly team builds and maintains systems to ensure Git data of GitLab instances, and GitLab.com in particular, is reliable, secure and fast.

Name Role
John CaiJohn Cai Engineering Manager, Gitaly
Christian CouderChristian Couder Staff Backend Engineer, Gitaly
Divya RaniDivya Rani Backend Engineer, Gitaly
Emily ChuiEmily Chui Senior Backend Engineer, Gitaly
Eric JuEric Ju Senior Backend Engineer, Gitaly
James FargherJames Fargher Senior Backend Engineer, Gitaly
James LiuJames Liu Senior Backend Engineer, Gitaly
Karthik NayakKarthik Nayak Senior Backend Engineer, Gitaly
Mustafa BayarMustafa Bayar Backend Engineer, Gitaly
Quang-Minh NguyenQuang-Minh Nguyen Staff Backend Engineer, Gitaly and Tenant Scale
Raynard OmongbaleRaynard Omongbale Site Reliability Engineer
Sami HiltunenSami Hiltunen Staff Backend Engineer, Gitaly
Toon ClaesToon Claes Senior Backend Engineer, Gitaly

Git

The Git team develops Git in accordance with the goals of the community and GitLab, and integrate it into our products.

Name Role
Patrick SteinhardtPatrick Steinhardt Acting Engineering Manager, Git

Data Access Durability Team

Mission

The mission of the Durability team is dedicated to safeguarding and securing customer data that is stored by the GitLab application and set guidelines for data access. We strive to build and maintain resilient infrastructure and improve the management of Redis, Sidekiq, and Gitaly.

Ownership

The team has ownership over the following areas of the GitLab product:

  1. Reliable backup and restore solutions for all environments where GitLab is deployed.
  2. Data management and performance for Sidekiq and Redis.
  3. Infrastructure support for the Gitaly service.

Services

Durability is responsible for infrastructure that supports the following GitLab application services:

Database Framework Group

Vision

Developing solutions for scalability, application performance, data growth and developer enablement especially where it concerns interactions with the database.

Mission

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.

Database Operations Team

Mission

The Database Operations team at GitLab mission is to Build, Run and Own the entire lifecycle of the PostgreSQL database engine for GitLab.com.

The team is focused on owning the reliability, scalability, performance & security of the database engine and its supporting services. The team should be seeking to build their services on top of Reliability::Foundations services and cloud vendor managed products, where appropriate, to reduce complexity, improve efficiency and deliver new capabilities quicker.

Git Team

Mission statement

The Git team is responsible for building, maintaining and providing expertise on the Git version control system. Its main responsibilities include:

  • Upstream development of the Git version control system.
  • Provide expertise to other teams at GitLab.
  • Foster the Git community.
  • Ensure the long-term viability of the Git project.

Upstream development

The Git team is responsible for driving the upstream development of Git both in accordance with the goals of the community and to address GitLab-specific needs as raised by other teams. This falls into the following broad categories:

Gitaly Team

What is Gitaly?

The Gitaly team is responsible for building and maintaining systems to ensure that the Git data storage tier of GitLab instances, and GitLab.com in particular, is reliable, secure and fast. For more information about Gitaly, see the README in the repository and the roadmap below.

The team includes Backend Engineers and SREs collaborating to deliver a reliable, scalable and fast data storage to our customers.

Functional boundary

While GitLab is the primary consumer of the Gitaly project, Gitaly is a standalone product which can be used external to GitLab. As such, we strive to achieve a functional boundary around Gitaly. The goal of this is to ensure that the Gitaly project creates an interface to manage Git data, but does not make business decisions around how to manage the data.

Last modified November 13, 2024: Move gitaly pages over to data access (c16c2006)