Obsvra

All comparisons

SpiceGrinder vs. AI-Generated Synthetic Data (Tonic, Gretel, MOSTLY AI)

Short version: both approaches can, in their own ways, mirror the shape of a real dataset. The difference is what you end up holding — a trained model whose weights are derived from your data, or a readable model file that says Lognormal mu=8.0 sigma=1.2 and never needs the data again.

First, the state of that market

It has moved fast, so bear in mind when you evaluate:

  • Gretel was acquired by NVIDIA in March 2025 and folded into NVIDIA’s cloud AI services. It’s no longer an independent product in the way most comparison articles still describe.
  • MOSTLY AI ceased operations in March 2026.
  • Tonic.ai remains the most prominent independent vendor in this space.

By the time you read this, the landscape very well may have changed again.

What the generative approach does well

Train a model — commonly a GAN or a transformer — on a real dataset, then sample new rows from it. When you have a large, representative real dataset and you want synthetic data that mirrors its statistical shape closely, including correlations nobody thought to write down (or even knew about), this is a legitimately powerful technique.

It’s also the right tool when the point is fidelity to an existing population: ML training augmentation, analytics on a shape you already have, or handing a partner something distributionally faithful to your real book of business.

The three potential concerns baked into that approach

You need the real dataset first. That puts you back at the problem a lot of teams adopt synthetic data to escape: getting engineers access to a copy of production. The training step is a production-data access path. It may be a well-governed one, but it exists, and a privacy review will find it. If your blocker is “we can’t get a copy of prod,” then a tool that requires a copy of prod hasn’t solved your problem.

The output is a sample, not a result. Run it twice, get two different (similarly-shaped) datasets. For most analytics work that’s fine. For a regression test, an exact-comparison fixture, or a “reproduce this specific failure” bug report, it’s a problem — you can’t diff against a baseline that changes.

There’s also a subtler issue: a trained model can only produce variations on what has already happened. If you’re testing a product that doesn’t exist yet, a regulation that takes effect next year, or a stress scenario your book has never seen, there’s nothing to train on. A trained model can make a guess for you, but you have little control as to how it makes that guess.

If you do have a dataset, you can fit a model to it

A written description is the expected common case for SpiceGrinder, but it isn’t a requirement. If you have a real sample and want synthetic data that matches its statistical shape, point an agent that can run code at it with our fit-model-to-sample skill (the fitting runs actual computation, so it needs somewhere to execute it). It computes summary statistics per column and tests candidate distributions with real statistical tests (KS, AIC/BIC) rather than eyeballing a few rows, checks pairwise correlation across numeric columns and reaches for MultivariateNormal where genuine covariance exists, looks for mixed sub-populations before concluding a column “doesn’t fit anything,” and treats patterned outliers as a case for Perturb rather than inventing another mixture component.

What comes out the other end is the important part. It’s a model file, not an opaque set of weights.

Fit a book of claims and what lands in your repo is this:

<dataset seed="42">
    <root node="ClaimObservation"/>
    <nodes>
        <Append name="ClaimObservation">
            <input name="Frequency"/>
            <input name="Severity"/>
        </Append>
        <Poisson name="Frequency" lambda="3.47"/>
        <Lognormal name="Severity" mu="7.94" sigma="1.18"/>
    </nodes>
</dataset>

Claim counts are Poisson with a mean of 3.47 per period; severity is log-normal, so it clusters low and stretches into a long tail. You can disagree with that. You can check it against your own data. You can change mu to 8.4 and see what a worse year does to your reserving model, then commit the diff so a reviewer knows exactly what you changed and why. None of those three sentences is true of a trained network’s weights.

That distinction is real:

  • You can read it. Lognormal mu=8.0 sigma=1.2 tells you what the model believes about your data, and it is something you can independently verify. A GAN’s parameters tell you nothing, which matters when someone has to sign off on the fit.
  • Sampled once, then disconnected. Once fitted, generation never touches the source data again — the model is not a derivative of it in any recoverable sense. A trained generative model is derived from its training set, which is precisely why membership-inference attacks are an active research area in that field but would not apply to a SpiceGrinder fitted model.
  • You can edit the fit. Widen a tail, shift a mean, triple the catastrophe year to stress the reserving model. You cannot hand-edit a trained network to do that.
  • It’s deterministic from then on. Same model, same seed, same bytes, forever.
  • It avoids laundering identifying values. The skill explicitly refuses to replay real SSNs, names, or emails into a “synthetic” model and routes them to the matching business object instead — because replaying them isn’t synthetic data, it’s the original data with extra steps.

The skill ships in the public spicegrinder-cookbook repo, so you can read exactly what it does before pointing it at anything — and it runs inside your own agent, against a sample that never has to leave your machine.

The honest limit: this method finds structure that someone can look for. It fits named distributions and measured correlations well, but a trained model can capture high-dimensional interactions nobody thought to check. If your data’s value is in deep unarticulated structure across many columns, a generative platform may mirror it more faithfully.

The compliance argument, stated structurally

Nothing ever leaves your perimeter — no cloud service, no telemetry, no license-server check-in, at any tier, including while you design and edit the model. You can verify that from the outside rather than taking our word for it.

And separately: the generation model requires no real data as input. There is no training step, so there is no point at which a copy of production has to exist for SpiceGrinder to work. Fitting a model to a sample, above, doesn’t contradict that — it’s an optional one-time analysis, run by your agent on your machine, and the model it produces carries no dependency on the sample afterward.

To be precise about the rest of it, because it’s the kind of claim a careful reader would otherwise notice and object to: Pro does ship components that can read external sources — FlatFile, Database, ServiceCall — so it would be wrong to say the engine cannot ingest anything. What’s true is that it never needs to, that all three are allowlist-gated and refuse everything remote by default. Pointing to a source is a decision you make explicitly, inside your own infrastructure.

That’s a different kind of claim than a privacy guarantee expressed as a differential-privacy epsilon. Both are legitimate; one is an architectural fact and the other is a tuning parameter.

Where the generative platforms are the better call

  • You need structure nobody thought to look for, or even knew existed. A trained model captures high-dimensional interactions without anyone specifying them. A fitted model contains what the fitting process tested for. That’s the real modeling difference between the two approaches.
  • Fidelity to an existing population is the whole point. If the deliverable is “statistically indistinguishable from our production table” as judged by a third party, that’s their design goal, they’re built for it, and they’d probably beat us at it in most cases.
  • De-identifying an existing database is the actual task. Tonic’s subsetting and masking work on data you already have. SpiceGrinder doesn’t do that at all.

And our own honest limit: SpiceGrinder Free is numeric-only with a 20-node cap. Modeling a full relational schema with realistic strings means Pro at $199/month.

Try it

Download SpiceGrinder Free →

Market status checked 2026-09-13.