# DevOps at Findmypast: Postgres Database Upgrades

DevFeed: [DevOps at Findmypast: Postgres Database Upgrades](<https://devfeed.tech/articles/devops-at-findmypast-postgres-database-upgrades-19745.md>)

Original publisher: [Read original article](<https://tech.findmypast.com/postgres-database-upgrades/>)

Author: Robbie Hill

Published: 2022-11-17T11:30:00Z

Content type: article

Language: en

Sources: [Findmypast](<https://devfeed.tech/sources/findmypast.md>)

Topics: [Databases](<https://devfeed.tech/topics/databases.md>), [DevOps](<https://devfeed.tech/topics/devops.md>), [upgrade](<https://devfeed.tech/topics/upgrade.md>), [Microservices](<https://devfeed.tech/topics/microservices.md>), [Kubernetes](<https://devfeed.tech/topics/kubernetes.md>), [Puppet](<https://devfeed.tech/topics/puppet.md>), [Ubuntu](<https://devfeed.tech/topics/ubuntu.md>)

Tags: [back-end](<https://devfeed.tech/tags/back-end.md>), [clusters](<https://devfeed.tech/tags/clusters.md>), [configuration](<https://devfeed.tech/tags/configuration.md>), [databases](<https://devfeed.tech/tags/databases.md>), [deployment](<https://devfeed.tech/tags/deployment.md>), [devops](<https://devfeed.tech/tags/devops.md>), [engineering](<https://devfeed.tech/tags/engineering.md>), [findmypast](<https://devfeed.tech/tags/findmypast.md>), [kubernetes](<https://devfeed.tech/tags/kubernetes.md>), [kubernetes-clusters](<https://devfeed.tech/tags/kubernetes-clusters.md>), [linux](<https://devfeed.tech/tags/linux.md>), [microservices](<https://devfeed.tech/tags/microservices.md>), [mongodb](<https://devfeed.tech/tags/mongodb.md>), [postgres](<https://devfeed.tech/tags/postgres.md>), [puppet](<https://devfeed.tech/tags/puppet.md>), [relational-databases](<https://devfeed.tech/tags/relational-databases.md>), [ubuntu](<https://devfeed.tech/tags/ubuntu.md>), [updates](<https://devfeed.tech/tags/updates.md>), [upgrade](<https://devfeed.tech/tags/upgrade.md>), [upgrades](<https://devfeed.tech/tags/upgrades.md>)

## AI overview

Findmypast describes its process for upgrading production and non-production Postgres databases. The article covers the database infrastructure, backup arrangements, Puppet-managed installations, version drift between environments, and the reasons for standardizing on the latest supported Postgres version.

## Source excerpt

Introduction Findmypast and its sister site; the British Newspaper Archive (BNA), are served by a web of microservices operating across multiple Kubernetes clusters. A number of our microservices rely upon a back-end database, and although we do operate other database technologies (MSSQL, MongoDB etc.), Postgres is our de-facto standard for relational databases. When the DevOps team first realised the need to upgrade all of the database nodes to the latest Postgres version, we operated a total of twelve production Postgres databases, each running on their own dedicated Ubuntu Linux virtual machine (VM). Running on standalone VMs allows for separation of concerns, and limits the 'blast radius' of issues and failures should they occur. All VMs are managed by our Hyper-V cluster, and backed up regularly by Veeam. In addition to this backup method we operate Barman, which takes a full backup of all production Postgres database hosts nightly, and continuously receives WAL (Write Ahead Log) updates. We operate a a similar number of staging / integration / utility Postgres databases. Unlike the production databases these are (mostly) co-located on a single host, given the reduced storage and performance requirements of these databases. Existing Processes We manage Postgres installations and configuration through Puppet, pinning the installed version of Postgres. After the initial deployment we were not actively upgrading the Postgres version running on the hosts. Upgrades of the production databases were instead only undertaken by the feature teams (those teams that manage our micro-services), or by us when requested by the feature teams. This meant that we had a variety of Postgres databases deployed to production, between versions 9 and 14 (the latest supported version at the time). It also meant that the Production Postgres versions differed from their respective staging / integration database. We knew this situation, as well as the approach to upgrades was bad practice