Microsoft SQL Server test data, inside your network

What works today

Dedicated SQL Server connector (pure-Python TDS driver): catalog discovery, primary and foreign keys, row estimates from sys.partitions, aggregate profiles and bounded streaming reads into the local engine, over verified TLS by default.

SQL authentication with the password as a secret reference. TLS is required by default and the server certificate is verified against the system CA bundle or a configured ca_file; a session that is not encrypted is refused.

Authentication: SQL authentication (secret reference).

Known limitations

• Requires agent 0.2.0 or later; agent 0.1.0 does not include its driver.
• SQL authentication only; Microsoft Entra ID (service principal) and Windows integrated authentication are not supported yet.
• Tested against the SQL Server 16.0 engine (Linux container); Azure SQL Database, Azure SQL Managed Instance and Amazon RDS for SQL Server are compatibility profiles still to be tested.
• Geography, geometry, hierarchyid, xml and sql_variant columns are carried as text.

Capability matrix

Each capability is tracked separately and shown at the level the recorded conformance evidence supports. A connector that only discovers metadata is never presented as equivalent to one that runs the whole workflow.

Read-only proof

Proven from the server before reading: fn_my_permissions must show no write or DDL permission on the server, the database or any visible table or view, and the login must not be sysadmin or a member of db_owner, db_datawriter or db_ddladmin.

Compatibility profiles

Managed variants of an engine are profiles of this connector, not separate connectors. A profile is marked tested only when its own conformance run passed.

• Azure SQL Database — not tested yet (roadmap only)
• Azure SQL Managed Instance — not tested yet (roadmap only)
• Amazon RDS for SQL Server — not tested yet (roadmap only)

Conformance evidence

DataNivra runs every connector through a common conformance kit on synthetic data: no write statements, proven read-only access, secret redaction, schema and relationship discovery, bounded streaming, cancellation, clear reason codes, egress canaries and no raw values in logs, then the discover, mask, subset, certify and provision workflow. The published status is computed from those results.

Connector version 0.1.0, last verified 2026-09-30.

What crosses the boundary

Connectors run inside the agent in your network. Only metadata, aggregates and evidence reach DataNivra Cloud:

• Schema, table and column names and data types (for file sets, operator-declared or opaque table names — never data-derived file names).
• Aggregates such as row-count estimates, null and distinct ratios; counts from 1 to 10 are reported as 10 (small-cell protection).
• Classification findings (which column looks like which kind of sensitive data) and relationship metadata.
• Evidence metadata: checksums, gate outcomes, engine and policy versions, and templated error codes.

Never sent:

• Any cell value, row, sample, minimum/maximum or top-k value — masked or not.
• Credentials, connection strings or resolved secret values: DataNivra stores only the secret reference.
• Free text copied from your data, or exception messages that contain values.

See the customer-resident architecture and how to verify these claims yourself.

Setup outline

1. Use agent 0.2.0 or later (earlier agent images do not include the SQL Server driver).
2. Create a SQL-authentication login and database user with SELECT on the schemas to read, and no write, DDL or owner role (not sysadmin, db_owner, db_datawriter or db_ddladmin).
3. Store the connection document with the password as a secret reference. TLS is on by default and the server certificate is verified against the system CA bundle or a ca_file you provide.
4. In the console, register the source with the secret reference of that document (for example vault://tdm/source-connection) and the agent that can reach it, then run discovery.
5. Before reading, the agent proves the login is read-only with fn_my_permissions and refuses to continue if it is not.

Example connection document, stored in your secret store and resolved by the agent locally (DataNivra only ever sees its reference):

{
  "kind": "SQL_SERVER",
  "host": "claims-sql.db.example.internal",
  "database": "claims",
  "user": "tdm_reader",
  "password_ref": "vault://tdm/claims-sql#password",
  "schemas": ["dbo"]
}

Next: install the agent, then follow the getting started guide.