PostgreSQL 16: at the finish line

April 8, 2023 is the expected feature freeze date for PostgreSQL 16.

Some of the new features are already known, particularly, we can expect interesting changes related to security and logical replication. However, announcing all interesting patches before the end of the March CommitFest is impossible. Based on the experience of previous releases, we can assume that the most interesting patches will be committed during late March and early April..

That's why the contents of this talk will remain unknown till the very last moment, the author of this talk will also discover it in due time.

Five shades of sharding

The importance of sharding is now colossal. The size of today's databases exceeds 100 terabytes, scaling up vertically, and adding replicas containing a complete physical copy of the database is becoming difficult, especially when computational resources are scarce. Database sharding is a way to scale horizontally by partitioning data between compute nodes that are independent of each other.

In the PostgreSQL world, there are well-known scaling tools - CitusDB, and Greenplum - as well as new generation solutions - Cockroach DB, Yugabyte DB, SPQR, and Shardman.

In this talk, we will discuss the difference between these implementations, the advantages, and disadvantages of these solutions, examine the current state of implementation of sharding in vanilla PostgreSQL, and also touch on another important topic - providing data integrity and consistency guarantees across a distributed cluster.

New UUID versions

Primary key generation is a known issue quite efficiently though not ideally solved by sequences. There are still problems with distributed generation, real uniqueness and predictability. Initially, UUID was not intended for use as a DBMS key, but its new versions (6, 7 and 8) make it quite convenient to use them as both synthetic and natural keys.

PostgreSQL vs Redis: Making the Right Choice

With the rise of NoSQL databases, a number of falsehoods have flourished regarding how to choose a database engine. This talk focuses specifically on Redis and PostgreSQL, and why one might choose one or the other.

At small scales, we can often get by thinking of database servers as black boxes, but as we scale, the internals and architecture become more and more important. This talk focuses on behavior of these systems at scale and under load.

In this presentation you will learn:

• How Redis and PostgreSQL differ architecturally
• How differences in architecture affect scalability and performance
• Cases here Redis is the clear winner
• Cases where PostgreSQL is the clear winner

Additionally, some notes will be offered in terms of where PostgreSQL can improve in to compete with the sorts of workloads that generally favor Redis.