Inside the OpusDocs Engine: Performance Under Real-World Complexity
About 150 document variations. A 2.35-second median to a finished, stored PDF.
We benchmarked the OpusDocs engine in a controlled test built from a residential solar customer’s templates: 12 template families, from 1-page forms to a 320-page master template with more than 300,000 document elements. Requests carried up to 124 conditional segment flags, along with repeating tables, images, and dozens of signature locations.
Half of the variations produced their finished PDF in 2.35 seconds or less, and 95% in under 5.2 seconds. In that customer’s production org, across its full daily document mix, OpusDocs averages 1.1 seconds per document.*
We also compared OpusDocs with this customer’s legacy Conga workflow. The results are below.
Customer template suite
Performance built around real document work
A useful benchmark reflects the work your team actually does. The same agreement may need different content by language, customer, product, jurisdiction, or transaction type. Related records expand into tables. Names and commercial terms repeat throughout. Signature and initial anchors need to land in the right places.
The suite covers that variation across the customer’s template library, and every measured request completed successfully.
| Document variations | Template families | Median generation (s) |
|---|---|---|
| About 150 | 12 | 2.35 |
The complexity behind the result
Template page count is only part of the story. A master template holds alternative clauses, disclosures, language sections, and exhibits that the engine evaluates before selecting the content for one document.
At the upper end, requests supplied up to 143 distinct merge values, 124 segment flags, 23 table datasets, and 266 table rows, and generated documents carried up to 42 e-sign tags. Those peaks come from different requests.
| Dimension | Range | Median | What is counted |
|---|---|---|---|
| Document body elements | 592–320,000 | 250,000 | Paragraphs, text runs, tables, and formatting before content selection |
| Supplied merge values | 2–143 | 108 | Distinct supplied values; the same value can appear in multiple places |
| Segment flags | 0–124 | 98 | Yes/no choices controlling conditional content; one choice can affect several sections |
| Enabled segment flags | 0–39 | 28 | Content choices set to include; surrounding conditions may still exclude a section |
| Table datasets | 0–23 | 11 | Supplied datasets, including empty ones |
| Supplied table rows | 0–266 | 18 | Rows summed across all datasets in a request |
| Template pages | 1–320 | 90 | Word-reported page count stored in the source template |
| Emitted e-sign tags | 0–42 | 15 | Signature, date, and initial markers in generated documents |
Each count understates the work. A customer name supplied once may appear dozens of times. One segment flag can switch several sections. Each e-sign tag marks a signature, initial, or date location for the right signer.
Hundreds of thousands of elements. Seconds to generate.
We grouped the requests by the number of document body elements in the source, before conditional content was selected. These include paragraphs, text runs, tables, and formatting structures, not just merge fields.
| Body elements | Variations | Median generation (s) |
|---|---|---|
| Under 10,000 | 24 | 0.28 |
| 10,000–99,999 | 23 | 0.74 |
| 100,000–249,999 | 37 | 1.98 |
| 250,000+ | 63 | 3.83 |
| Body elements | Merge values | Segment flags | Template pages | E-sign tags |
|---|---|---|---|---|
| Under 10,000 | 2–56 | 0–4 | 1–8 | 0–20 |
| 10,000–99,999 | 64–69 | 29–37 | 36–46 | 0–9 |
| 100,000–249,999 | 32–143 | 46–99 | 74–90 | 3–30 |
| 250,000+ | 108–140 | 98–124 | 257–320 | 0–42 |
The most complex group held 63 variations with at least 250,000 body elements, 98 to 124 segment flags, and source templates of 257 to 320 pages. Its median generation time was 3.83 seconds.
For teams that run on a large master template, that is the result that matters: you can keep every clause, rule, and variation in one place and still generate fast enough for interactive work.
Source pages are only one dimension of complexity
The source templates in this library range from 1 to 320 pages. Those pages hold all the content available before conditional sections are selected, not just the pages that reach one generated agreement. The larger masters also carry extensive tables and embedded images.
| Template pages | Templates | Word tables | Embedded images |
|---|---|---|---|
| 1–10 pages | 6 | 1–7 | 1–3 |
| 11–50 pages | 2 | 37–65 | 2–28 |
| 51–100 pages | 2 | 44–156 | 6–32 |
| 101–350 pages | 2 | 223–253 | 49–50 |
What the average request looks like
On average, a request in this suite drew on a source template of about 150 pages and 200,000 body elements, with about 30 embedded images, close to 100 distinct merge values, and more than 70 segment flags.
| Dimension | Average | What this means |
|---|---|---|
| Template pages | 149 | Source content available before conditional selection |
| Document body elements | 200,000 | Paragraphs, runs, tables, and formatting structures |
| Word tables | 142 | Source tables, including tables used for layout |
| Embedded images | 29 | Image files in the source package; not visible placements |
| Supplied merge values | 97 | Distinct values that can be reused throughout the template |
| Segment flags | 73 | Inputs selecting the applicable content |
| Supplied table rows | 47 | Related records available for repeating tables |
| Emitted e-sign tags | 15 | Signature, date, or initial anchors in generated documents |
A short agreement with many rules can still be a demanding template, so compare the whole mix with your own: source content, reusable values, conditional rules, repeating records, images, and signing locations.
One template, many variations
Speed should support maintainability, not replace it. Reusing values across an agreement and selecting the applicable sections lets teams support every variation without a separate file for each combination. The suite exercises exactly that: different conditional selections, datasets, field values, images, and language variants from the same templates.
Scalability tests
Alongside the customer suite, we ran a controlled scaling benchmark built on familiar business patterns: values reused throughout a document, conditional sections, and nested rules that select the applicable content.
The profiles step from 100 to 5,000 field placements, with 25–200 distinct values and 10–250 conditional segments, nested up to five levels deep. Each profile has a partial-content and a full-content variation.
All 30 measured runs passed exact content checks in both the generated Word document and the finished PDF.
| Field placements | Distinct values | Segments | Nesting depth |
|---|---|---|---|
| 100 | 25 | 10 | 1 |
| 500 | 50 | 25 | 1 |
| 1,500 | 100 | 75 | 3 |
| 3,000 | 150 | 150 | 3 |
| 5,000 | 200 | 250 | 5 |
| Field placements | Partial content (s) | Full content (s) |
|---|---|---|
| 100 | 0.08 | 0.09 |
| 500 | 0.14 | 0.17 |
| 1,500 | 0.27 | 0.41 |
| 3,000 | 0.54 | 0.72 |
| 5,000 | 0.76 | 1.17 |
The full-content 5,000-field, 250-segment template generated its finished PDF in a median 1.17 seconds. The 3,000-field profile took a median 0.72 seconds. Each additional 1,000 field placements added only about 0.2 seconds, even as rules nested five levels deep.
Estimated compute cost for 10,000 PDFs
Fast generation keeps compute costs small. Across the scalability profiles, up to the 5,000-field, 250-segment template, modeled compute stays under $0.70 of AWS Lambda compute per 10,000 PDFs. Compute scales with generation time, so a document that takes twice as long costs about twice as much.
| Field placements | Estimated average processing (s) | Compute / 10,000 PDFs (USD) |
|---|---|---|
| 100 | 0.093 | $0.05 |
| 500 | 0.203 | $0.10 |
| 1,500 | 0.600 | $0.29 |
| 3,000 | 1.086 | $0.53 |
| 5,000 | 1.351 | $0.66 |
The estimate is 10,000 × mean runtime per PDF × 2.9375 GB × $0.0000166667 per GB-second, using the tested 3,008 MB allocation and first-tier x86 on-demand AWS Lambda pricing in US West (N. California), checked October 5, 2026. Requests add $0.002 per 10,000 invocations. It is a compute estimate, not an OpusDocs price: it excludes storage, data transfer, logs, CRM costs, and software licensing.
Compared with a legacy Conga workflow
How does that compare with a legacy document-generation tool? This customer previously generated these documents in Conga,† so we compared two of them: a low-complexity document and the most complex one.
Even a low-complexity document meant nearly a minute of waiting in this customer’s legacy Conga workflow. Its median elapsed time was 52 seconds, compared with a 0.29-second median on OpusDocs.
At the other end is the Customer Agreement, this customer’s most complex document. Its Conga median was 1 minute 37 seconds. OpusDocs generated its variations in a median 3.7 seconds.
| Workload | Conga workflow | OpusDocs generation |
|---|---|---|
| Low complexity | 52 s | 0.29 s |
| High complexity | 1 min 37 s | 3.7 s |
| Workload | Template pages | Body elements | Merge values¹ | Segment flags¹ | Word tables | Embedded images |
|---|---|---|---|---|---|---|
| Low complexity | 8 | 3,384 | 11 | 4 | 2 | 1 |
| High complexity | 257 | 296,984 | 140 | 98 | 253 | 49 |
¹ Typical input counts. Page counts refer to source templates; Word tables include layout tables.
The gap also holds beyond the median. Nine in ten of Conga’s production Customer Agreement runs took at least 1 minute 25 seconds. Nine in ten OpusDocs benchmark variations finished in under 5 seconds.
The two documents could hardly be more different. The low-complexity template has 8 source pages, around 3,400 body elements, and 4 conditional flags in a typical request. The Customer Agreement has 257 source pages, nearly 300,000 body elements, 253 Word tables, 49 embedded images, and around 100 conditional flags per request. Conga’s medians were tens of seconds for both. OpusDocs’ medians were under a second for one and under four seconds for the other.
Conga’s time runs from workflow start to the finished file and can include queue time, while the OpusDocs time covers generation through PDF storage. Measured end to end, including the Salesforce queries, the OpusDocs Customer Agreement typically arrives in under five seconds, from a single template that replaced 105 Conga files.
How we measured
All OpusDocs figures come from controlled test runs, not production traffic. Generation time is the server-side time from template retrieval to the stored, finished PDF. It does not include upstream CRM queries or the customer’s network. Each of the 147 customer variations was measured once, and the scalability profiles ran three times each on AWS Lambda with 3,008 MB of memory. Every measured run is included.
We reviewed 25,000 of the customer’s historical Conga production records. The document-specific comparison uses 290 records for the low-complexity document and 16,389 for the Customer Agreement, compared with 6 and 39 OpusDocs variations of the matching templates.
These results measure how long one document takes. They are not a concurrency test or an SLA; for production volume, see our high-volume customer story.
Put your most complex document to the test
Bring us the template with the conditional clauses, related records, repeated tables, and signature requirements your team depends on.
With the OpusDocs free pilot, we help set up generation, show your team how to manage the template, and verify the results using your scenarios. No cost. No commitment. Just a practical way to see how your documents perform. Comparing platforms? Read what to evaluate in a Conga Composer alternative.
* The 1.1-second average reflects the customer’s full daily production mix. This benchmark is a controlled test that deliberately concentrates on high-complexity variations, many of them from the two largest master templates.
† The historical review covered 25,000 of the customer’s Conga production records.