Decomposing the GitLab backend database, Part 1: Designing and planning

What this post added

This post details the initial design and planning phase for decomposing the GitLab backend database. It covers the motivation for splitting the monolithic Postgres database, the analysis of write traffic to identify CI tables as a primary candidate for extraction, the proof-of-concept process, and strategies for managing the 'moving target' of application evolution during the decomposition. It also highlights the development of tools like multiple databases documentation, cross-join detection, cross-database transaction detection, query analyzer metrics, and a Rubocop rule to ensure code compatibility. The implementation of loose foreign keys to handle inter-database relationships and the mirroring of `projects` and `namespaces` tables to the CI database are also discussed.