TRAKTOR: Towards the cloud

TRAKTOR now has the capability to analyze the PostgreSQL server logs through file_fdw or log_fdw, without requiring direct access to the server filesystem any more.

This enables it to work with managed PostgreSQL like AWS RDS and Aurora.

File_fdw and log_fdw seem to be lacking from Azure Database for PostgreSQL.

TRAKTOR, true multimaster replication for PostgreSQL

Hi all,

after the retirement of pgchem::tigress, I stumbled over this Blog post, that showed a method to break the vicious replication cycle when using PostgreSQL logical replication in a multimaster cluster, i.e. all nodes are readers and writers.

For PostgreSQL 16.x, this is not necessary anymore, since it introduced origin=NONE, but for pre-16.x,it works quite well.

Yet, setting up a multimaster cluster is tedious and error prone, so I decided to start a new endeavour and make it easier (that was well before the introduction of pgEdge or pgactive).

So without much furter ado, TRAKTOR was released today. With the help of TRAKTOR, you can set-up true multimaster replication clusters on top of vanilla PostgreSQL servers. Notable features are:

1. Does not need anything beyond a standard PostgreSQL server. No fork, no extension.
2. Shared nothing architecture. No single point of failure,
3. Can automatically heal conflicts in case of split brain situations.
4. REST API for control and monitoring.
5. Works with extensions and custom datataypes, PostGIS and rdkit have been tested.

It does NOT help with designing a robust logical multimaster model! No fancy CRDT datatypes, no vector clocks. And it lacks a comprehensive user's guide yet, but there is a tutorial to get you started.