Only a handful of synthetic data tools genuinely preserve referential integrity across relational tables. The most capable options include SDV (Synthetic Data Vault), MOSTLY AI, Tonic.ai, K2view, YData Fabric, and IBM watsonx — each taking a schema-aware approach that generates parent tables before child tables and enforces foreign key constraints throughout. Most simpler or single-table tools fail this test because they treat each table independently, breaking the relationships that make relational data useful. This article walks through how referential integrity works, why it is hard to preserve synthetically, what to look for in a tool, and how to validate the result.

How does referential integrity work in relational databases?

Referential integrity is a rule that ensures relationships between tables in a relational database remain consistent and valid. It works by requiring that any foreign key value in a child table must match an existing primary key value in the parent table, or be explicitly set to null where permitted. Without it, databases accumulate orphaned records — orders with no valid customer, transactions with no valid account — that corrupt queries and reports.

The mechanism behind referential integrity is the foreign key constraint, defined at the schema level. When a record is inserted, updated, or deleted, the database management system checks whether the operation would violate any declared relationship. If it would, the system either blocks the operation outright or applies a cascade rule — automatically updating or deleting the related rows to restore consistency.

This structure underpins how modern enterprises store and query data. Relational databases organize information into multiple interconnected tables governed by these foreign key references, and they remain the dominant data management architecture globally. The practical implication for synthetic data is significant: generating realistic data for any one table in isolation is not enough. Every generated row in a child table must point to a row that actually exists in the parent table — and that constraint must hold across the entire database simultaneously.

Why do most synthetic data tools struggle with relational tables?

Most synthetic data tools struggle with relational tables because they were designed for single-table generation. They learn statistical distributions from one table at a time and produce rows independently, with no awareness of how those rows connect to other tables. When foreign keys are assigned afterward by randomly matching records across tables, the cross-table correlations that exist in real data are destroyed.

The challenge has two distinct dimensions. First, a multi-table database is a graph structure — some tables have multiple parent tables, and some relationships are indirect, spanning several hops. Modeling that graph accurately requires understanding the entire schema before generating a single row. Second, even when the graph structure is understood, the statistical dependencies between records linked by foreign keys are subtle. In real data, a customer’s orders are not a random sample of all orders — they reflect that specific customer’s behavior. Generating them independently and then linking them at random breaks that behavioral coherence.

As multi-table synthesis research has documented, existing approaches often focus on relatively simple parent-child relations and fail to address real-world complexities such as composite keys, intra-table sequential correlations, and indirect inter-table dependencies. IBM has noted directly that referential integrity is not often found with standard synthetic data generators — an acknowledgment that the problem is widespread even among established tools. Generative models like GANs tend to learn single-column distributions reasonably well but struggle to preserve logical relationships across columns and tables, making them an incomplete foundation for relational synthesis without additional schema-aware layers on top.

What features should a synthetic data tool have to preserve referential integrity?

A synthetic data tool should preserve referential integrity by understanding and respecting the full database schema before generating any data. The most important feature is schema-aware generation: the tool must parse primary keys, foreign keys, cardinalities, and hierarchical dependencies, then generate parent tables before child tables so that valid references always exist when child rows are created. This ordering approach, based on a topological sort of the table dependency graph, is the foundational technique that separates capable tools from those that treat tables in isolation.

Beyond generation order, look for the following capabilities:

• Automatic relationship discovery: The tool should identify primary and foreign keys through data profiling, not require manual configuration for every table pair. For databases with dozens or hundreds of tables, manual mapping is impractical.
• Schema-level constraint enforcement: The tool should enforce uniqueness, range limits, functional dependencies, and other schema constraints — not just foreign key links. A violation rate metric, measuring the fraction of integrity checks that fail across the generated dataset, is a useful quality signal.
• Cross-table statistical fidelity: Referential integrity is a structural property, but a high-quality tool also preserves the statistical relationships between linked tables. Generating valid foreign keys that point to random parent rows is not enough if the behavioral correlation between parent and child is lost.
• Multi-system scope: Enterprise databases rarely live in a single system. Tools should be able to preserve referential integrity across multiple databases, file formats, and APIs simultaneously.
• Evaluation support: The tool should provide metrics for both single-table quality and joined-table quality, so teams can verify that cross-table correlations and privacy properties hold at the join level, not just within individual tables.

CI/CD pipeline integration and scheduled generation are also worth prioritizing. Stale test data that no longer reflects the current schema is a common source of broken referential integrity in development environments, and automated regeneration eliminates that risk.

Which synthetic data tools support multi-table relational generation?

Several synthetic data tools now support multi-table relational generation with referential integrity preservation, ranging from open-source libraries to enterprise platforms. The right choice depends on your infrastructure, compliance requirements, and the complexity of your data model.

Open-source and developer-focused tools

Synthetic Data Vault (SDV), originally developed at MIT’s Data to AI Lab, is the most widely used open-source framework for this purpose. It supports single-table, multi-table, and sequential data generation through models including GaussianCopula, CTGAN, and TVAE. SDV uses a hierarchical modeling approach that preserves relational structure by aggregating parameters recursively across the table graph. Its companion package, SDMetrics, provides evaluation metrics for both single-table and joined-table quality, making it a practical starting point for teams who want full control over their generation pipeline.

Gretel, whose relational generation features support databases via SQLAlchemy connectors including PostgreSQL, MySQL, Snowflake, and others, extracts primary and foreign keys automatically before generating synthetic databases. Gretel was acquired by NVIDIA in early 2025 and integrated into the NeMo ecosystem, so teams evaluating it should assess the current product positioning under that umbrella rather than relying solely on pre-acquisition documentation.

Enterprise platforms

MOSTLY AI supports single-table, two-table, and multi-table generation with referential integrity maintained across all scenarios. Its Synthetic Data SDK strictly preserves all foreign key relationships, including tables more than one hop away from the primary entity, making it well suited to complex relational schemas.

Tonic.ai offers two relevant products. Tonic Structural connects to production databases, applies automated masking and de-identification, and provisions test data that preserves schema structure and business logic. Tonic Fabricate generates referentially intact data from scratch across databases, APIs, and files simultaneously, using a conversational AI interface to draft a multi-step generation plan before building anything.

K2view uses patented entity-based technology that preserves referential integrity through a schema blueprint of the full data model. It supports both GenAI-driven and rules-based generation and integrates into CI/CD pipelines. YData Fabric supports multi-table database synthesis while maintaining relational integrity across complex schemas with multiple interrelated tables. IBM watsonx includes multi-table nodes that preserve primary key and foreign key relationships when generating synthetic data from database connections. SAS Data Maker (which incorporates the former Hazy platform) focuses on privacy-preserving synthesis for compliance-heavy environments in financial services and government.

We at bluegen.live also operate in this space, with a platform built specifically for the European market and designed to support complex relational structures including many-to-many relationships. Our solution is GDPR-compliant by design and serves regulated industries including healthcare, finance, and energy — sectors where both referential integrity and privacy guarantees are non-negotiable.

How do you test whether synthetic data preserves referential integrity?

You test whether synthetic data preserves referential integrity by querying for orphaned records using SQL LEFT JOINs. For each foreign key relationship in the schema, join the child table to the parent table on the key column and filter for rows where no match exists. A result of zero orphaned records confirms that all foreign key references are valid. This check should be run across every declared relationship in the schema, not just the most obvious ones.

SQL checks confirm structural validity, but they do not tell the whole story. A complete validation strategy covers three layers:

1. Structural validity: Foreign keys match primary keys, uniqueness constraints hold, and range limits are respected. The violation rate metric — the fraction of integrity checks that fail — gives a single summary figure for this layer.
2. Statistical fidelity: Distributions within individual tables match the source, and cross-table correlations are preserved at the join level. Tools like the SDMetrics package provide metrics for both single-table and joined-table quality, and evaluation should explicitly include joined reports to catch cases where individual tables look fine but their relationship is statistically broken.
3. Privacy evaluation: Re-identification risk is assessed at the join level, not just per table. Joining synthetic tables can sometimes expose patterns that would not be visible in any single table, so privacy testing must reflect the same joins that real analysts would perform.

As multi-table benchmarking research has noted, most methods fail multi-table fidelity tests when rigorously evaluated — which makes independent validation essential rather than optional. Modern platforms increasingly provide dashboards and continuous audit capabilities to monitor synthetic data quality over time, which is particularly important in CI/CD environments where the schema evolves and previously passing datasets can become invalid after a schema change.

What’s the difference between row-level and schema-level synthetic data generation?

Row-level generation produces individual records independently, with each row treated as a self-contained entity. Schema-level generation treats the entire data model as a single unit, understanding all primary keys, foreign keys, cardinalities, and hierarchical dependencies before producing any rows. The difference is fundamental: row-level tools are sufficient for single-table use cases, but only schema-level tools can produce relational databases where the data across tables is internally consistent.

In row-level generation, the model learns a statistical distribution from one table and samples from it. This works well when each row represents a complete, independent entity — a survey response, a sensor reading, a product listing. The model has no need to know that other tables exist.

Schema-level generation is a different class of problem. Before a single row is generated, the tool must parse the full data model and determine a generation order — parent tables first, child tables after. It must then ensure that when child rows are generated, the foreign key values they reference correspond to rows that have already been created in the parent table. Beyond structural correctness, a high-quality schema-level tool also models the statistical dependencies between linked records: the behavioral patterns that connect a parent entity to its children, and the indirect correlations that flow through multi-hop relationships.

The practical consequence is that using a row-level tool for a relational database — even a good one — will produce data that passes individual table checks but fails as soon as it is used in a join. Application logic breaks, queries return incorrect results, and machine learning models trained on the joined data learn spurious patterns. As synthetic data engineering guidance makes clear, preserving foreign key relationships and cross-table statistical dependencies is critical for generating realistic test databases that do not break application logic. Schema-level generation is not an advanced feature — it is a baseline requirement for any relational use case.

When should you use synthetic data instead of anonymized production data for relational datasets?

Use synthetic data instead of anonymized production data when you need to share data outside your organization, generate data at a different scale than your production dataset, simulate rare patterns not present in real data, or when strong privacy-by-design is required for sensitive domains like healthcare or financial services. Use anonymized data when exact referential integrity from production is required for late-stage UAT or regulatory reporting that depends on precise data relationships.

The distinction comes down to what each approach preserves and what it sacrifices. Anonymized or masked data retains the exact structural relationships and statistical properties of production data — including the complex cross-table correlations that are hardest to replicate synthetically. For scenarios like user acceptance testing where system behavior must match production exactly, or for regulatory reports that require direct correlation to real data distributions, anonymization has a structural advantage. The tradeoff is that anonymized data inherits the full complexity of the source system and cannot be scaled up or down — anonymization algorithms typically produce a dataset of the same size as the original, which limits load testing and performance testing scenarios.

Synthetic data addresses the cases where anonymization falls short. It can be generated at any volume, engineered to include rare edge cases that do not exist in production, and shared freely across teams and external partners without privacy risk. Critically, sophisticated adversaries can sometimes de-anonymize masked data if enough external reference data is available — synthetic data eliminates this attack surface entirely because the records do not correspond to real individuals. For regulated industries operating under GDPR, high-quality synthetic data that cannot be mapped back to real individuals can fall outside the scope of many data protection provisions, subject to legal review — a meaningful compliance advantage that anonymization cannot always provide.

There is a genuine tradeoff on fidelity. Even the best synthetic generation introduces some approximation: rare correlations and complex multi-table patterns can be smoothed out or lost. For analytical use cases where those rare patterns matter — fraud detection edge cases, rare disease cohorts, low-frequency financial events — this approximation bias deserves careful evaluation. The right answer is context-dependent: synthetic data for development, testing, sharing, and AI training; anonymized data for production-grade validation and regulatory reporting that demands exact fidelity to real distributions.

How BlueGen helps with referential integrity in synthetic data

Preserving referential integrity across complex relational schemas is one of the hardest problems in synthetic data generation — and it is exactly what BlueGen is built to solve. Rather than treating tables in isolation, BlueGen takes a schema-first approach that understands your full data model before generating a single row, ensuring that every foreign key relationship remains valid throughout the entire generated dataset.

Here is what BlueGen delivers in practice:

• Schema-aware generation: BlueGen parses your full data model — including primary keys, foreign keys, cardinalities, and multi-hop dependencies — and generates parent tables before child tables, so referential integrity is enforced by design, not patched in afterward.
• Support for complex relational structures: BlueGen handles many-to-many relationships and indirect inter-table dependencies that simpler tools cannot manage, making it suitable for enterprise-grade schemas with dozens or hundreds of interrelated tables.
• GDPR-compliant by design: Built specifically for the European market, BlueGen ensures that generated data cannot be mapped back to real individuals — giving regulated industries a compliant path to safe data sharing and development without sacrificing referential integrity.
• Regulated industry focus: BlueGen serves healthcare, finance, and energy sectors where both structural correctness and privacy guarantees are non-negotiable requirements, not optional extras.
• CI/CD pipeline integration: BlueGen supports automated, scheduled generation so that your synthetic datasets stay in sync with schema changes — eliminating the stale test data that is a leading cause of broken referential integrity in development environments.

If referential integrity across your relational data is a bottleneck — whether for testing, AI training, or secure data sharing — request a demo with BlueGen and see how the platform handles your specific schema automatically.