PgConf.Russia 2020

pg_repack is one of the most popular instruments for removing bloat of tables and indexes in Postgres. In most cases, it works perfectly. But if you use such a feature of Postgres as deferred constraints, using pg_repack becomes more difficult or even impossible. I will talk about how we encountered the problem and will describe some workarounds - from internal instruments of Postgres to a small patch for pg_repack.

We would like to share our test results (including performance testing) of PostgreSQL/Citrus and MongoDB for our company's data. It has been a very exciting process with unexpected turns and a somewhat controversial outcome.

A brief story how MySQL → PG migration could increase company efficiency tenfold times:

1. Program code has been reduced 50 times, with optimization of backend team (from 15 to 3 engineers)
2. Software development of new features has become measuring in days, not in months
3. Infrastructure costs per 1M users have been reduced 20 times
4. Database structure and technical documentation were simplified significantly, from 100K high-dependent tables to just 20 simple tables
5. New security level because of total forbidden on external SQL commands to the database
6. Quick analytics aggregation on multiple parameters, without external analytics systems
7. The last, but not the least: the main business was keeping alive during migration

pg_probackup is a flexible tool that allows choosing the backup strategy depending on the write load of the PostgreSQL cluster, as well as offers a number of other features that can facilitate this vital aspect of database maintenance. In this tutorial, we will see how to apply this tool in practice.