Explore unified Auxiliary Database Server approach for non-main databases to reduce deployment complexity

Problem Statement

Today's GitLab stack presents several database deployment scenarios, each with different location requirements:

• Single Node Omnibus - Co-located with main database
• Multi Node HA Omnibus - Separate single node non-HA (until omnibus-gitlab#7292 is addressed)
• Single Node Third Party - Co-located with main database
• Multi Node HA Third Party - Co-located with main database
• Geo (Single or Multi Node) - Separated to avoid replication conflicts, although it could be co-located on Primary

Praefect and Geo Tracking have partially established some precedents, though HA support was never added directly to GitLab packaging. With these deployments, separate databases were recommended for HA and Geo scenarios, although Geo Tracking could be co-located with Praefect.

As we add new databases, these nuances will continue to expand exponentially, creating a real risk of causing confusion for customers as well as our own teams and Support.

Proposal

We need clear, consistent guidance that keeps permutations to a minimum with well-defined deployment patterns.

If we require database separation for Geo deployments, we should develop a unified approach for all non-main replicated databases rather than asking customers to deploy numerous separate database servers for each individual database.

An Auxiliary Database Server could address this by housing Praefect, Container Registry, and Geo Tracking (on secondary) together in Geo setups, along with any future non-main databases.

This approach would provide customers with a clearer, more maintainable database architecture while reducing operational complexity.