GitLab architecture: how GitLab scaled (2 case studies)
GitLab.com runs on PostgreSQL with Ruby on Rails. GitLab split its CI tables into their own Postgres database to relieve the main database, and traced replica stalls to Postgres subtransaction overflow, then removed subtransactions from its code.
We track 2 public engineering write-ups by GitLab, published between 2021 and 2022. They cover decomposition, query optimization, read replicas and vertical partitioning. Stack mentioned most: PostgreSQL (2) and Ruby on Rails (2). Each card below links to our short summary and the original post.
Tech used in GitLab's scaling write-ups
GitLab scaling timeline: every story, summarized
- 2021-09-29
Why we spent the last month eliminating PostgreSQL subtransactions
GitLab traced replica stalls to Postgres subtransaction overflow and removed subtransactions from its code.
- 2022-06-02
We are splitting our database into Main and CI
GitLab.com split CI tables into their own Postgres database to relieve its main database.
FAQ
What database does GitLab use?
PostgreSQL, in both GitLab posts we track. In 2022 GitLab.com split CI tables out of its main Postgres database into a separate CI database.
Why did GitLab eliminate PostgreSQL subtransactions?
GitLab's 2021 post traced stalls on its read replicas to Postgres subtransaction overflow, and the fix was removing subtransactions from its code.