PostgreSQL and Databases in general

Logical replication in PostgreSQL has steadily evolved since its introduction in version 10.

With the introduction of failover slots in PostgreSQL-17, logical replication can now be effectively utilized in high-availability environments.

In my last blog post, Evolution of Logical Replication, I mentioned the future development of a feature to allow "upgrades of logical replication nodes."

This blog post is about how the Logical Replication has evolved over the years in PostgreSQL, what's in the latest release-16, and what's being worked upon for future releases.

There are various areas in PostgreSQL like Partitioning, Logical Replication, Parallel Query, Vacuum, etc. which improve with each new version.

In the upcoming release of PostgreSQL-14, we will see multiple enhancements in Logical Replication which I hope will further increase its usage.

Logical Replication was introduced in PostgreSQL-10 and since then it is being improved with each version.

Vacuum is one of the sub-systems in PostgreSQL which gets improved with each release.

This blog post is about the journey of parallelism in PostgreSQL till now and what is in store for the future.

There is a lot to say about parallelism in PostgreSQL.

In the past few years, PostgreSQL has advanced a lot in terms of features, performance, and scalability for many-core systems.

PostgreSQL have supported Hash Index for a long time, but they are not much used in production mainly because they are not durable.

Currently when the PostgreSQL database becomes slow especially on systems with high load, it becomes difficult to find the exact reasons.

Parallelism is now reality in PostgreSQL.

Lately, PostgreSQL has gained attention because of numerous performance improvements that are being done in various areas (like for 9.5 the major areas as covered in my PGCon presentation are Read operations, Sorting, plpgsql, new index type for data acce…

As of now, one can't reliably use tar format to take backup on Windows because it can't restore tablespaces data which is stored in form of symbolic links in <data_directory>/pg_tblspc/.

I have ran some benchmark tests to see the Write performance/scalability in PostgreSQL 9.5 and thought it would be good to share the same with others, so writing this blog post.

Database Management Systems uses MVCC to avoid the problem of Writers blocking Readers and vice-versa, by making use of multiple versions of data.

In PostgreSQL 9.5, we will see a boost in scalability for read workload when the data can fit in RAM.