Before we proceed, you should understand the basic Postgres Pro Shardman system architecture. Understanding how the parts of Postgres Pro Shardman interact will make this chapter somewhat clearer.

Postgres Pro Shardman uses a client/server model. It is a solution for the distributed systems that works with real-time OLTP for CRM/ERP, Massively Parallel Processing (MPP) framework, PaaS, SaaS, FaaS, and ODS/MDM. Postgres Pro Shardman splits a large database into smaller, independent parts located on different servers.

Postgres Pro Shardman introduces a notion concept of shard in the PostgreSQL ecosystem. Shard is a separate partition of a bigger database used for horizontal scaling of a DB by splitting a larger DB into smaller pieces distributed across servers. It allows distributing workload and improve availability. Each shard can be handled as a separate DB, while a set of shards unite into a single DB. Note that the number of shards can change with time.

Postgres Pro Shardman also have a number of unique table and object types. For more information, refer to Table Types and Distributed System Objects.

Postgres Pro Shardman transport provides data transfer and connection between primary and standby nodes when data from client connections is received based on client backends and workers. Any issues are monitored on cluster level (notably, monitor) to quickly detect any transaction or node failures, connection issues, or deadlocks.

While Postgres Pro Shardman server can handle multiple concurrent connections from clients, inter-cluster communications is handled by the Silk transport.

The nodes are mostly managed with the shardmanctl utility, while cluster configuration parameters are specified within the sdmspec.json file. shardmanctl also manages backup activities.

For internal specifics refer to Distributed System Internals.