NeMo Data Designer: Column-Based Synthetic Data Generation with Samplers, LLM Columns and Validators
🎨 NeMo Data Designer: Generate high-quality synthetic data from scratch or from seed data.
At a glance
- What is it?
- NVIDIA's Apache-2.0 Python library builds synthetic datasets as a declarative column graph, mixing category samplers, LLM prompts, validators and MCP tool calls. It is a good fit when field relationships and validation matter more than raw prompt throughput, and a poor fit if you just want a one-line text generator.
- Who is it for?
- Adopt Data Designer if your synthetic dataset is a schema with relationships and validation rules, not a pile of prompts, and if you can accept a per-column configuration surface plus LLM API costs. Do not adopt it if you need a single-call text generator, or if you cannot send data to NVIDIA Build, OpenAI or OpenRouter.
- Can I use it commercially?
- Yes. Apache-2.0 is a permissive licence: you can use, modify and sell software built on it, as long as you keep its copyright and licence notices.
- Is it still maintained?
- Yes. The repository received new commits within the last day.
- What is it written in?
- Mainly Python, according to GitHub's language statistics.
Answers come from the project's GitHub data, last synced on September 15, 2026, and from our analysis. They are not legal advice.
DEEP OPEN-SOURCE ANALYSIS
The problem: LLM prompting alone does not produce a dataset
A loop that calls a model with the same prompt and writes the outputs to JSONL gives you samples. It does not give you a dataset with controlled field distributions, dependencies between fields, or any guarantee that a generated record passes a rule you care about. Data Designer is aimed at that gap. The README frames it as generating datasets that "go beyond simple LLM prompting", and the feature list is explicit about what that means: statistical distributions, correlations between fields, and validated outputs.
The intended user is an engineer or data scientist building training or evaluation data where the schema is the deliverable. The README lists text, structured data and images, multimodal workflows with image, audio and video context, and tool-use traces captured through MCP servers. The person-sampling documentation linked from the README suggests a second audience: teams that need synthetic records with demographic attributes rather than free-form prose. If your task is "write 500 product descriptions", this is more machinery than you need.
Columns as the unit of work, and how dependencies flow
The core abstraction is a column added to a `DataDesignerConfigBuilder`. Each column declares its own type and parameters, and later columns reference earlier ones by name inside a prompt template. In the README example, a `SamplerColumnConfig` named `product_category` draws from a fixed list of values via `CategorySamplerParams`, and an `LLMTextColumnConfig` named `review` then references `{{ product_category }}` in its prompt string.
That ordering is the mechanism. The sampler produces a value, the LLM column consumes it through template substitution, and the resulting record is a row of named fields rather than a blob of text. The README describes this as dependency-aware generation, which is the part that distinguishes the library from a prompt runner: the sampler is not a prompt, it is a deterministic draw from a distribution you specified, so the category field has the exact value frequencies you configured regardless of what the model does.
Validation sits on the same structure. The README lists Python, SQL, custom validators and LLM judges, and points to a dedicated validators concept page. A validator attached to a column is a check on that column's output, which means quality control is expressed in the config rather than in a post-processing script. The README also mentions plugins for custom columns, seed readers and processors, so the column set is extensible rather than fixed. What the README does not state is the execution order between validators and downstream columns, or what happens to a record that fails validation. Those details live in the linked documentation, not in the repository front page.
Install, keys, and the config CLI
The documented install is a single package: `pip install data-designer`. The README carries a note that the project downloads and installs additional third-party open source software and that you should review those licences before use. Installing from source is `git clone https://github.com/NVIDIA-NeMo/DataDesigner.git`, then `cd DataDesigner`, then `make install`.
Model access is key-based. The README names three default providers (NVIDIA Build API, OpenAI, OpenRouter) and the environment variables `NVIDIA_API_KEY`, `OPENAI_API_KEY` and `OPENROUTER_API_KEY`. At least one is required for any LLM column to run. The README example uses `model_alias="nvidia-text"`, which is a name resolved through configuration rather than a hard-coded model id. That resolution is handled by the CLI: `data-designer config providers` to configure providers, `data-designer config models` to set up model configurations, and `data-designer config list` to view current settings. Anyone pointing the library at a self-hosted endpoint should expect to go through those commands rather than editing a Python constant.
The README's quick-start ends with `data_designer.preview(config_builder=config_builder)` followed by `preview.display_sample_record()`. Preview is the documented way to inspect a small sample before committing to a large run, and the README separately mentions resume and monitoring for larger jobs. The supported Python range is stated as 3.10 through 3.14 on the badge.
Telemetry is on by default and the README says so
Data Designer collects telemetry unless you set `NEMO_TELEMETRY_ENABLED=false`. The README states the data is not used to track individual user behaviour, that it is used to see which models are most popular for synthetic data generation in aggregate, and that the aggregate will be shared with the community. The README even publishes a chart of top models used year to date.
This is unusually candid for a library in this category, and it is also a real constraint. Any organisation with rules about outbound telemetry from developer machines or CI runners has to set the variable before the first run, not after. The README does not spell out the full payload in the section reproduced here; it links to a longer telemetry and privacy section. Treat the default as on and the disable switch as the thing to verify.
Where it is the wrong tool
The dependency on hosted model providers is the sharpest limitation. Every default provider in the README is a remote API reached with an API key. If your data cannot leave your network, the quick-start path does not apply, and you are relying on whatever custom model configuration the CLI supports. The README shows the commands exist but does not, in the material available, demonstrate a fully local provider end to end.
The second limitation is the configuration surface itself. A dataset expressed as a chain of column configs is auditable and reproducible, and it is also more code than a prompt string. For a one-off set of a few hundred examples, the sampler and validator machinery is overhead you will not recover. The README's own quick-start needs an import, a `DataDesigner()` instance, a config builder, two column configs and a preview call before you see a single record. That is the right shape for a pipeline you will rerun; it is the wrong shape for a throwaway script.
The third is that the README does not state cost controls, rate-limit behaviour, or what happens when a validator rejects a record mid-run. Those are the questions that decide whether a large job finishes or burns budget, and they are not answered on the repository front page. Absence in the README is not absence in the product, but it is absence in the material a reader can check quickly.
How it differs from prompt-first tools and from writing your own loop
The obvious alternative is a general synthetic data framework built around prompt templates and a model call, where the prompt is the primary artefact and the output schema is whatever the model returns. The difference in approach is where control lives. In a prompt-first tool you steer the model with instructions and hope the distribution of categories comes out roughly right. In Data Designer the category distribution is a `CategorySamplerParams` list, decided before the model is called, and the model only fills the fields that genuinely need generation.
Writing your own loop is the other alternative, and it is a fair comparison because the quick-start is short enough to imitate. What you would have to rebuild is the column dependency resolution, the validator attachment, the plugin points for custom columns and seed readers, and the preview and resume behaviour. The README also lists an agent skill installable with `npx skills add NVIDIA-NeMo/DataDesigner`, tested with Claude Code and Codex, which lets a coding agent handle schema design and generation from a description. That is a different bet: you trade explicit config for a natural-language description, and the README states the skill is tested with those two agents specifically, which is a narrower support statement than the library itself carries.
Maintenance, versioning and licence
The library is on a steady release cadence, with v0.9.0 in August 2026 followed by v0.9.1 and v0.9.2 in the weeks after, and the repository is not archived. Version numbers below 1.0 are worth reading as a signal: the configuration API shown in the README, including class names like `SamplerColumnConfig` and `LLMTextColumnConfig`, is the kind of surface that can shift between minor releases. Anyone pinning this in a production pipeline should pin the version too, and should read the release notes for each 0.9.x bump rather than assuming the config builder is stable.
Documentation has its own migration note. The README states that contributors should edit prose under `fern/`, that tutorial notebook source lives in `docs/notebook_source/*.py`, and that generated notebooks and Fern artefacts are not the source of truth. A legacy MkDocs archive remains on GitHub Pages for releases 0.5.7 and older. That means older tutorials found through search may describe an API that no longer matches the current docs.
On licensing: the repository is Apache-2.0, which is permissive and includes an explicit patent grant. The README separately warns that installation pulls in additional third-party open source projects whose terms you should review. Apache-2.0 covers the code in this repository, not the model providers you call or the dependencies pip resolves. That is a description of what the files say, not legal advice; if your organisation has a licence review process, the dependency tree is the part that needs it.
Editorial conclusion
Adopt Data Designer if your synthetic dataset is a schema with relationships and validation rules, not a pile of prompts, and if you can accept a per-column configuration surface plus LLM API costs. Do not adopt it if you need a single-call text generator, or if you cannot send data to NVIDIA Build, OpenAI or OpenRouter. Before committing, run `data-designer config providers` and `data-designer config models` against your own endpoint, confirm the Python version your environment ships falls inside the documented 3.10 to 3.14 range, and check whether `NEMO_TELEMETRY_ENABLED=false` is required by your policy.
Community notes