pg_shardman is a PG 11 experimental extenstion which explores applicability of Postgres partitioning, postgres_fdw and logical replication for sharding. It allows to hash-shard tables using pg_pathman and move the shards across nodes, balancing read/write load. You can issue queries to any node, postgres_fdw is responsible for redirecting them to the proper one. To avoid data loss, we support replication of partitions via synchronous or asynchronous logical replication (LR), redundancy level is configurable. Manual failover is provided. While pg_shardman can be used with vanilla PostgreSQL 11, some features require patched core. Most importantly, to support sane cross-node transactions, we use patched postgres_fdw with 2PC for atomicity and distributed snapshot manager providing snapshot isolation level of xact isolation. We support current version here, which we call 'patched Postgres' in this document. To manage the cluster, we need one designated PG node which we call shardlord. This node accepts sharding commands (implemented as usual PG functions) from the user and makes sure the whole cluster changes its state as desired. Shardlord holds several tables (see below) forming cluster metadata -- which nodes are in cluster and which partitions they keep. Currently shardlord can't keep sharded data itself and is manually configured by the administrator. We will refer to the rest of the nodes as worker nodes or workers.