Configure GitLab using an external PostgreSQL service

If you’re hosting GitLab on a cloud provider, you can optionally use a managed service for PostgreSQL. For example, AWS offers a managed Relational Database Service (RDS) that runs PostgreSQL.

Alternatively, you may opt to manage your own PostgreSQL instance or cluster separate from the Omnibus GitLab package.

If you use a cloud-managed service, or provide your own PostgreSQL instance:

  1. Set up PostgreSQL according to the database requirements document.
  2. Set up a gitlab user with a password of your choice, create the gitlabhq_production database, and make the user an owner of the database. You can see an example of this setup in the installation from source documentation.
  3. If you are using a cloud-managed service, you may need to grant additional roles to your gitlab user:

    This is for the installation of extensions during installation and upgrades. As an alternative, ensure the extensions are installed manually, and read about the problems that may arise during future GitLab upgrades.

  4. Configure the GitLab application servers with the appropriate connection details for your external PostgreSQL service in your /etc/gitlab/gitlab.rb file:

     # Disable the bundled Omnibus provided PostgreSQL
     postgresql['enable'] = false
    
     # PostgreSQL connection details
     gitlab_rails['db_adapter'] = 'postgresql'
     gitlab_rails['db_encoding'] = 'unicode'
     gitlab_rails['db_host'] = '10.1.0.5' # IP/hostname of database server
     gitlab_rails['db_password'] = 'DB password'
    

    For more information on GitLab multi-node setups, refer to the reference architectures.

  5. Reconfigure for the changes to take effect:

    sudo gitlab-ctl reconfigure
    

Troubleshooting

Resolve SSL SYSCALL error: EOF detected error

When using an external PostgreSQL instance, you may see an error like:

pg_dump: error: Error message from server: SSL SYSCALL error: EOF detected

To resolve this error, ensure that you are meeting the minimum PostgreSQL requirements. After upgrading your RDS instance to a suitable version, you should be able to perform a backup without this error. Refer to issue #64763 (Segmentation fault citing LooseForeignKeys::CleanupWorker causes complete database restart) for more information.