The monolith hits the ceiling
Docusign's primary database is DocusignDB (DSDB). Microsoft says it reached 308 TB across five production sites, with more than 500 tables and 8,000 stored procedures. At peak, the hottest DSDB instance generated two to three times the I/O demand of a top-tier Azure M176 configuration. In other words, the busiest instance wanted more I/O than one of Azure's largest VM shapes could supply.
Josh Meier, Senior Principal Engineer at Docusign, said the production environment was nearing practical capacity. Engine-level contention was limiting throughput at the busiest site.
Docusign set two constraints on the fix:
- No change to the customer experience or API contract.
- No simple 1:1 migration. That would have carried the same scaling limits into the cloud.
Moving accounts one at a time was also ruled out, because it introduced unacceptable cross-datacenter latency. The design therefore had to spread the workload out while the application kept behaving as before.
The architecture: match the service to the workload
Docusign decomposed the environment using vertical and horizontal sharding across custom Azure SQL configurations and services. Abhishek Chaturvedi, a Fellow at Docusign, put the principle this way: the goal was to match the service to the workload, not force every database onto one Azure service. Microsoft SQL Engineering helped validate the design.
Microsoft's summary names four building blocks:
- Azure SQL Managed Instance
- Azure SQL virtual machines
- Azure SQL Database Hyperscale
- Custom Azure SQL configurations
The story gives specifics for two of them:
- Largest DSDB workloads on Azure SQL virtual machines. Microsoft says these provided the configuration control and sizing those workloads needed. Docusign also optimized queries and pulled blob metadata, address books, brands and templates out of DSDB. Those steps reduced DSDB IOPS enough to allow a safe failover.
- EnvelopeSearchDB (ESDB) on Azure SQL Database Hyperscale. ESDB gives a consolidated search view across DSDB and EVDB. It uses read replicas and scales compute and storage independently.
The result is that Docusign can shard the transactional envelope workload and keep one search experience. As EVDB adds shards and envelope history moves out of DSDB, ESDB can grow storage, compute and read capacity without a rebuild of the application or search design.
Why Hyperscale suits the search tier
This matches how Microsoft's own engineers describe the service. Microsoft's Azure SQL Dev Corner blog says Hyperscale gives each of the jobs a single SQL Server machine used to do its own tier. Compute replicas run the query processor, a log service owns durability, and Azure Storage holds the long-term copy. The same blog says there can be up to four high-availability replicas plus up to 30 named replicas, each with its own compute size, for isolating reporting, analytics, or AI workloads.
Microsoft's documentation also says storage can scale out up to 128 TB for a single Hyperscale database.
That 128 TB figure matters for context. Docusign's 308 TB footprint is far beyond a single Hyperscale database, which is consistent with the story's approach. The large transactional workload was sharded and kept on VMs, and a search layer went on Hyperscale. The story does not say how much data sits in ESDB or how the shards are sized.
The migration: rehearsal over heroics
The operational details are the most useful part of the story:
- Failover. Docusign carried out a site-level database failover in under five minutes. A controlled EVDB ramp followed.
- Validation. The process was checked with 35,000 test cases and more than 50 runbook rehearsals.
- Scale. Chaturvedi says nearly 200 million accounts moved across five production sites while eSignature stayed live. He says this happened with no application rewrite, no big-bang customer migration and no production rollback.
Stripped of marketing, this is a familiar pattern. Keep the application contract stable, change what sits underneath it in small steps, and rehearse the cutover until it is dull. Meier summed it up: eSign no longer has to be treated as one indivisible system, and the data and infrastructure underneath can evolve in smaller, safer steps.
Reported results, and what's missing
Microsoft reports these outcomes:
- Post-failover storage tuning cut average read time by 5 ms.
- P99 latency for completing a signing session and posting a new envelope dropped by more than 3 seconds at the largest North American sites.
- Adding capacity is now a deployment, not a year-long hardware procurement cycle.
The P99 figure is a headline number, but the story omits several things you would want before treating it as a benchmark:
- No baseline P99 and no post-migration P99 value.
- No measurement window.
- No results for the other production sites.
- No cost data.
- No shard keys, scripts or test-case details.
Treat the story as a design pattern, not a promise that other systems will see the same gains.
What IT and database teams can take from it
- Diagnose the real bottleneck first. The story points to concentrated I/O and engine contention, not just raw size. A lift-and-shift would have preserved both.
- Reduce the load before you move it. Extracting blob metadata, address books, brands and templates, plus query tuning, cut IOPS before failover. Offloading data that does not belong in the hot database is often cheaper than buying bigger hardware.
- Use more than one Azure SQL option. VMs gave control for the heaviest workloads. Hyperscale gave elastic read scale for search. Managed services covered new and feature-specific databases.
- Treat rehearsal as a deliverable. Fifty-plus runbook rehearsals and 35,000 test cases are the unglamorous reason a sub-five-minute failover is believable.
- Keep the API contract frozen. Changing the data tier is much easier when clients cannot tell.
One counterpoint: running the largest workloads on Azure SQL VMs means Docusign still carries more operational responsibility than it would on a fully managed service. That is probably a deliberate trade for control, and the story frames it that way. It does not discuss the tradeoff.
The AI angle
Microsoft ties the new foundation to Docusign's Intelligent Agreement Management push. It names Docusign Iris, which it calls the engine behind Docusign's AI contract management platform. It also lists AI-assisted agreement summaries, real-time signer Q&A and agents that automate redlines.
The story does not credit AI for the latency gains. It gives no AI performance or accuracy figures. The link is capacity and elasticity: a platform that can add throughput by deployment is easier to build AI features on.
Docusign says its next steps are moving more eSign services onto its Kubernetes-based platform and decommissioning on-premises datacenters. No schedule is given.
Bottom line
Docusign's story is a credible, if vendor-curated, example of breaking up a very large SQL Server estate without touching the application contract. The strongest takeaways are the workload-by-workload service choices, the I/O reduction before failover, and the rehearsal discipline. The performance numbers lack the baselines needed to check them independently.