To generate synthetic data that handles complex many-to-many table relationships, you need a generator that models the junction table as a first-class structure, preserves foreign key constraints in both directions, and maintains the statistical properties of the relationship itself, not just the individual tables. Most standard synthetic data tools are built around simpler parent-child hierarchies and fall short here. This article walks through why many-to-many synthesis is uniquely difficult, what properties must be preserved, how modern tools approach junction tables, and how to validate the results.

Why are many-to-many relationships harder to synthesize than other joins?

Many-to-many relationships are harder to synthesize because they cannot be modeled as a simple parent-child hierarchy. Instead of one parent row owning several child rows, two tables are mutually connected through a junction table, forming a bipartite graph structure where each side can reference multiple rows on the other side. This requires fundamentally different modeling techniques than those used for one-to-many joins.

Most synthetic data generation research and tooling has historically focused on single-table synthesis or straightforward parent-child relationships. published SDG research has consistently found that many-to-many datasets present distinct challenges that existing methods have largely not addressed. The bipartite graph structure means that techniques from graph representation learning and random graph theory are needed, which are far more complex than the recursive conditional sampling that works well for one-to-many hierarchies.

There are also compound challenges around scalability and long-range dependencies. Information about a single entity is often distributed across multiple tables, connected through conditional joint relationships. Capturing those indirect correlations, where an attribute in one table subtly influences the distribution of attributes in a table two hops away, requires models that can reason across the full schema rather than table by table. Previous multi-relational approaches have struggled with exactly this: they either sacrifice privacy to preserve relationships, or they preserve privacy by ignoring the relationships entirely.

What data properties must be preserved across linked tables?

When generating synthetic data across linked relational tables, you must preserve statistical distributions within each table, correlations between columns across tables, referential integrity constraints, and cardinality patterns in the relationships themselves. Failing to preserve any one of these produces synthetic data that looks superficially plausible but breaks downstream machine learning models or analytical queries.

At the column level, the synthetic data must match the real data’s marginal distributions, including the shape of tails, skewness, and kurtosis. A marginal distribution mismatch, where the synthetic version of a feature follows a different probability distribution than the original, is one of the most common and damaging failure modes. Beyond individual columns, correlations between columns must be maintained, including non-linear and high-dimensional relationships that simple correlation coefficients would miss.

Across tables, the requirements become more demanding. The schema itself must be respected: primary key uniqueness, foreign key validity, and the absence of orphan records are baseline requirements. But beyond structural integrity, the statistical relationships between columns in different tables must also hold. Purchase records for the same product, for example, are likely to be correlated with each other; a synthetic dataset that ignores intra-group relationships within a joined table will produce significantly different behavior from the real data when used for model training.

Cardinality is another critical property. The distribution of how many child rows correspond to each parent row, or how many links exist between any two entities in a many-to-many relationship, must mirror the real data. If the real data has a highly skewed cardinality distribution and the synthetic version produces a uniform one, any analysis that depends on frequency or volume will be unreliable.

How does a synthetic data generator handle junction tables?

A synthetic data generator handles junction tables by either synthesizing the relationship structure first and then populating the connected tables, or by generating parent tables first and then conditionally generating the junction table and its linked records. The most effective modern approaches treat the junction table as a structural artifact that encodes the relationship graph, and they model that graph explicitly rather than treating the junction table as just another child table.

Generating relationships before values

One technically efficient approach, described in recent patent literature, inverts the typical generation order: it synthesizes the edges between two tables first, establishing which rows will be linked, and then generates the attribute values conditioned on that relationship structure. This approach reduces computational complexity significantly and can be an order of magnitude faster than methods that attempt to generate values and relationships simultaneously.

Hierarchical and conditional generation

The more common approach, used by tools like SDV’s hierarchical modeling algorithm and MOSTLY AI’s sequential generation, starts with the topmost parent tables and works downward. Each child table is generated conditionally, given the context established by its parents. For a junction table, this means both sides of the relationship must already exist before the junction rows are synthesized, and the generator must control cardinality carefully to ensure the resulting link distribution matches the original. Tools like ClavaDDPM (NeurIPS 2024) use clustering labels as intermediaries to model the relationship between tables and include an explicit model for estimating child group sizes, which helps preserve the cardinality distribution of the junction.

What are the most common errors when synthesizing many-to-many data?

The most common errors in many-to-many synthetic data generation are dangling foreign keys, cardinality distortion, error propagation through the table hierarchy, and the loss of cross-table correlations. These errors often go undetected when teams only evaluate individual tables in isolation rather than examining the joined dataset as a whole.

Dangling foreign keys occur when a synthesized junction table row references a primary key that does not exist in the linked table. This is a structural error that breaks referential integrity and makes the synthetic database unusable for any relational query. A related problem is premature insertion order: if child or junction records are generated before their parent records exist, the entire relational structure becomes invalid.

Cardinality distortion is subtler but equally damaging. If the real data has a power-law distribution of links, where a small number of entities are connected to many others and most are connected to few, a generator that produces a more uniform distribution will create a dataset that behaves very differently in practice. Models trained on this data will have miscalibrated expectations about frequency and volume.

Error propagation is a well-documented challenge in hierarchical synthesis: parent tables tend to be synthesized more accurately than child tables, because each level of conditional generation compounds any inaccuracies from the level above. In a many-to-many schema, this problem is amplified because the junction table depends on two parent tables simultaneously, meaning it inherits potential errors from both sides.

Finally, composite key handling remains an open problem for many tools. recent relational synthesis research has shown that naive conversion of composite keys to singular keys does not help models maintain correct relational schemas, and that overlapping foreign keys and multi-fold connected table relations cause failures in most current approaches.

How do you validate that synthetic many-to-many data is accurate?

To validate synthetic many-to-many data, you need to evaluate both individual table fidelity and cross-table relationship fidelity. This means running statistical similarity tests on each table independently, then running additional metrics on the joined datasets to confirm that correlations between columns in different tables are preserved and that cardinality distributions match the original.

For individual tables, standard metrics include column-level distribution comparisons using tests like the Kolmogorov-Smirnov test for continuous variables, and Jensen-Shannon divergence to quantify the statistical distance between real and synthetic distributions. Bivariate metrics check whether pairwise relationships between columns are preserved.

For relational validation, cardinality shape similarity is a key metric: for each parent row, you calculate how many linked rows exist in both the real and synthetic data, then compare those distributions. A well-synthesized dataset will produce a cardinality distribution that closely matches the original. The SDMetrics library from DataCebo provides this metric and is currently the primary open-source option for multi-table evaluation, though it is worth noting that its design assumes a parent-child hierarchy and has known limitations for true many-to-many structures.

Beyond fidelity metrics, utility testing provides a practical validation signal. Training a machine learning model on the synthetic data and evaluating it on real data, a method sometimes called Train on Synthetic, Test on Real, reveals whether the synthetic dataset is genuinely useful for downstream tasks. If model performance degrades significantly compared to training on real data, it signals that important statistical properties were not preserved. The SyntheRela benchmark is the first open-source benchmark specifically designed for evaluating relational synthetic data and is a useful reference for teams building evaluation pipelines.

Which synthetic data tools support relational and many-to-many schemas?

Several tools support relational synthetic data generation, but genuine support for many-to-many schemas specifically is rarer than vendor marketing suggests. The most widely used open-source option, SDV, explicitly does not support many-to-many relationships in its current multi-table synthesizer. Commercial and research-grade tools offer varying levels of support, and the right choice depends on your schema complexity, scale requirements, and compliance needs.

Open-source and research tools

SDV (Synthetic Data Vault), maintained by DataCebo, is the de facto open-source standard for multi-table synthesis and handles one-to-many hierarchies well through its hierarchical modeling algorithm. However, its official documentation is clear that many-to-many and one-to-one relationships are not supported. For research use cases, ClavaDDPM (released at NeurIPS 2024) uses cluster-guided diffusion models and supports multi-parent scenarios, making it one of the more capable open-source options for complex relational schemas. The IRG framework is another research-grade tool that handles composite keys and multi-fold connected tables, and is currently the only method demonstrated to generate valid synthetic relational databases across all tested complex schema types.

Commercial platforms

Gretel.ai, now part of NVIDIA, provides a relational synthesis product that maintains referential integrity and statistical accuracy across large multi-table databases. Tonic.ai offers two complementary products: Tonic Structural for de-identifying and synthesizing existing production data while preserving schema structure, and Tonic Fabricate for generating logically consistent synthetic data from scratch for relational schemas. MOSTLY AI supports multi-table generation with referential integrity and cross-table correlation retention using its proprietary model architecture.

Choosing the right tool ultimately comes down to your schema complexity, the volume of data you need to synthesize, and your regulatory environment. For teams working with genuinely complex many-to-many structures in production, it is worth testing any tool against your actual schema before committing, since support for relational synthesis varies widely even among tools that advertise it.

How BlueGen helps with many-to-many relational data synthesis

Synthesizing many-to-many relational data correctly requires a platform that understands the full schema, not just individual tables. BlueGen is purpose-built for exactly this challenge, offering end-to-end support for complex relational structures in regulated industries where both accuracy and compliance are mandatory.

• Native many-to-many support: BlueGen treats junction tables as first-class structures, modeling the relationship graph explicitly to preserve referential integrity across all linked tables.
• Cardinality preservation: The platform maintains the real data’s link distribution, ensuring that skewed or power-law cardinality patterns are faithfully reproduced in the synthetic output.
• Cross-table correlation retention: BlueGen captures statistical dependencies between columns in different tables, so synthetic datasets remain reliable for model training and analytical queries.
• GDPR-compliant by design: As a Dutch company built for the European market, BlueGen delivers provable privacy guarantees alongside structural fidelity — a combination that most tools cannot offer simultaneously.
• Enterprise-ready: BlueGen serves enterprise clients and government institutions across the Netherlands and Europe who require production-grade synthetic data at scale.

If you are working with complex many-to-many schemas and need a solution that handles both the technical and regulatory dimensions, request a demo and see how BlueGen can address your specific relational data challenges.