One release. Seven merged PRs. Schema loading got faster, sharded queries got safer.
schema sync now runs in parallel across shards — a magnitude faster on large deployments
Copy data and schema discovery no longer serialize, unlocking deployments with dozens of shards and thousands of tables.
Schema loading in pgdog used to walk each shard sequentially, blocking the sync pipeline. On a deployment with 10 shards and 1,000 tables each, this serialization added unnecessary latency at startup and during topology changes. @levkk's PR #868, merged in v0.1.35, parallelizes the copy and schema discovery across all shards at once. The effect is immediate: schema sync time drops from linear to near-constant, regardless of shard count. Large Excalibase deployments now initialize in seconds instead of minutes.
logical replication now constructs correct delete queries on compound keys
Tables with multi-column primary keys were silently deleting the wrong rows; the protocol fix is in place.
Logical replication's Delete message handler was building WHERE clauses incorrectly when a table had a compound identity. A delete on a row with keys (tenant_id, id) would construct the wrong parameter binding, leading to deletes against the wrong logical shard or row. @levkk caught and fixed the query construction in PR #866, now part of v0.1.35. The fix ensures compound keys are properly mapped to their placeholders in the extended protocol. Replication fidelity is restored for multi-column primary key scenarios.
multi-shard SELECT...WHERE IN queries no longer deadlock
Queries against multiple shards with large value lists were acquiring locks in inconsistent order; the fix ensures acquisition is deterministic.
A SELECT query with a large IN clause against a sharded table could deadlock if pgdog fanned the query across multiple shards and lock acquisition order differed. @levkk's PR #864 fixes the deadlock by ensuring shard locks are acquired in a consistent order—typically by shard ID. The effect: large IN queries are now safe to execute against sharded tables without serialization workarounds.
extended protocol now handles null LIMIT values without crashing
Queries like LIMIT $1 where $1 is null were failing; the driver now treats null limits as unbounded.
@levkk fixed PR #865 to handle the case where a parameterized LIMIT receives a null value. Previously, pgdog would crash or error; now it correctly interprets a null limit as "no limit" and proceeds. This is part of v0.1.35 and ensures compatibility with ORMs and drivers that pass null for optional LIMIT parameters.
race condition in extended_anonymous prepared statements is now closed
Concurrent prepared statement creation was triggering statement ID collisions under load.
The extended_anonymous prepared statement pool had a race where two concurrent requests could claim the same statement ID, causing protocol errors downstream. @levkk closed the race in PR #863 by ensuring statement ID allocation is atomic. The fix lands in v0.1.35 and eliminates a class of flaky errors under high concurrency.
postgres.js driver now tested in pgdog's CI pipeline
A test gap with the Node.js client has been closed—postgres.js now runs alongside the default test suite.
@levkk added postgres.js to the CI matrix in PR #860. The driver is a popular choice for Node.js deployments; running it in CI ensures pgdog's extended protocol implementation doesn't regress against a real, widely-used client. The test suite now covers postgres.js alongside existing drivers.
-
docs
PgDog documentation.3 commits · 0 releases · ★ 5
-
pgdog
PostgreSQL connection pooler, load balancer and database sharder.7 commits · 1 release · ★ 4267
-
pgdog
PgDog fork with Postgres-backed config and NATS reload for Excalibase platform7 commits · 0 releases · ★ 0
-
helm-ee
PgDog Enterprise control plane Helm chart.1 commits · 0 releases · ★ 0