A Wolters Kluwer customer-authored case study published by Microsoft on October 21, 2026 describes scaling tax and accounting workloads with elastic clusters in Azure Database for PostgreSQL. The company's dataset grew from roughly 6 TB to nearly 10 TB during 2026. This is new production experience, not a new feature-launch announcement. Read the case study.
The most useful lesson is not a headline performance number. It is how distribution design, connection management, and high-availability testing affected the result.
Design Time Was Part of the Migration
The team reports approximately three months of design, cleanup, and testing across roughly 400 tables, followed by a weekend migration of about 6.4 TB. They selected tenant-distributed tables, reference tables, and time-based partitioning to fit their application. Reported migration work.
That distinction matters for planning. A short cutover does not mean the architecture decision or preparation was quick.
For another workload, I would separate discovery, distribution design, rehearsal, cutover, and post-cutover acceptance in the project record. Give each phase its own evidence rather than estimating the whole effort from the final migration window.
Scaling Out Still Requires a Data Decision
The elastic-cluster documentation explains that the managed service uses Citus for horizontal sharding. Newly created tables and schemas are not automatically distributed. Teams must choose and apply an appropriate sharding model.
My proposed design review would start with the application's most important data relationships. Identify tenant boundaries, shared reference data, retention requirements, and queries that cross those boundaries.
Ask the application team to explain how a representative transaction accesses its data. Then compare that explanation with the proposed distribution. Do not treat an available cluster size as proof that the application's access patterns fit a distributed design.
Keep the decision understandable to the people who will maintain it. A future schema change should have a clear review path when it alters a relationship the original design depends on.
Include Connection Behavior in Capacity Testing
In the published case, adding PgBouncer reduced physical connections to approximately one-sixth of their previous level. The team also reports that enabling HA only after migration exposed an issue absent from their earlier testing. They now test failover, health probes, and routing with HA enabled. Operational lessons.
Those are customer-reported observations for that configuration, not universal savings or a guarantee for another application.
For a pilot, I would record application connection demand, pool settings, concurrency, and the database behavior observed under a representative workload. Include the application's actual connection lifecycle rather than a load generator that reuses connections differently.
Assess both normal operation and a disrupted dependency. The useful question is whether the service recovers within its acceptance criteria without an uncontrolled connection surge or ambiguous application result.
Make the Rehearsal Match the Intended Topology
My acceptance plan would identify the production features that must also exist in the rehearsal: HA configuration, identity, network path, routing, monitoring, and relevant connection settings.
Record differences explicitly when a smaller environment is necessary. A scaled-down test can establish some behavior, but the report should say which capacity or recovery claims remain unproven.
Use synthetic or appropriately protected data and involve the application owner in checking the business outcome. A healthy database endpoint does not establish that a multi-step operation completed correctly from the user's perspective.
Agree in advance how to stop or reverse a rehearsal change, which observations must be retained, and who decides that the evidence is sufficient for the next stage.
Read the Customer Result as a Hypothesis
The case is useful because it exposes engineering decisions behind the outcome. My recommendation is to turn those observations into testable questions for your own application rather than copying the customer's topology or expected performance.
Choose an initial workload with measurable acceptance criteria. Preserve its baseline, document the proposed design, and repeat the important operational exercises before expanding the scope.
That creates a decision record your team can revisit when data volume, tenant distribution, or application behavior changes.
Practical Cloud Engineer Takeaway
Budget for distribution design, not just the cutover.
Make table and query boundaries explicit.
Test real connection behavior and recovery demand.
Include HA, probes, and routing in the rehearsal topology.
Treat customer results as evidence to investigate, not promised outcomes.
Who Should Care?
PostgreSQL platform teams, multi-tenant application engineers, and architects evaluating horizontal database scale while retaining a managed Azure service.
Bottom Line
Wolters Kluwer's new case study makes the operational work visible. Use it to strengthen the migration test plan, especially where a simplified environment would hide the configuration your production service actually needs.
No database migration, pool configuration, failover, load test, or Azure resource change was performed for this article. The case measurements belong to the named customer.
Sources
Stay radical, stay curious, and keep pushing the boundaries of what is possible in the cloud.
Chriz
Beyond Cloud with Chriz
Comments