Synthetic Data Generation in Production: Gretel, YData, Tonic, and Training ML Models When Real Data Is Off-Limits

Three years into my engagement with a regional hospital network, we had a problem that took me six months to solve. The ML team had built a solid patient readmission prediction model using three years of historical EHR data. The model worked. The problem was that we wanted to fine-tune it with more recent patient records, and those records lived in a system covered by a Business Associate Agreement that explicitly prohibited exporting identifiable data outside the clinical environment. The data science team was in a different legal entity. We couldn’t share the data. We couldn’t anonymize it well enough to satisfy the compliance team. We were stuck.

That problem forced me to seriously evaluate synthetic data generation for the first time. After twenty years of building data infrastructure, I thought I understood the data tooling landscape. Synthetic data changed my mental model in ways I didn’t expect.

The core insight: synthetic data is not fake data. It’s statistically learned data. A well-generated synthetic dataset preserves the joint distributions, correlations, and edge cases of the original without containing any actual records. Done correctly, you can train a model on synthetic data and achieve 90-95% of the performance you’d get from real data, while sharing that dataset freely across organizational boundaries.

This article covers how to build that pipeline in production: the technical approaches, the tools that matter in 2026, how to evaluate quality, and the cloud architecture that makes it sustainable.

Why Synthetic Data Has Finally Matured

For years, synthetic data generation was an academic exercise. The GANs were unstable. The statistical methods couldn’t capture multi-variate dependencies. The results weren’t actually usable for training.

Several things changed simultaneously. First, conditional tabular GANs got stable enough for production use. Second, LLM-based synthesis approaches emerged that can generate realistic text and structured data in ways that rule-based methods never could. Third, the regulatory pressure got real: GDPR enforcement actions, HIPAA audits, and state-level privacy laws made “just anonymize it” an insufficient answer. Fourth, the tooling finally got developer-friendly.

In 2026, I’m seeing synthetic data pipelines in production at healthcare companies, financial services firms, insurance carriers, and increasingly at any company that wants to share production-like datasets with contractors, offshore teams, or test environments without data governance headaches.

The Four Technical Approaches

Understanding the underlying methods matters because each tool in this space uses a different approach, and the choice affects quality, speed, and what kinds of data you can synthesize.

Statistical and parametric methods are the oldest approach. Libraries like SDV (Synthetic Data Vault) use Copulas to model the joint probability distribution of your dataset and sample from it. This works well for tabular data with clear statistical relationships and is fast and interpretable. The weakness is that Copulas struggle with high-cardinality categorical columns and complex non-linear relationships.

Deep learning methods using GANs and VAEs produce better results on complex datasets. CTGAN (Conditional Tabular GAN) is the reference implementation for tabular data, and it handles mode collapse better than earlier GAN architectures by conditioning the generator on column values. TVAE (Tabular Variational Autoencoder) is often faster to train and tends to produce better statistical fidelity for columns with many null values. The downside is training time and the compute cost, which matters at scale.

LLM-based synthesis is the newest and most interesting development. Tools like Gretel’s Navigator Fine-Tuning use large language models that have been fine-tuned on structured data to generate realistic tabular records from a schema and statistical profile. This approach is particularly powerful for free-text columns, complex nested structures, and cases where you need domain-specific realism that statistical methods miss entirely. Asking a GAN to generate realistic clinical notes is a bad idea. Asking a fine-tuned language model to generate realistic clinical notes, constrained by the statistical profile of real notes, actually works.

Rule-based and template methods remain useful for specific domains. If you need synthetic financial transactions, there are domain libraries that encode known behavioral patterns (transaction frequency distributions, typical amounts by merchant category, etc.) that outperform learned synthesis for out-of-distribution generation.

The Tool Landscape in 2026

The market has consolidated somewhat but there are still meaningfully different tools targeting different use cases.

Gretel.ai is where I start for most greenfield synthetic data work. Their Python SDK is clean, their cloud platform handles compute automatically, and they’ve invested heavily in the Navigator approach that combines fine-tuned language models with tabular synthesis. The gretel-client library makes it trivial to connect to their cloud, train a model on your data, and generate. What I like about Gretel is that they’ve solved the developer experience problem: you can have a synthetic dataset in a day without deep ML expertise. Their privacy evaluation reports are also solid, which matters when you need to show compliance teams that you’ve done the work. The limitation is cost at scale: generating hundreds of millions of rows gets expensive.

YData Fabric is stronger in the data-centric AI space. They started from the data quality angle and added synthesis later, which means their tooling around profiling, monitoring, and evaluation is more mature than Gretel’s. Their open-source ydata-profiling library is a de facto standard for data quality reporting. For organizations that want to run synthesis on-premises inside a secured perimeter, YData’s self-hosted option is often the right answer. I used it at the financial services client I mentioned above: the synthesizer trained inside the regulated environment, and only the synthetic output crossed the boundary.

Tonic.ai takes a different angle: they’re primarily focused on developer data, meaning creating synthetic versions of your production database for test environments. If your problem is “how do I give developers realistic-looking data in staging without copying production PII into the wrong environment,” Tonic is the right answer. They support PostgreSQL, MySQL, MongoDB, and several others, and their subsetting and relationship-preserving masking is genuinely good. They’re not optimized for ML training data, but for test data provisioning they’re the strongest option I’ve seen.

SDV (Synthetic Data Vault) from DataCebo is the best open-source option. If you have the time to build and maintain your own pipeline, SDV gives you access to multiple synthesis algorithms (CTGAN, TVAE, CopulaGAN, GaussianCopula) under a unified API with reasonable defaults. It handles relational data (multiple tables with foreign key relationships), which is a real differentiator. For teams with a data engineer who wants full control without vendor dependency, SDV is where I’d start.

Mostly.ai focuses on enterprise tabular synthesis with a strong emphasis on privacy guarantees and regulatory compliance. Their AI-based synthesis has been validated in several European financial and healthcare deployments where regulators accepted the synthetic data as compliant. If you’re operating in a heavily regulated European context, their compliance documentation is more mature than the alternatives.

Building a Production Synthetic Data Pipeline

Generating a single synthetic dataset manually is straightforward. Building a pipeline that keeps synthetic data fresh, evaluated, and trusted is where most teams underinvest.

The pipeline has four stages: ingest, synthesize, evaluate, and serve. The integration with your broader data pipeline orchestration setup matters as much as the synthesis itself.

Ingestion and profiling is the first step. Before you can synthesize, you need a statistical profile of the source data. This profile becomes the reference against which you evaluate synthetic quality. You also need to identify which columns contain PII and apply appropriate handling (columns that are structurally important but contain PII should be generalized or hashed before synthesis, not just dropped). Running ydata-profiling or a similar tool on the source data produces the baseline report you need.

Training the synthesizer should be treated like training an ML model: versioned, reproducible, with tracked hyperparameters. I store the trained synthesizer model in MLflow alongside the source data profile. The training run logs epoch loss curves (for CTGAN/TVAE), and I fail the pipeline if the discriminator loss doesn’t converge within expected bounds. Training time varies wildly: a 100k-row, 30-column tabular dataset might take 10-20 minutes on a GPU with CTGAN; a multi-table relational dataset might take several hours.

Evaluation is where most teams cut corners and regret it. You need to measure two dimensions: utility (does the synthetic data behave like real data for modeling purposes?) and privacy (could an adversary use the synthetic data to recover information about individuals in the training set?). These two metrics trade off against each other, which is why a single “quality score” is usually misleading.

For utility, the most reliable metric is the Train-on-Synthetic, Test-on-Real (TSTR) score: train your actual ML model on synthetic data, test on held-out real data, and compare to the baseline of train-and-test on real data. A TSTR/TSTS ratio above 0.90 is generally acceptable. Column-level statistics (mean, standard deviation, quantiles, value frequency distributions) and cross-column correlation matrices provide leading indicators before you run the full TSTR evaluation.

For privacy, the three metrics I always include are singling-out rate (can you identify a unique individual in the training set from the synthetic data?), linkage rate (can you link synthetic records to real individuals using auxiliary information?), and inference rate (can you use synthetic data to infer sensitive attributes of training individuals?). SDV’s sdmetrics library computes these. Gretel’s privacy report computes similar metrics. No tool gives you perfect privacy guarantees, but these metrics should be below acceptable thresholds before you distribute synthetic data to untrusted parties.

Serving the synthetic data to consumers means treating synthetic datasets like any other data asset: versioned, cataloged, and with lineage tracked. I register synthetic datasets in the same data catalog as the source data (whether that’s OpenMetadata, DataHub, or something else), with clear metadata indicating it’s synthetic, when it was generated, from what source data version, and what evaluation scores it achieved. This is table stakes for building trust with the teams consuming the data.

Evaluating Quality: The Utility-Privacy Tradeoff

This tradeoff is real and you need to understand it before presenting synthetic data to stakeholders. More privacy protection almost always means less utility, and vice versa.

CTGAN with standard settings produces high-utility, moderate-privacy synthetic data. Adding differential privacy mechanisms to the synthesis process (Gretel supports this, SDV’s synthesizers module supports epsilon-bounded DP) improves the privacy guarantees but degrades utility, sometimes significantly. For most enterprise use cases where the data stays within the organization’s ecosystem, I don’t use DP synthesis because the utility cost isn’t worth the marginal privacy gain. For cases where the synthetic data will be published or shared with external parties, DP synthesis is worth the tradeoff.

The privacy evaluation results also depend heavily on how you handle rare population groups in the training data. If your dataset has 500k records but only 12 patients with a particular rare condition, a synthesizer that faithfully reproduces those 12 records might effectively be re-creating real individuals. This is where domain knowledge matters: you need to decide whether to collapse low-frequency categories, generalize rare values, or exclude those subpopulations from synthesis entirely.

I’ve had this conversation with compliance teams many times. The argument I make is: “We’re not trying to achieve perfect privacy. We’re trying to demonstrate that the risk of re-identification from this synthetic dataset is lower than the risk from the masked production data you’re already sharing with vendors.” Framed that way, the privacy evaluation scores become a comparative tool rather than an absolute threshold.

For integration with your data quality observability stack, I track synthetic data quality metrics in the same dashboards as real data quality. If the TSTR score drops below 0.85 on a pipeline refresh, I want the same alerting that fires when real data quality degrades.

Integrating with Your MLOps Stack

Synthetic data generation doesn’t exist in isolation. It needs to connect to your feature stores, your training pipelines, and your model registries.

The integration pattern I use most often: the synthetic data pipeline runs on a schedule (weekly or on source data version change) and outputs synthetic datasets to an object storage bucket with versioned paths. The downstream ML training pipelines consume synthetic data by version, the same way they’d consume any other dataset. The training pipeline logs which synthetic data version it used as a run parameter in MLflow or Weights and Biases. This gives you full lineage from source data through synthesis to model version.

For LLM fine-tuning workflows, synthetic data is increasingly critical. The challenge is that fine-tuning data for enterprise LLMs often contains customer information, internal business logic, or regulated content. Generating synthetic conversation data, synthetic document examples, or synthetic instruction-response pairs using a larger teacher model is a pattern I’m seeing more of in 2026. The teacher model (say, a frontier model accessed via API) generates synthetic training examples that preserve the style and domain coverage of real examples without containing actual customer data. This is different from the tabular synthesis I’ve been describing, but the same evaluation principles apply: measure whether a model fine-tuned on synthetic examples performs comparably to one fine-tuned on real examples.

When using synthetic data in data contracts between teams, make sure the contract explicitly specifies the synthesis method, the evaluation scores, and the acceptable use cases. A synthetic dataset appropriate for ML model development might not be appropriate for UI testing or load testing, and the contract should say that explicitly.

Cloud Architecture for Synthetic Data Generation

At scale, the synthesis step is compute-intensive. CTGAN training on a 10M-row dataset requires GPU compute, and you don’t want to run that on shared infrastructure.

The pattern I’ve settled on runs synthesis training on spot GPU instances (G5 or G4dn on AWS, A2 or G2 on GCP) triggered by an Airflow DAG. The trained synthesizer model is stored in S3 or GCS with versioning. Generation (sampling from the trained model) is less compute-intensive and can run on standard compute. The evaluation step runs on standard CPU compute with a parallelized statistical comparison step.

For organizations using Gretel’s cloud platform, they handle the compute provisioning for you. The tradeoff is cost and the requirement to send source data to an external service. Gretel runs in AWS and they sign BAAs for HIPAA-covered customers, but some compliance teams still won’t approve sending source data outside the organizational perimeter regardless of contractual protections. In those cases, YData self-hosted or SDV running in your own environment is the right architecture.

The entire pipeline should be managed as code. Treating your synthesizer configuration (algorithm choice, hyperparameters, column metadata, privacy settings) as a versioned artifact alongside your infrastructure as code is what makes it reproducible and auditable.

Regulated Industry Use Cases

Healthcare is the canonical use case. HIPAA’s Safe Harbor method for de-identification requires suppressing or generalizing 18 specific identifiers, but that approach destroys a lot of the statistical structure that makes data useful for modeling. Synthesis is a better answer when the goal is preserving predictive utility for internal ML development.

The framing that’s worked for me with hospital compliance teams is this: the synthetic data is generated within the covered environment and evaluated there. What leaves the environment is a dataset that contains no real patient records. The compliance team reviews the privacy evaluation report, confirms that re-identification risk is below their threshold, and approves the output for use by the external ML team. This is materially different from “de-identify and share,” because the synthesis process doesn’t need to suppress useful information to protect privacy.

Financial services is equally challenging. Transaction data contains behavioral patterns that are commercially sensitive even if individual records aren’t personally identifiable. Synthetic transaction datasets let fraud detection teams share representative data with analytics vendors without exposing the actual transaction patterns of specific customers. At one bank, we generated synthetic transaction data for vendor evaluation exercises: vendors could demonstrate their fraud detection algorithms worked on realistic data without ever touching real customer records.

Insurance actuarial data has similar characteristics: the joint distributions between age, health indicators, claim history, and policy terms are proprietary, even if individual records aren’t identifiable. Synthetic datasets let actuarial teams collaborate with external partners without sharing the underlying pricing model’s training data.

When Not to Use Synthetic Data

Twenty years of infrastructure work has taught me that every tool has a failure mode. Synthetic data has several.

Small datasets are the first failure mode. If your source dataset has fewer than 5000 records, CTGAN and TVAE models don’t have enough signal to learn robust distributions. The synthetic output will overfit to the training data and may effectively memorize individual records, defeating the privacy purpose. Statistical methods work better at small data sizes, but their utility is also limited. If you have small data, the answer is usually to collect more real data, not to synthesize.

Highly imbalanced datasets cause synthesis to amplify the imbalance unless you explicitly handle it. A fraud detection dataset with 0.1% fraud rate will produce synthetic data where fraud records are statistically underrepresented unless you either oversample during synthesis or use conditional generation that targets fraud vs. non-fraud records separately.

Time-series and sequential data is harder than tabular. The autoregressive dependencies in time-series data are difficult for CTGAN to capture. There are specific tools for time-series synthesis (TimeGAN, DoppelGANger), but they’re less mature and require more tuning. If your use case involves time-series, evaluate carefully before committing.

Distribution shift is a silent killer. The synthesizer learns the distribution of your historical training data. If your production data distribution has shifted (new product features, changed customer demographics, pandemic-era behavioral changes), the synthetic data will reflect the old distribution. You need to refresh your synthesizer model on recent source data regularly, and you need to track when distribution shift makes existing synthetic datasets stale.

Finally, synthetic data is not a substitute for real data when you need genuine diversity and edge cases. Synthesizers generate records that are statistically similar to the training distribution. Rare events, novel situations, and distribution tails are often underrepresented or distorted. For anomaly detection models where you’re explicitly trying to capture rare events, synthetic data can mislead more than it helps.

The MLOps Integration

The MLOps practices you’ve built for model training apply to synthesizer training too. Treat your synthesizer as a model: version it, track experiments, monitor for drift in the synthetic data quality over time. The synthesizer that worked well six months ago on a particular source dataset might produce degraded output if the source distribution has shifted.

Setting up automatic evaluation on a cadence, with alerting when quality metrics degrade, is what separates teams that successfully use synthetic data at scale from teams that generate a dataset once and trust it indefinitely.

The investment in building this pipeline properly is front-loaded. Once it’s running, the marginal cost of generating a fresh synthetic dataset is low, and the organizational value of being able to freely share production-like data across team boundaries is significant. I’ve seen this unlock machine learning work that was genuinely blocked by data governance for years. That’s not a marginal improvement. That’s the difference between a model that ships and one that never does.

Synthetic data generation has become a practical tool in the cloud architect’s kit for 2026. The tooling is mature enough that teams without deep ML expertise can build production pipelines in weeks. The regulatory environment means you almost certainly have use cases where it’s the right answer. And the pattern of treating synthetic datasets with the same rigor as real datasets, with versioning, quality evaluation, and lineage tracking, is what makes it trustworthy rather than just fast.

Start with SDV or Gretel on a non-production dataset to understand the quality tradeoffs before committing to architecture decisions. The utility-privacy evaluation is where most teams underinvest, and it’s where the real work is. Once you’ve done that evaluation on your actual data with your actual downstream use case, you’ll have a much clearer picture of whether synthesis is the right answer for your specific constraints.