If you're a Postgres expert, you've surely been asked to reach some objectives like Recovery Time Objective (how much disruption you can afford) and Recovery Point Objective (how much data you can lose). You might have also found yourself in the difficult situation of explaining to your boss that, even though you can reduce the risk of data loss or service disruption, there is no such thing as zero risk.

On top of that, thanks to the Consistency-Availability-Partitioning (CAP) theorem and the PACELC (Partitioning-Availability-Consistency-Else-Latency-Consistency) theorem, reducing the risk of service disruption will imply a more complex architecture that can induce more latency and perhaps more data loss and vice versa.

In this webinar, we will explore the trade-offs that you need to make when drawing an architecture for a Relational Database Management System like PostgreSQL. We will conclude with some practical use cases, explaining the constraints, the problems and how we solve them.