Real data is often inaccessible due to strict regulations in medicine and finance, high labeling costs, or scarcity of rare scenarios. For example, an insurance company needed to generate 1 million synthetic policies while preserving correlations between age and risk. After platform deployment, the time for testing new models dropped from two weeks to two days. We integrate and customize data generation platforms that generate artificial samples retaining the statistical properties of the original while containing no confidential information. Our track record: over five years in MLOps and generative models, more than 50 implemented solutions.
Artificial data solves three key challenges: privacy compliance (GDPR, HIPAA without process changes), rare class expansion (dataset augmentation for Computer Vision or NLP), and system testing under load (generating millions of records with controlled distribution). Reference: General Data Protection Regulation (GDPR) - Wikipedia. We don't just produce — we verify each sample through statistical tests and ML Utility gap, which in 97% of projects does not exceed 2%.
Why synthetic data instead of real?
Generated data provides a controlled distribution unattainable with real samples. In insurance, we generated 10% rare losses that were less than 0.1% in the original data — the ML model's F1-score increased by 15%. This is impossible with simple augmentation.
Building a synthetic data platform
A typical solution architecture includes ingestion, generation, validation, and delivery layers. We use a modern stack: FastAPI for API, React for frontend, PostgreSQL for metadata, S3/MinIO for storage, PyTorch and Hugging Face for models.
┌─────────────────────────────────────────────────────────┐
│ Data Ingestion Layer │
│ [Real Data] → [Privacy Scan] → [Statistical Profiling] │
└─────────────────────────────────────────────────────────┘
↓
┌─────────────────────────────────────────────────────────┐
│ Generation Engine │
│ ┌──────────────┐ ┌──────────────┐ ┌──────────────┐ │
│ │ Tabular (GAN)│ │ Text (LLM) │ │ Image (Diff) │ │
│ └──────────────┘ └──────────────┘ └──────────────┘ │
└─────────────────────────────────────────────────────────┘
↓
┌─────────────────────────────────────────────────────────┐
│ Quality Validation │
│ [Statistical Fidelity] [Privacy Audit] [ML Utility] │
└─────────────────────────────────────────────────────────┘
↓
┌─────────────────────────────────────────────────────────┐
│ Delivery Layer │
│ [API] → [Data Catalog] → [Access Control] → [Audit] │
└─────────────────────────────────────────────────────────┘
Tabular data generation
For structured tables we use CTGAN (Conditional Tabular GAN) or Gaussian Copula — the choice depends on dataset size and required speed. CTGAN is 2x slower than Gaussian Copula, but delivers 5-10% higher accuracy on complex datasets.
from sdv.single_table import CTGANSynthesizer, GaussianCopulaSynthesizer
from sdv.metadata import SingleTableMetadata
metadata = SingleTableMetadata()
metadata.detect_from_dataframe(real_df)
# CTGAN — high quality, 500 epochs
ctgan = CTGANSynthesizer(metadata, epochs=500, batch_size=500,
generator_dim=(256,256), discriminator_dim=(256,256))
ctgan.fit(real_df)
synthetic_df_ctgan = ctgan.sample(100_000)
# Gaussian Copula — 10x faster, better at preserving correlations
copula = GaussianCopulaSynthesizer(metadata)
copula.fit(real_df)
synthetic_df_copula = copula.sample(100_000)
Related table generation
When data is normalized (patients → diagnoses → prescriptions), we use HMA Synthesizer, which models the relationship hierarchy.
from sdv.multi_table import HMASynthesizer
from sdv.metadata import MultiTableMetadata
metadata = MultiTableMetadata()
metadata.detect_from_dataframes({
'patients': patients_df, 'diagnoses': diagnoses_df, 'prescriptions': prescriptions_df
})
metadata.add_relationship('patients', 'patient_id', 'diagnoses', 'patient_id')
metadata.add_relationship('patients', 'patient_id', 'prescriptions', 'patient_id')
synthesizer = HMASynthesizer(metadata)
synthesizer.fit({'patients': patients_df, 'diagnoses': diagnoses_df, 'prescriptions': prescriptions_df})
synthetic_data = synthesizer.sample(scale=1.5)
How we evaluate quality and privacy
We don't deliver a black box to the client. Each produced sample undergoes three checks:
- Statistical Fidelity — Column Shapes and Column Pair Trends (score ≥ 0.9)
- Privacy Audit — data privacy membership inference (MI) attack (new row score > 0.9)
- ML Utility — Train on Synthetic, Test on Real (AUC difference < 2%)
Example code for privacy audit (ML utility test TSTR — Train on Synthetic, Test on Real):
from sdmetrics.single_table import NewRowSynthesis
new_row_score = NewRowSynthesis.compute(
real_data=real_df, synthetic_data=synthetic_df,
metadata=metadata, numerical_match_tolerance=0.01
)
# Target: score > 0.9 — synthetic data does not reproduce real records
And the ML Utility test shows whether the data is suitable for model training:
model_real = train_classifier(real_train, real_val)
model_syn = train_classifier(synthetic_train, real_val)
print(f"ML Utility gap: {(model_real.auc - model_syn.auc):.4f}")
# Acceptable < 0.02
Comparison of generation methods
| Method | Best for | Speed | Quality (Score) | Privacy |
|---|---|---|---|---|
| CTGAN | Tables with complex interactions | Medium (hours) | 0.90–0.95 | High |
| Gaussian Copula | Large tables with correlations | Fast (minutes) | 0.85–0.92 | High |
| HMA | Related tables (normalized DBs) | Medium | 0.88–0.93 | High |
| LLM (GPT, LLaMA) | Text fields, dialogues | Slow (days) | 0.95+ (NLP) | Requires fine-tuning |
Use cases for synthetic data platforms
The main scenario is a shortage of data for training or testing. In the banking sector, we replaced 70% of real transactions with synthetic ones for stress testing: p99 latency dropped by 30%, and anomaly coverage doubled. Get a consultation — we'll assess if your case fits.
How to get started
- Submit your dataset metadata or schema.
- Receive a demo synthetic dataset for evaluation.
- Review quality and privacy reports.
- Deploy the full platform with your data.
Project workflow
| Stage | Duration | Result |
|---|---|---|
| Analytics | 1–2 weeks | Source audit, sensitive field identification, generator specification |
| Design | 1–2 weeks | Model selection, pipeline architecture, quality metrics |
| Implementation | 6–8 weeks | Development of generation, validation, and deployment modules |
| Testing | 1–2 weeks | Run on your data, iterate on scores |
| Deployment | 1–2 weeks | Platform with UI/API, RBAC, monitoring, team training |
What's included in the result
- Full-featured platform with web interface and REST API on FastAPI and React.
- Integration with your Data Catalog and storage systems (S3, PostgreSQL).
- Automatic privacy audit and ML utility report for each dataset.
- API, architecture, and operation documentation.
- Team training (2–3 days).
- 3-month warranty support.
Implementation timeline
A typical project takes 3 to 4 months. A typical project investment ranges from $50,000 to $150,000, depending on complexity. The timeline may vary depending on the number of data types, source, and UI requirements. Contact us for a consultation — we'll prepare a commercial proposal tailored to your specifics and show a demo of the generator on your metadata the next day.
Consultation and commercial proposal
Our turnkey data platform, built with a FastAPI React data platform stack, includes the ML utility test TSTR. If you have questions about architecture or cost — write to us. We'll prepare a commercial proposal tailored to your specifics and demonstrate a generator demo on your metadata.







