Our typical PostgreSQL shard consists of master and two replics. We monitor that master has as much as needed number of replics (we fire WARN event in monitoring if there is only one alive replica and CRIT if there are no alive replics). And we monitor replication lag, replay_location …

We have workflows with storing cooling UGC-data in DB. The older the data is, the less likely it is asked. We partition tables with such data by date and eventually move data from SSD-disks to SATA. It gives us very good hardware savings. PostgreSQL has built-in support for …

Preface

Once upon a time we started having strange performance issues with writing-only load on PostgreSQL 9.4 with huge shared_buffers. The problem itself is well described here but it is not the topic of the post. And since PostgreSQL does not have something like Oracle wait events interface …