dbmask

Why it's ranked here

Masking only writes to disk behind an explicit apply flag, an incomplete scan refuses to proceed, and completeness gets checked row by row against an untouched copy afterward. It is MIT licensed, published to the Python package index, with a continuous-integration badge in its documentation. The honest caveat: its automated test suite currently exercises only one database engine, across many Python versions, on two operating systems. Postgres and MySQL run through the same code path but are not yet covered by that suite, only by early adopters. That gap is disclosed in the documentation rather than left for a user to discover.

What's good

The fail-closed defaults are the strongest part: masking never writes without an explicit flag, a column that cannot be classified is reported as unknown rather than assumed safe, and a sensitive primary key gets a loud warning instead of a silent skip. Generated values are typed correctly, not just string-shaped: dates stay real calendar dates, credit card numbers pass a Luhn check, an integer column never receives a string. Validation distinguishes a genuine pass from an unprovable one; a database without a usable key gets a warning, not a green checkmark, and strict mode turns that warning into a failure for a build pipeline.

Tradeoffs

The project is still labeled beta, and the test suite matches that: continuous integration currently runs against one database engine only. The other four share the same connection code, but that support rests on early adopters, not an automated suite yet. Determinism, the feature that keeps joins intact, is also the main weakness: anyone who knows the seed and can guess a value can recompute its mask, so the seed and the consistency store need the same protection as the data itself. Free text is flagged at the column level at best; a phone number buried inside a paragraph will not be caught.

How to use it well

This fits a pipeline that turns production data into a dev, staging, demo or analytics copy, wired in right before that copy is handed out, with verification run as a gate that fails the build rather than a step someone can skip. Set a private seed and pull the consistency-store salt from an environment variable instead of accepting the public defaults. Treat any column reported as unknown as a manual decision, not noise, and pick a blunt strategy such as blanking or redacting for free-text fields detection cannot see inside. Anyone targeting an engine other than SQLite should test thoroughly first rather than assume the same guarantees.

Observed

License

MIT (LICENSE file referenced from pyproject.toml)

Language / version support

Python, requires-python >=3.9, classifiers list support through 3.14

Packaging

Installable from PyPI; core runtime dependencies are limited to SQLAlchemy, PyYAML and click, with database drivers and LLM SDKs shipped as separate optional extras

Interfaces

CLI (console-script entry point) and a Python library API

Platform / database support

OS Independent per package classifiers; connects to PostgreSQL, MySQL/MariaDB, SQL Server, Oracle and SQLite through a single SQLAlchemy-based connector

Test coverage scope

A test directory is present and referenced from the architecture docs, but the docs state the automated suite exercises SQLite only; PostgreSQL and MySQL integration tests are documented as not yet part of that suite

Security process

docs/security-model.md states what dbmask defends against (casual exposure, breach amplification, fail-closed failures) versus what it does not (deterministic-seed guessing, linkage re-identification, free-text leakage, primary-key sensitivity)