Why object count isn’t scale—and how we (+AI) built data generators based on tens of thousands of real-world backups
If you build anything that touches Jira or Confluence at scale, such as backups, migrations, analytics, reporting, or marketplace apps, you’ve probably done this:
You spin up a test instance.
You generate 1,000 issues.
Everything works.
And then production happens.
The problem isn’t the number of issues. It’s everything that comes with them. Real Jira and Confluence instances aren’t just big—they’re dense, interconnected, and shaped by years of human behavior.
So I built and open sourced two tools to make realistic large-scale testing easier:
- https://github.com/rewindio/jira-test-data-generator
- https://github.com/rewindio/confluence-test-data-generator
They generate large, structurally realistic datasets that actually help you test how your system behaves when the data has history, relationships, and uneven growth.
“Can it handle 10,000 issues?” is the wrong question
An issue is not a unit of scale.
In real environments, an issue implies:
- Comments and discussion threads
- Worklogs
- Attachments (often lots of them, often not small)
- Status transitions and workflow behavior
- Change history
- Custom fields
- Subtasks, epics, and link graphs
- App-specific data
- Users interacting with all of the above over time
So when someone says “10,000 issues,” what they usually mean is:
10,000 issues plus years of accumulated complexity attached to them.
If your test data doesn’t model that, you’re not testing reality—you’re testing a skeleton.
The same story applies to Confluence. A few thousand pages sounds simple until you remember what production looks like:
- Pages in hierarchies (some deep, some messy)
- Pages with many versions
- Attachments that accumulate and balloon over time
- Comments, inline feedback, and collaboration patterns
- Spaces with permissions that… evolve
Scale isn’t just object count.
Scale is structure + history + density.
This isn’t guesswork, it’s based on tens of thousands of backups
Rather than make up ratios, I analyzed structural patterns across tens of thousands of Jira and Confluence backups over an extended period to understand how real environments grow.
To be clear: this wasn’t about inspecting customer content. It was an analysis of aggregated, anonymized operational metadata: object counts, attachment distributions, relationship density, growth patterns. The shape of the data, not the data itself.
From that analysis, I built multiplier tables that model how related data types scale relative to a core unit like:
- Number of issues (Jira)
- Number of pages (Confluence)
That’s the missing piece in most data generators. They can create objects, but they usually don’t create the implied objects in realistic ratios that make the dataset behave like production.
If you ask the Jira generator for 10,000 issues, you don’t just get 10,000 empty shells. You get issues, plus a realistically scaled mix of:
- Comments
- Attachments (with distributions that resemble production)
- Change history density
- Subtasks and links
- Custom field usage patterns
- Other related objects that emerge once an instance has been used for a while
The goal isn’t to clone any specific organization.
The goal is to recreate the shape and density of real-world Jira and Confluence data, so systems experience realistic pressure:
- API load and throttling behavior
- Storage growth patterns
- Relationship traversal complexity
- Indexing and search stress
- Restore depth and cross-object dependency impact
That’s where integrations break. That’s where performance cliffs show up. That’s where you find out whether your tooling is actually ready.
Built for real scale (not just demos)
Large datasets take time to generate. And long-running jobs fail.
These tools were built for jobs that run for hours (or longer), not just quick demo scripts:
- Checkpointing so progress is saved and generation can resume after interruption
- Practical handling of throttling and transient failures
- Designed to be stable and repeatable for ongoing test runs
If you’re generating a genuinely large dataset, you shouldn’t have to restart from zero just because a network hiccup happened at hour four.
Who is this for?
This isn’t a “make my demo prettier” tool.
It’s for engineers who need to answer questions like:
- Will my backup and restore workflow still behave at scale?
- Does my migration tool fall over when attachments get dense?
- What happens when relationship graphs become complex?
- Does indexing degrade when history and versions pile up?
- Will my integration survive realistic API pressure?
Small synthetic datasets are comforting because they tend to be clean.
Production isn’t clean.
If you want confidence, you need test data that reflects reality.
Getting started
Both tools are available on GitHub:
- Jira: https://github.com/rewindio/jira-test-data-generator
- Confluence: https://github.com/rewindio/confluence-test-data-generator
Each repository includes configuration options so you can:
- Control dataset size
- Tune scaling parameters
- Move from small → medium → enterprise-scale
- Resume interrupted runs
My advice: start with a dataset slightly larger than you think you need. You’ll learn faster.
Why open source this?
Because generating realistic large-scale test environments is harder than it looks, and most teams eventually run into it.
If you build on Jira or Confluence long enough, you will hit scale. And when you do, you basically have two options:
- Test properly, or
- Learn in production
I prefer option one.
If these tools help you surface edge cases earlier, pressure-test your systems more effectively, or avoid a few unpleasant surprises, then they’ve done their job.
If you want to extend the modeling, improve the scaling logic, or support additional data shapes, open an issue or send a PR.
Closing thought
Small datasets hide problems.
Real Jira and Confluence instances are shaped by time: collaboration patterns, attachments, relationships, versions, and growth that’s anything but uniform.
If your system needs to work under real conditions, your test data should reflect that reality.
That’s what these generators are for.
Dave North">
