Skip to content

Add support for configuring multiple PostgreSQL services in Omnibus GitLab single node

Problem Statement

GitLab Omnibus currently supports only two PostgreSQL services via configuration:

  • postgresql['enable'] - The main GitLab database service
  • geo_postgresql['enable'] - The secondary PostgreSQL service for GitLab Geo tracking database

As GitLab continues to evolve, new databases are being introduced that may require dedicated PostgreSQL instances, particularly in single-node deployments where some databases cannot be replicated by GitLab Geo and therefore must run on separate servers. The current hardcoded approach of adding individual service configurations (like we did with geo_postgresql) is:

  1. Not scalable - Each new database requires code changes in Omnibus
  2. Inflexible - No way for users to configure custom database setups for single-node scenarios
  3. Maintenance burden - Increases testing complexity with each database addition

Recent examples of databases that require separate instances include:

For Geo deployments specifically, this introduces a problem for single-node Geo setups, as some databases cannot be replicated. Currently, there are only two ways to address this: users must either spin up a completely separate node or service for the database, or Omnibus must gain the ability to deploy multiple PostgreSQL server processes on the same box to achieve proper separation.

Proposal

Add a new configuration pattern that allows users to define multiple PostgreSQL services dynamically via a map structure in gitlab.rb, for example:

postgresql_servers = {
  'main' => {
    'enable' => true,
    'port' => 5432,
    'data_dir' => '/var/opt/gitlab/postgresql',
    'username' => 'gitlab-psql',
    'databases' => ['gitlabhq_production'],
    'listen_address' => '0.0.0.0',
    'shared_buffers' => '1GB',
    'max_connections' => 300,
    'ssl' => {
      'enable' => true,
      'cert_file' => '/path/to/cert.pem',
      'key_file' => '/path/to/key.pem'
    },
    'md5_auth_cidr_addresses' => ['127.0.0.1/32', '192.168.1.0/24'],
  },
  'registry' => {
    'enable' => true,
    'port' => 5433,
    'data_dir' => '/var/opt/gitlab/postgresql-registry',
    'username' => 'gitlab-psql-registry',
    'databases' => ['registry_production'],
    'shared_buffers' => '256MB',
    'max_connections' => 100
    # Inherits other defaults
  }
}

Scope: This feature would only target single-node PostgreSQL deployments where each service runs independently on the same server with separate ports and data directories. This addresses the specific challenge of databases that cannot participate in GitLab Geo replication and need to be isolated on dedicated database servers.

An approach like this could lead to the following benefits:

  • Future-proof: New databases don't require Omnibus code changes
  • Geo-compatible: Enables proper database isolation for non-replicable databases in single-node Geo setups
  • Cost-effective: Avoids the need for additional servers or external database services
  • Flexible: Users can create custom database configurations for their specific needs
  • Maintainable: Single configuration pattern vs multiple hardcoded services
  • Backward compatible: Existing postgresql and geo_postgresql continue to work with future option to streamline
  • Standardized: Consistent configuration approach across all PostgreSQL instances
Edited by Grant Young