GitLab is offered as a Single Application with a Single data-store. This handbook entry is meant as guidance for when you encounter a situation where you are considering changes or additions to our data-store architecture. For information on tooling, migrations, debugging and best practices please read the Database guides section in GitLab Docs.
When you propose any database additions, updates or deletions it is required that you have participated in a Database Review prior to deployment (best early in development).
Over time there have been proposals to use different types of data-stores (e.g. NoSQL). At this point we are not considering adding another data-store for our persistent data. Please read Single data-store.
We are intentionally requiring that the data for GitLab lives in a single data-store, in this case that means a single database. The term "database" can be taken many different ways. Here is how we are using the following terms:
Often, moving to a separate service or microservice is seen as a solution to a scaling or performance problem within the GitLab application. However, moving to a microservice based solution may simply be defering the problem while creating a more complex architecture. The articles and quotes below discuss real world examples of the struggles with microservices.
"If microservices are implemented incorrectly or used as a band-aid without addressing some of the root flaws in your system, you'll be unable to do new product development because you're drowning in the complexity."
Maintaining a bunch of loose microservices is not easier than maintaining a monolith. There might be an argument for moving from a distributed monolith to microservices, provided that the organizational problems that led to a distributed monolith have been addressed. A shift to microservices is likely to make things worse before it makes them better. If things are already bad, that’s going to make life difficult.
As we've learned from our discussions around defining the container registry database schema there are times when it makes sense to separate the data out into its own database. The following sections will describe what data points you should consider and how you would move forward in gaining approval to create a separate database.
If you answered yes to all of the questions in the Considerations section above, then you will need to get approval for your separate database design before proceeding with implementation.