SDV: a Python library for generating and scoring synthetic tabular data

The gap SDV fills: tabular data you can hand to someone else

Most teams that want synthetic data do not want a research model. They want a table that looks like the production table, keeps the column types, keeps the relationships between columns, and does not contain the real customer email addresses. SDV is built around that request. The README describes it as a Python library for creating tabular synthetic data that uses machine learning algorithms to learn patterns from real data and emulate them in synthetic data. The three advertised capabilities map to three jobs: generation, evaluation, and preprocessing with anonymization and constraints. The target user is a data engineer or applied scientist who already has a pandas-shaped dataset and needs a second dataset with the same shape. It is not aimed at people generating text, images or graph structures; nothing in the supplied material claims those. It is also not aimed at someone who wants a one-line fake-data generator with no configuration. The metadata object is mandatory, and that is a deliberate design choice rather than an accident.

Metadata as the contract between your table and the model

The mechanism SDV exposes is simple to state. You describe the dataset once, in a metadata object, and then hand that object to a synthesizer. The README's demo loads both pieces at once through download_demo(modality='single_table', dataset_name='fake_hotel_guests'), which returns real_data and metadata. The metadata is described as a description of the dataset including the data types in each column and the primary key, which in the demo is guest_email. From there the synthesizer is constructed with the metadata and fitted on the data. That sequencing matters: the metadata tells the synthesizer which columns are keys, which are categorical, which are dates, and how tables relate. In a multi-table setup, the same metadata is what carries the primary key to foreign key links, which is how the README can claim that connections between tables make sense in the output. The library also exposes several model families behind this one interface, from GaussianCopula, described as a classical statistical method, to CTGAN, described as a deep learning method. The repository topics list GANs, time series and relational datasets, so the same metadata-plus-synthesizer pattern is meant to stretch across those modalities. The practical consequence is that model quality and metadata correctness are coupled. If the metadata mislabels a column, the synthesizer learns the wrong distribution and the evaluation report will show it, but only after you have fitted a model.

Fitting, sampling and the quality report in practice

The README's getting-started path is short. Install with pip install sdv, or with conda install -c pytorch -c conda-forge sdv. Note the channel list in the conda command: pytorch appears alongside conda-forge, which is consistent with the deep learning models in the library. Then construct a synthesizer, fit it, and sample. The README uses GaussianCopulaSynthesizer(metadata), then synthesizer.fit(data=real_data), then synthesizer.sample(num_rows=500). The sample call takes a row count, so you can generate more or fewer rows than the original. Evaluation is a separate import, evaluate_quality(real_data, synthetic_data, metadata), which returns a quality report. The README's example output shows two sub-scores, Column Shapes at 89.11 percent and Column Pair Trends at 88.3 percent, averaged into an overall score of 88.7 percent. Those numbers belong to the demo hotel dataset and to that particular fit; they are not a claim about your data. The useful part is the structure: one score for how well individual columns match, one for how well pairs of columns move together. That second score is what separates a synthetic dataset that is merely plausible column by column from one that preserves correlations. The README's own example of preserved structure is the correlation between room rate and room type. If your downstream use depends on correlations, the pair trends score is the one to read first.

Anonymization and constraints are declared, not inferred

Two features in the README deserve separate attention because they change what you have to write. The first is anonymization. The README states that sensitive columns are fully anonymized, and names email, billing address and credit card number as columns that contain new data so the real values are not exposed. The second is constraints, described as business rules in the form of logical constraints. Both of these are things you configure rather than things the library guesses. That is a reasonable design, but it puts the burden on you to know which columns are sensitive and which rules must hold. A synthesizer that produces a check-in date before a booking date, or a room rate outside the range your business allows, is a synthesizer whose output will fail validation downstream. The README lists preprocessing, anonymization and constraints as one feature area, which suggests they are configured together before fitting. The supplied material does not give the specific config keys or class names for constraints beyond the general description, so check the docs before assuming an API shape.

Where SDV is the wrong tool

The clearest limitation is the licence. The README states the library is publicly available under the Business Source License, and the repository metadata reports the licence as NOASSERTION, which means automated licence detection could not classify it. A Business Source License is not a permissive open source licence in the usual sense; it typically carries usage restrictions that convert to a different licence after a stated change date. The supplied material does not include the licence text, the restriction, or the change date, so anyone who needs to know whether their use is permitted has to read the LICENSE file directly. That is a real constraint on adoption inside organisations with strict licence policies, and it is a bigger practical issue than any modelling detail. Beyond licensing, the scope boundary is tabular data. The README's framing is single tables, multiple connected tables and sequential tables. If your data is images, free text or arbitrary graph structures, the described feature set does not address it. There is also an operational cost that the README implies but does not quantify: deep learning synthesizers such as CTGAN are heavier to fit than GaussianCopula, so the choice of model is a compute decision as well as a quality decision. The demo uses GaussianCopula, which is the lighter option.

How SDV differs from a plain statistical sampler

The obvious alternative is to skip a library and sample each column independently from its own empirical distribution, or to fit a per-column model and draw from it. That approach is fast and has no metadata requirement. It also breaks the thing SDV's evaluation is built to measure. Independent sampling preserves column shapes and destroys column pair trends, because the joint structure is discarded the moment you sample columns separately. SDV's Column Pair Trends score exists precisely because that failure is common. A second alternative is to reach for a general-purpose generative model and treat the table as a matrix. That path asks you to handle column types, key uniqueness and cross-table links yourself, which is the work the metadata object is doing here. The honest comparison is not quality in the abstract; it is how much of the relational bookkeeping you want to own. SDV's answer is that you own the metadata and the constraints, and the library owns the fitting, sampling and scoring. If your table is a handful of independent numeric columns with no keys and no relationships, the metadata ceremony buys you little, and a simpler sampler will be easier to reason about.

Release cadence and what maintenance looks like

The release history shows a steady patch rhythm: v1.38.1, v1.38.2 and v1.38.3 landed on consecutive Fridays in August and September 2026, and the last push to the repository is dated 2026-09-10. That pattern suggests active maintenance rather than a frozen project, and it also means you should expect to move versions periodically. The README recommends using a virtual environment to avoid conflicts with other software, which is sound advice for any library that pulls in a deep learning stack. The conda install line names both the pytorch and conda-forge channels, so environment resolution is a place where upgrades can go wrong. For upgrade cost, the material does not describe a deprecation policy or a versioning guarantee, so the practical step is to pin a version, fit and sample a representative table, and re-run evaluate_quality after any bump to see whether the scores move. On licence, the README points to the LICENSE file in the repository, and the Business Source License is the only term named. Treat that as the thing to read before you build a pipeline on top of the library, not after.

Editorial conclusion

Adopt SDV if you already work in Python and your data is tabular, relational or sequential, and you want one metadata object to drive both generation and scoring. Do not adopt it if you need a permissive OSI-approved licence without reading the Business Source License text first, or if your data is unstructured text, images or graphs, which the README does not claim to cover. Before committing, verify three things against the current docs: the exact terms and change date of the Business Source License, whether the synthesizer you pick handles your column types, and what the quality report scores on your own table rather than on the demo hotel dataset.

Official sources

1. Issues
2. Project website
3. README
4. Releases
5. sdv-dev/SDV on GitHub