5 Improper feature usage

Unidirectional logical replication

Logical replication in both directions

• SQL_ASCII is not a character encoding so much as the absence of one. If you don’t want to risk mixing encodings irreversibly and you enjoy the ease of automatic character set conversion, make sure you use UTF-8 for your database.
• PostgreSQL RULEs are not related to rules as defined in other DBMSs. RULEs are complicated to understand and are mainly there as Postgres internal machinery. In most cases they don’t behave as the user expects them to and TRIGGERs are best used instead.
• Using JSON(B) values with relational access patterns makes for less efficient SQL which is harder to read and might not perform as well. It’s better not to mix the SQL and NoSQL paradigms, but use each facility for what it’s best at doing.
• uuids take up more storage space than even bigints and indexing them is less efficient. They may guarantee a range of values that you simply don’t require for your use case, and an integer index might be enough to guarantee uniqueness.
• Bi-directional or multi-master replication is more complex than what appears at first sight. For practical use in a production system, there is a very long list of prerequisites, considerations and caveats. If your use case indeed justifies setting up a multi-master system, you are better off using an established multi-master solution whose developers have given thought to these issues rather than re-inventing the wheel.
• All of the above apply to homemade distributed systems as well and it is not recommended to set out building them unless your scope is very narrowly focused. You need to consider the potential for distributed serialization anomalies and the very real trade-offs laid out in the CAP and PACELC theorems.

FAQ