Skip to content
Snippets Groups Projects

GitLab CI/CD scalability improvements blueprint

Merged Grzegorz Bizon requested to merge architecture/gb/improve-ci-builds-data-model into master
All threads resolved!
@@ -9,16 +9,10 @@ description: 'Improvements to CI/CD builds data storage model'
## Summary
<!-- vale gitlab.ReferenceLinks = NO -->
GitLab CI/CD is one of the most data and compute intensive components features.
Since its [initial release in November 2012][1], the CI/CD subsystem has
evolved significantly. It was [integrated into GitLab in September 2015][2] and
has become [one of the most beloved CI/CD solutions][3].
[1]: https://about.gitlab.com/blog/2012/11/13/continuous-integration-server-from-gitlab/
[2]: https://about.gitlab.com/releases/2015/09/22/gitlab-8-0-released/
[3]: https://about.gitlab.com/blog/2017/09/27/gitlab-leader-continuous-integration-forrester-wave/
Since its [initial release in November 2012](https://about.gitlab.com/blog/2012/11/13/continuous-integration-server-from-gitlab/),
the CI/CD subsystem has evolved significantly. It was [integrated into GitLab in September 2015](https://about.gitlab.com/releases/2015/09/22/gitlab-8-0-released/)
and has become [one of the most beloved CI/CD solutions](https://about.gitlab.com/blog/2017/09/27/gitlab-leader-continuous-integration-forrester-wave/).
GitLab CI/CD has come a long way since the initial release, but the design of
the data storage for pipeline builds remains almost the same since 2012. We
@@ -26,8 +20,6 @@ store all the builds in PostgreSQL in `ci_builds` table, and because we are
creating more than 0.5 million builds each day on GitLab.com, we are reaching
database limits that are slowing our development velocity down.
<!-- vale gitlab.ReferenceLinks = YES -->
## Goals
1. Transition primary key for `ci_builds` to 64-bit integer
Loading