Derk van Veen

When cleaning up some old data we found some corrupted pages in a toast table. Suddenly these corruptions blocked the vacuum and transaction wrap around was waiting for us just around the corner.

Good technical ideas, solutions, and projects get lost when they are not well communicated. Think about losing track of a presentation because you don't know where it is going, or a software feature request where the developers reject it because they don't know why it is needed or which problem it solves.

In the latest published version of the adyen postgres partition framework (https://github.com/Adyen/adyen-postgres-partitioning) you find a lot of improvements but I want to highlight a few novelties here. First of all, you should not partition individual tables, but all tables around the same leading figure.

Understanding all the details of a High Availability PostgreSQL clusters is one of the most critical DBA knowledge area's. Instead of boring you with endless numbers of slides, with volunteer assistance from the audience, we will show you all important concepts like WAL transport, synch/async commit, RTO, RPO, network involvement etc with nothing more than a few decks of playing cards and some...

In our experience, when developers create partitioned tables, they will create a few partitions to cover the first year, create a few more after the year and finally forget about them.

Understanding how PostgreSQL handles multiple requests at the same time is one of the most important concepts when working with it. Without understanding this the Multi Version Concurrency Control (MVCC) mechanisms it is hard, if not impossible, to understand and predict how an application will behave.

At Adyen we have invested heavily and built upon the Postgres database engine, generally this has worked very well for us. Occasionally Postgres Write Amplification can be technical challenge at Adyen, fortunately this does not happen often, unfortunately when it does happen it is around critical, high volume workloads.