PGConf.Russia 2023

Since PostgreSQL 9.5 logical replication has replication origin infrastructure for replication progress tracking. Now 16th version is coming with feature which made bi-directional replication setups possible using said infrastructure. In earliest reviews it got a nickname of "native multimaster" for cluster, interconnected with said replication, bearing some resemblance to PostgresPro's Multimaster. We're going to figure out degree of it and explain insides of them. Talk expects you to have a basic knowledge of WAL insides and it's role in PostgreSQL functioning.

ORM libraries are widely used in backend development – let's take this for granted. ORM libraries are improving, developers are learning from their own and others' mistakes, and many have learned to write code for ORM that generates quite optimal queries for typical operations. Yet, limited functionality of existing tools is another problem related to ORM. This is especially true for Postgres, which has a lot of operators and constructs (both in the core and in extensions) that go beyond the SQL standard.

With LinqToDb ORM library you can write extensions that implement any SQL operator or construct very easy, literally using just one line. Full-text search, KNN, CTE (including recursive ones), working with arrays and jsonb, array_agg and jsonb_object_agg, table functions and LATERAL JOIN - all this can be easily used in ORM, which I will demonstrate during this talk!

PostgreSQL backup process in one of the biggest issues you face after switching to PostgreSQL. PostgreSQL has two out-of-the box options for backup and restore, they are dump/restore and pg_basebackup. Both of them have their nuances and peculiarities radically distinguish the backup and recovery system from MS SQL. Another option in the PostgreSQL ecosystem is the pg_probackup utility which is being actively developed and has a number of backup and restore variants offering different features. Each of these options maybe good or not so good for a particular scenario. In this talk, I'd like to cover the nuances, peculiarities and best practices for large databases, hundreds of midsize databases and small database setups.

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.