Open Source Data Anonymization Tools Compared

Search for open source data anonymization tools and you get lists that put ARX, Presidio and a Postgres extension in the same table, as though they were substitutes. They are not. They do three different jobs, and a team that picks the wrong category ships a pipeline that looks anonymized and is not.

This is a map of the open-source landscape organised by the job each tool does, what privacy model it can actually enforce, and where the boundary of the tool ends and your own governance has to start. The commercial side of the same market is covered separately in the comparison of anonymization tools across open source and enterprise tiers.

Three jobs, not one category

Almost every disappointment with an open-source anonymization tool traces back to a category error. The three jobs are:

Find the identifiers. Given unstructured text, images or a schema nobody has documented, work out which fields and spans carry personal data at all. This is a detection problem, and it is probabilistic.

Enforce a formal privacy model. Given structured tabular data and a declared set of quasi-identifiers, transform it until it satisfies k-anonymity, l-diversity, t-closeness or a differential privacy budget, and report how much utility that cost. This is an optimisation problem with a measurable output.

Produce a safe copy of a production database. Given a live schema with foreign keys, sequences and triggers, emit a dump or a replica that developers can work against without holding real customer records. This is an engineering problem about referential integrity and pipeline ergonomics.

A tool that is excellent at one is usually indifferent at the other two. NIST SP 800-188 makes the same point in governance language: de-identification is a process with a risk assessment attached, not a transformation you apply once.

The landscape at a glance

Tool	Job	Data it handles	Privacy model it can enforce	Interface
ARX	Formal model	Tabular (CSV, Excel, JDBC)	k-anonymity, l-diversity, t-closeness, δ-presence, differential privacy	Java GUI and library
Amnesia	Formal model	Relational and set-valued tabular	k-anonymity, km-anonymity	Web GUI
sdcMicro	Formal model	Tabular microdata	Statistical disclosure control, k-anonymity, risk scoring	R package
Microsoft Presidio	Detection	Text, images, semi-structured	None on its own — it finds and replaces	Python library, container
PostgreSQL Anonymizer	Safe copy	PostgreSQL	None formal — masking rules in DDL	Postgres extension
Greenmask	Safe copy	PostgreSQL, MySQL in beta	None formal — deterministic transformers	Go binary, pg_dump-compatible
OpenDP SmartNoise	Formal model	Tabular queries and synthesis	Differential privacy	Python SDK

The “privacy model it can enforce” column is the one that decides whether a GDPR anonymity argument is available to you, and it is the column most tool round-ups leave out.

Tools that enforce a formal model

ARX remains the most complete open-source implementation of statistical privacy models. It supports k-anonymity and its descendants alongside differential privacy in a single application, and it ships both a cross-platform GUI for analysts and a Java library for pipeline use. What separates it from a masking script is the feedback loop: ARX quantifies re-identification risk before and after transformation and reports utility loss, so a disclosure decision can be evidenced rather than asserted. Its limit is scope. It is built for structured tabular data and does nothing for free text, images or nested JSON.

Amnesia, developed by the ATHENA Research Center under OpenAIRE, covers similar ground through a browser interface and adds k^m-anonymity for set-valued data — the shape you get from transaction baskets, diagnosis code lists or tag sets, where each record holds a variable-length collection rather than a fixed row. That is a genuinely awkward case for row-oriented tools, and it is the reason to reach for Amnesia rather than ARX on some datasets.

sdcMicro comes from the official-statistics world and lives as an R package. It is the right tool if your output is a microdata release and your reviewers speak the language of disclosure risk, global risk measures and information loss metrics. It is the wrong tool if nobody on the team writes R, because everything is scripted and the learning curve is real.

OpenDP SmartNoise targets the differential privacy case specifically: DP queries over a dataset, and DP synthesis. Choose it when the deliverable is an aggregate statistic or a published synthetic table with a stated privacy budget, not when the deliverable is a de-identified copy of the records themselves.

The detection layer

Microsoft Presidio is the default open-source answer for finding personal data in content that has no schema. Detection combines named-entity recognition, regular expressions, deny lists and checksum validation; a separate anonymizer component applies redaction, masking, hashing, replacement or encryption to the spans that were found. Presidio Image Redactor extends the same idea to OCR output, and Presidio Structured brings it to tabular and semi-structured sources.

The critical property to internalise is that Presidio’s detection is probabilistic and its own documentation says so. Recall varies by entity type, language and domain, and default models routinely miss the identifiers specific to your business: internal employee numbers, case references, product serials. Custom recognisers close part of that gap. Nothing closes all of it, which is why Presidio belongs at the front of a pipeline that has another control behind it, not at the end of one.

Presidio is also the tool most often misapplied to a job it was never built for. Replacing every detected name with a random name does not produce anonymous data. It produces pseudonymized data with an unusually convincing disguise, and the distinction has legal consequences that are set out in pseudonymization versus anonymization under GDPR.

Tools that produce a safe database copy

This is the category that the query “database anonymization tools” is usually reaching for, and it is served almost entirely by the PostgreSQL ecosystem.

PostgreSQL Anonymizer is an extension that takes a declarative approach: masking rules are attached to columns as security labels in the schema itself, so the rule travels with the table definition instead of living in a separate script that drifts. It offers static masking, dynamic masking for restricted roles, anonymous dumps, masking views, replica masking and masking data wrappers for external sources, with documented function families covering destruction, randomization, faking, deterministic pseudonymization, generic hashing, partial scrambling, shuffling, noise addition, generalization, local differential privacy and custom SQL. The distinction between the faking functions and the pseudonymization ones matters more than the docs make it look: faking is random per call, pseudonymization is deterministic, and deterministic output is a linkage that keeps the result on the pseudonymised side of the line. Generalization functions give you the raw material for a k-anonymous view; the assessment of whether the result is defensible is still yours to make and document.

Greenmask takes the opposite ergonomic bet. It is a single Go binary that acts as a drop-in replacement for pg_dump, applying transformations during the dump rather than requiring anything to change in the database. It supports deterministic transformers, so the same input value maps to the same output every time and joins survive; database subsetting to keep dumps small; and transformation diffs so a configuration can be inspected before it is trusted. Subsetting handles cyclic and polymorphic foreign-key references, which is the case that breaks naive WHERE-clause sampling. The project now also ships a mysqldump mode, but its own README marks MySQL support beta and work-in-progress, so PostgreSQL is the only tier to plan production dumps around today.

The choice between them is mostly organisational. Greenmask if you want zero schema changes and a dump-time pipeline. PostgreSQL Anonymizer if you want the masking policy to be part of the schema and reviewable in the same migration that adds the column.

The trap: fake data is not anonymized data

Faker, Mimesis and their equivalents generate plausible values. They do not analyse your dataset, they hold no model of re-identification risk, and they will happily leave every quasi-identifier in place while replacing only the fields you remembered to list. A dataset where names are fake but the combination of postcode, birth date and job title is untouched is still capable of singling out individuals, which is the test that matters under GDPR Recital 26.

Value generators are a useful component inside a masking configuration. They are not a de-identification strategy, and any tool comparison that lists them alongside ARX is measuring the wrong thing.

What no open-source tool gives you

Three gaps survive every tool on this list.

Risk assessment is not automatic. ARX and sdcMicro can compute a risk score if you tell them which attributes are quasi-identifiers. Deciding that a job title is a quasi-identifier in your population, and that an auxiliary dataset an attacker could plausibly obtain would make it one, is a human judgement. NIST SP 800-188 pushes organisations towards a Disclosure Review Board for exactly this reason.

Provenance is not automatic. Regulators asking whether a training set was lawfully assembled want lineage: what was collected, under what basis, what was transformed, and when. None of these tools produce that record. The obligations that create the demand for it are covered in training-data privacy and data-subject rights against AI models.

Model-level leakage is untouched. Anonymizing the training file does not anonymize the model. Outliers are memorised, and membership inference attacks recover the fact of a record’s participation from query behaviour alone. If the deliverable is a model rather than a table, the controls that matter are further down the pipeline, as set out in how to anonymize training data.

Choosing in four questions

1. What shape is the data? Free text or images means Presidio. Fixed tabular means ARX, Amnesia or sdcMicro. A live relational schema means Greenmask or PostgreSQL Anonymizer.
2. What is the output for? Internal development copies tolerate masking. External release or research sharing needs a formal model and a documented risk assessment.
3. Do you need a defensible anonymity claim? If yes, the tool must be able to enforce and report a privacy model. Masking tools cannot get you there no matter how thorough the rules are.
4. Who maintains the configuration? A schema-embedded policy survives staff turnover better than a script in a repository nobody owns.

Most mature programmes run two tools, not one: a detection layer for anything unstructured, and a formal-model or masking layer sized to the destination. If you are unsure which obligations attach to your own deployment before you pick anything, the interactive applicability wizard maps a deployment to the GDPR, EU AI Act and US state duties that reach it.

Related across the network

• Best AI Privacy and Data Security Tools for LLM Pipelines — bestaisecuritytools.com
• Training Data Extraction from LLMs: The Carlini Results Explained — adversarialml.dev
• Membership Inference vs. Model Inversion: Privacy Attacks — adversarialml.dev