Skip to content

Instantly share code, notes, and snippets.

@drnic
Created March 23, 2016 00:27
Show Gist options
  • Save drnic/4bc9a120011e0a4ef82e to your computer and use it in GitHub Desktop.
Save drnic/4bc9a120011e0a4ef82e to your computer and use it in GitHub Desktop.

Orchestrating high-availability PostgreSQL for Cloud Foundry - Patroni, wal-e & Docker

PostgreSQL can be the only database you need - it offers SQL and NoSQL/JSON, it supports high-availability via synchronous or asynchronous replication to followers, and supports disaster recovery by storing backups and incremental write-ahead logs (WAL) offsite. But orchestrating all this is not easy; and can be a major engineering effort by DBAs or DevOps teams to build out and maintain. And that's just for one database. What if you want hundreds or thousands?

Fortunately in 2016 we have solutions. Patroni [1] is a major step forward in making it easy to setup a highly available PostgreSQL cluster. wal-e [2] provides a way to store base backups and progressive WAL updates offsite in AWS S3, Azure or similar. Docker [3] makes it easy to provision many isolated PostgreSQL services across a shared fleet of pre-provisioned machines.

Combining them all together into Dingo Postgresql [4] means we can provide 100s or 1000s of highly-available, dedicated PostgreSQL clusters to Cloud Foundry users; and single databases or the entire system can be recovered from a disaster.

In 2016, highly-available, disaster proof PostgreSQL may be easier to provision than not to.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment