PostgreSQL, known for its powerful features and robustness, offers various replication methods to ensure high availability, data consistency, and near-zero-downtime upgrades. Logical replication is one of these techniques. In this blog, we cover the importance and drawbacks of logical replication, EDB's contributions to this technology, and the intriguing improvements made in PostgreSQL 16.

Everyone has a cache for database results, right? Something like redis or memcached to prevent unnecessary and comparatively slow calls to the database. No? Worry not, for with Postgres and some trigger magic, we can produce a cache where there was none before. Don’t let complicated and expensive queries limit your application throughput when you really need to put the pedal to the metal. Let us show you how!

Nobody likes it when their database goes down for any reason, especially if it was unintentional. Sometimes companies are open about their experiences and provide post-mortems for the world to see, and we commend them for it. As Postgres experts, we want to take one of these and see what lessons were learned through the process, and how catastrophe may have been averted.

There are some fundamental strategies inherent to deploying a functional and highly available Postgres cluster. In Part 2 of this blog series, we covered our recommendations on what one should and shouldn’t do while building a HA Postgres cluster when it comes to architecture. In Part 3 of this series, we’ll provide tips on establishing your architecture baseline. Tools “The expectations of life...

There are some fundamental strategies inherent to deploying a functional and highly available Postgres cluster. In Part 1 of this blog series, we covered our recommendations on what one should and shouldn’t do while building a HA Postgres cluster when it comes to expectations. In Part 2 of this series, we’ll provide tips on establishing your architecture baseline. Architecture “You never change...

When it comes to maintaining Postgres high availability, there are some fundamental strategies inherent to deploying a functional and highly available Postgres cluster. In this first blog post of the series, we share recommendations on what one should and shouldn’t do while building a HA Postgres cluster, with tips on setting realistic expectations.

What is “extreme” high availability when we’re talking about Postgres? Is it avoiding outages? Handling failovers? EDB Postgres Distributed defines a new era in high availability that defies description, so we’re going to try our best to define an entirely new level of database durability.

Would you use Postgres in a 1-billion transaction-per-day system? I have! It’s a sobering and rewarding experience that really reveals where Postgres shines. This article will explore a vintage 2011 platform which handled an extremely high transaction volume, and how things may have been done differently today.

Postgres provides several tools to simplify application development. Triggers, for example, allow one event to automatically invoke subsequent inserts, updates, or deletes to either reinforce business logic, or for auditing purposes. But are they valid for all such scenarios? Are there times when triggers would be detrimental to performance and scalability? What are our alternatives? Well, there’s only one way to find out!

In Part 1, we examined how Postgres behaves on older hardware with various allocations of Shared Buffers. This time we repeat those benchmarks on more contemporary hardware equipped with modern SSD storage. The difference this makes is dramatic and has far reaching implications. Join us as we discuss the continuing role of Shared Buffers in modern server deployments!