Log inStart free

Use cases

Synthetic test data shaped like your own tables

Describe your own tables once - names, types, keys and relationships, never values - and request synthetic test data in that shape from CI, the CLI or the console.

Use case

DataNivra's industry packs describe the tables of common systems - banking cores, claims platforms, retail order systems - and generate realistic synthetic data for them. Many teams run software that no pack describes: an agricultural cooperative's field records, a logistics firm's depot system, an in-house product built years ago. Those teams still need test data that fits their tables, and they still should not copy production to get it. A custom schema lets you describe your own tables once and then request synthetic data in exactly that shape, through the same approved, bounded Test Data API that pack-based requests use.

What a custom schema holds

A custom schema is a private, versioned description of tables in your organization: schema and table names, column names and types, which columns may be empty, primary keys and the foreign keys between tables. It never holds values. There are three ways to create one:

  • paste the structure as JSON in the console under Automate → Custom Schemas;
  • run datanivra schemas import file.sql on a file of CREATE TABLE statements. The CLI parses the file on your machine and keeps names, types, NOT NULL, primary and foreign keys. Defaults, CHECK expressions, comments, enum literals and INSERT rows are dropped there and never sent. Without --yes it only shows you what it would send;
  • copy the latest discovery snapshot of a source you already connected (Save as custom schema on the source's page). The source is not read again.

Versions are immutable. Adding a version leaves earlier ones unchanged, and archiving a schema stops new profiles from naming it while approved profiles keep working.

From schema to test data

A synthetic-only test-data profile names one custom schema version instead of an industry pack, and each offered scenario names a root table. The console's Create draft profile button builds such a profile from a version: one scenario per root table, bounded counts and the target environment you choose. A second person reviews and approves the exact version, as with every profile; the approval pins the schema version and its fingerprint.

When a person, a CI pipeline or an AI agent requests that profile, the control plane sends the pinned structure to your agent with the signed job. The agent (version 0.5.0 or later) recomputes the fingerprint and refuses the job if it differs, opens no connector, and generates the root table, every table that references it through foreign keys, and a few reference rows for parents outside that set, in foreign-key order so every key resolves. The dataset is then provisioned into the approved target like any other.

This path was run end to end on DataNivra's hosted pilot on 2026-10-16: a four-table schema uploaded in the console, a profile version approved by a second user, a request from GitHub Actions authenticated by its workload identity and approved automatically inside the profile's envelope, a build by agent 0.5.0, the dataset ready, then released when the test run finished. All of it ran in a synthetic tenant with synthetic data.

Privacy boundary

Table and column names, types and relationships are control metadata: the same kind of information discovery already reports. A custom-schema build reads no source, so no production row is read, copied or sent anywhere. Names themselves can be sensitive (a column named after a customer, for example); the same identifier rules as discovery apply, and the import and paste paths let you review and rename before anything is sent.

What it does not do

  • Values are generic. Generated values follow each column's type and name and the relationships between tables, not an industry's vocabulary or your data's distributions. Where an industry pack fits, it gives more realistic values.
  • Synthetic only. A custom schema cannot drive masking or subsetting of a real source; those use connected sources and policies.
  • No constraint logic beyond keys. CHECK expressions, triggers, defaults and enum value lists are not reproduced, because they are dropped before upload.
  • Limits. Up to 5,000 tables per version, 2,000 columns per table and 500 foreign keys per table; an uploaded structure is at most 768 KiB.
  • Agents before 0.5.0 never receive these jobs. Requests are refused with AGENT_CUSTOM_SCHEMA_UNSUPPORTED until the target environment's agent is upgraded.