DEV Community: Jitendra Devabhaktuni

Stop Generating Synthetic Datasets. Start Generating Synthetic Systems.

Jitendra Devabhaktuni — Tue, 14 Apr 2026 11:17:53 +0000

If you’re building AI for BFSI, insurance, or healthtech, you’ve probably evaluated synthetic data platforms. You upload a table. You get a table back. The distributions look right. The privacy report is green. You move to training.

Then production happens.

Your fraud model misses edge cases it should have caught. Your risk engine drifts after two weeks. Your QA team ships a bug because the test data didn’t reflect how users actually behave across multiple tables.
You didn’t build a bad model. You built it on a lie.

The Problem Nobody Talks About

Here’s the uncomfortable truth: most synthetic data platforms generate datasets, not systems.

A dataset is a single table with plausible rows. A system is a network of interconnected tables where:
• A user’s transaction history actually belongs to that user
• Claims link to valid policies with realistic timestamps
• Event sequences follow allowed state transitions
• Foreign keys, constraints, and referential integrity just… work
• Edge cases span multiple tables the way they do in production

When you generate isolated datasets, you break all of that. You get tables that look real individually but behave nothing like production when joined, queried, or fed into a model.
And that’s where AI pilots go to die.

Why Dataset-Level Generation Fails in Production?

I’ve audited synthetic data deployments across fintech, insurance, and healthtech.

The pattern is always the same:
1.Team generates synthetic tables for users, transactions, and events separately
2.Each table passes univariate fidelity checks
3.Tables are joined for model training
4.Correlations collapse. Referential integrity breaks. Temporal sequences become impossible
5.Model looks great in the notebook, degrades silently in production
The root cause isn’t the model architecture. It’s the assumption that you can generate tables in isolation and expect them to work together.
You can’t.

What AI Products Actually Need?

AI products don’t run on CSVs. They run on databases.

If you’re building a fraud detection system, you’re not just modeling transactions. You’re modeling:

• Users with histories, risk profiles, and behavioral patterns
• Transactions that link to those users with valid timestamps and merchant contexts
• Events that follow sequences (login → transaction → alert → investigation)
• Policies, claims, denials, and appeals that span multiple entities

If any of those relationships break in your test data, your model learns patterns that don’t exist in production.
You don’t need more data. You need structurally coherent data — a synthetic system that mirrors production complexity end-to-end.

The Shift: From Datasets to Databases
This is the mental model change the industry needs right now.

Instead of asking “Can this platform generate a high-fidelity dataset?”, ask:
• Can it generate a complete synthetic database with my full schema intact?
• Does it preserve foreign keys and referential integrity automatically?
• Do cross-table correlations match production, not just within-table distributions?
• Are temporal sequences and state transitions logically valid?
• Can I generate millions of rows across dozens of tables without structural collapse?
• Can I reproduce this exact database on demand for audit or debugging?

If the answer to any of these is “no” or “we don’t measure that,” you’re not ready for production.

A Better Way to Think About Synthetic Data

Here’s the framework I use when evaluating synthetic data infrastructure now:

Level 1: Dataset Generation
• Single-table fidelity
• Univariate distributions match
• Privacy checks pass
• Good for: Notebooks, proofs of concept, early prototyping

Level 2: Multi-Table Coherence

• Cross-table correlations preserved
• Foreign keys intact
• Joint distributions match production
• Good for: Model training, integration testing, QA environments

Level 3: Synthetic Systems
• Full schema fidelity (constraints, triggers, indexes)
• Temporal consistency across entities
• Realistic user journeys and event sequences
• Audit-ready generation logs with full reproducibility
• Good for: Production-safe testing, compliance reviews, realistic demos, load testing

Most platforms stop at Level 1. A few attempt Level 2. Almost nobody is building for Level 3.

But Level 3 is exactly what enterprise AI teams need to move from pilot to production.

Why This Matters for Regulated Industries?
If you’re in BFSI, insurance, or healthtech, you’re not just trying to train a model.

You’re trying to:

• Build and test AI applications end-to-end without touching production data
• Run product demos that feel real without exposing customer records
• Simulate production load for performance and QA testing
• Pass model risk review with traceability and privacy guarantees
You can’t do any of that with isolated datasets. You need synthetic systems.
And you can’t get there with prompt engineering or LLM-generated rows. This is infrastructure work — statistical fidelity, referential integrity, temporal modeling, and audit trail engineering.

*The Conversation We Should Be Having
*
Instead of debating “synthetic data vs. real data,” let’s talk about:
• How do we measure cross-table fidelity, not just within-table similarity?
• What does referential integrity preservation actually look like in practice?
• How do we validate temporal consistency for event-driven systems?
• What audit logs do model risk teams actually need to sign off?
• When is dataset-level generation enough, and when do we need full synthetic systems?

Because the future of enterprise AI isn’t about generating more data.
It’s about generating data infrastructure that behaves like production — structurally, statistically, and temporally.

Over to You
If you’ve shipped AI to production in a regulated environment:
• What broke when you moved from synthetic data to real data?
• Did your synthetic tables hold up when joined and queried together?
• What metrics did your model risk team actually care about?

If you’re evaluating synthetic data platforms right now:
• Are you testing single-table fidelity or multi-table coherence?
• Have you validated referential integrity and temporal consistency?
• Can you reproduce your test database on demand for audit?

Let’s talk about what it actually takes to build production-safe AI — not just in notebooks, but in the real world.

What’s your experience been? Drop a comment — especially if you’ve hit the dataset trap and had to climb out of it.

How synthetic test data can unblock your engineering team without breaking compliance

Jitendra Devabhaktuni — Tue, 07 Apr 2026 06:28:09 +0000

Most product and engineering teams want the same two things

Move fast on features and stay out of trouble with security and compliance

The tension usually shows up when you talk about test data

Engineers want realistic behavior and edge cases
Security wants less spread of real customer records
Compliance wants clear answers about where personal data goes and why

Synthetic data is one of the few approaches that can make all three groups reasonably happy at the same time

What we actually need from test data ?

If you look at how staging and QA environments are used day to day the requirements are pretty consistent

Realistic structure the same schemas tables and relationships as production
Realistic behavior similar distributions nulls weird formats and edge cases
Repeatability the ability to recreate scenarios when bugs appear
Safety test data should not increase the blast radius of a breach or misconfiguration

Cloning production gives you the first three but fails on safety

Heavily mocked or hand crafted data helps safety but usually misses behavior and edge cases

Synthetic test data tries to give you all four at once

How synthetic test data works in practice

Modern synthetic data systems such as what we are building with SyntheholDB do a few key things

Learn the structure and relationships of your existing tables primary and foreign keys distributions correlations constraints
Generate new records that follow the same patterns so tests still hit realistic values and edge cases
Remove direct identifiers and linkages to real people so individual users cannot be reconstructed from the synthetic dataset

The result is test data that behaves like your production data at a system level without being a copy of actual customer records

For engineering teams this means

You can spin up or refresh staging environments without waiting for a masked prod dump
You can share realistic sandboxes with vendors and contractors without exposing raw user data
You can simulate rare scenarios by generating more of the patterns that matter for a specific feature or service

For security and compliance teams it means

Fewer environments that hold real personal data
Clearer scopes when you document data flows and vendor access
An easier story to tell during audits about how non production systems are populated

Where SyntheholDB fits into this picture

SyntheholDB is designed to make synthetic test data usable in day to day engineering work instead of feeling like a separate research project

The focus is on:

Table aware generation so relational structures and constraints are preserved across multiple tables
Configurable privacy and utility profiles so teams can choose stronger privacy for some datasets and higher fidelity for others
Simple integration into existing pipelines so populating staging or QA with synthetic data feels like part of your normal CI or environment setup flow

The goal is straightforward:
Replace as many production clones in lower environments as possible with synthetic datasets that are safer by design but still useful for real testing

A simple way to get started?

If your team is curious about synthetic test data but has not tried it yet a practical approach looks like this

1 pick one non critical application or service where staging currently uses a prod clone

2 identify the core tables needed to exercise most test cases

3 generate synthetic versions of just those tables and wire them into a fresh environment

4 run your usual test suite and a few manual flows compare results with your current staging setup

5 iterate on the generation configuration until the main edge cases are covered

You do not need a big bang migration:
You can replace production clones environment by environment and table by table while keeping your current process as a fallback

Why this matters for the next 12 to 24 months?

Regulation and customer expectations around data privacy are not going to get looser. At the same time engineering teams are under more pressure than ever to ship quickly and experiment more

Synthetic test data is one of the few levers that improves both sides Less real data scattered across tools and environments. More freedom for product and engineering to build with realistic datasets

That is the problem space SyntheholDB is focused on, If your team is trying to move away from production clones in lower environments synthetic data is very likely the most practical path forward

How Synthetic Test Databases Replace Staging Snapshots

Jitendra Devabhaktuni — Wed, 01 Apr 2026 14:14:39 +0000

Stop Writing INSERT Scripts for Test Data

If you’ve been building products for a while, you’ve probably done this dance:

New feature.
New tables or columns.
Empty staging database.
“I’ll just write a few INSERT scripts to fake some rows…”

An hour later, you’ve got a wall of SQL, a half‑realistic dataset, and the quiet feeling that none of this is going to look like production anyway.

For years this was just “how it’s done.” Today, it’s a tax.

In this post, I want to lay out why hand‑crafted test data is breaking your velocity (and your tests), and what a better default looks like.

The hidden cost of hand‑written test data

The obvious cost is time: senior engineers spending hours writing INSERTs, CSVs, or seed scripts instead of shipping features.

But the deeper costs are more dangerous:

Your data is too clean

Synthetic in the worst way: perfect dates, perfect enums, no NULL hell. Your tests pass beautifully on this happy‑path dataset and then fall over in production.
Your relationships drift

You add a new table, a new foreign key, or a new join. Did you remember to update every seed script, every fixture, every CSV? If not, you end up with orphan rows and tests that silently stop covering real flows.
Nobody owns it

Test data becomes tribal knowledge. One person “just knows” which script to run or which dump to restore. When they’re busy (or leave), test environments quietly rot.
Compliance risk

To avoid writing data by hand, teams often copy masked production snapshots into staging. Masking is rarely complete. A few columns slip through, and now PII is sitting in places it shouldn’t.

Individually these feel like minor annoyances. Together, they create a slow, constant drag on every release.

What “good” test data actually means

When people say “we need realistic test data,” they usually mean more than just random rows.

A useful test database has at least three properties:

Referential integrity

Foreign keys are valid, constraints are respected, and joins behave the way they do in production.
Realistic distributions

Data “feels” like production: skewed, messy, correlated. Not everyone signs up on the last day of the month. Not every account has exactly three users.
Designed edge cases

You see the weird stuff on purpose:
- users with 0 orders,
- accounts with 1000+ invoices,
- subscriptions with overlapping billing periods.

Most hand‑written test data does okay on (1), fails on (2), and completely ignores (3). You get just enough to demo the happy path, but not enough to trust your system.

Why staging snapshots aren’t the answer

The usual response is: “We’ll just use a masked copy of production.”

That sounds great until:

Masking doesn’t catch everything, and suddenly you have PII in non‑prod.
Schema changes make your anonymization scripts brittle.
Refreshing the snapshot becomes a mini‑project every time you want to test a new flow.
You can’t easily generate new edge cases on demand, because the data is whatever production happened to look like last week.

Staging snapshots are a snapshot of the past. Most teams need a generator for the future.

A better default: synthetic relational test databases

The alternative is to treat test data as something you generate on demand, not something you “hope is still usable.”

The workflow looks more like this:

Describe the domain you care about (in schema or plain English).
Generate a full relational database that respects your constraints.
Tune volumes, distributions, and edge cases.
Regenerate whenever the schema changes.

You get:

Consistent, repeatable datasets for local dev, CI, demos, and staging.
No real customer records outside production.
The ability to intentionally create “weird” worlds to stress your system.

This is the mental model behind SyntheholDB: describe the database you wish you had for testing, then generate it instead of hand‑coding it.

What this looks like in practice

Here’s a simple example.

Imagine you’re testing a B2B SaaS app. You might say:

“I need 200 companies, 1–25 users per company, a mix of free and paid plans, and at least 20 companies with more than 50 invoices each.”

With the traditional approach, you’d:

Create CSVs for companies, users, subscriptions, invoices.
Write scripts to import them.
Fix foreign keys when something doesn’t line up.
Iterate until the data “looks okay”.

With a synthetic test database generator, you:

Express that requirement once.
Let the tool generate all the tables and relationships.
Re‑run when you change your schema or want a different scenario.

The output becomes an asset: you can spin up identical worlds for local dev, QA, and demos, without anyone touching INSERT scripts.

How to start (even without a fancy tool)

Even if you don’t use SyntheholDB or any specific product, you can still move towards this pattern.

A few practical steps:

Define your core entities and relationships explicitly

Write down the tables and constraints that matter most for testing. This becomes your “test world” spec.
Stop editing data directly in the DB

Always go through a generator, script, or seeding process. No more manual tweaks in staging.
Design edge-case scenarios as first-class citizens

Don’t wait for production to surprise you. Decide up front which “weird” configurations your system must handle and encode them.
Separate test data from real data in your mental model

Production is for truth. Testing environments are for exploring possibilities.

Once you think in generators instead of snapshots, the value of synthetic relational test data becomes obvious.

Closing thought

If you’re still writing INSERT scripts by hand in 2026, it’s not because you enjoy it.

It’s because the alternative feels like “too much work right now.”

The truth is the opposite: the more your product grows, the more expensive hand‑crafted test data becomes.

Whether you roll your own generator or opt for a tool, it’s worth asking:

What would it look like if test databases were never a bottleneck again?