anon

Overview

Version

Build

You can build the RPM / DEB packages for pg_anon using pig build:

pig build pkg pg_anon         # build RPM / DEB packages

Install

You can install pg_anon directly. First, make sure the PGDG and PIGSTY repositories are added and enabled:

pig repo add pgsql -u          # Add repo and update cache

Install the extension using pig or apt/yum/dnf:

pig install pg_anon;          # Install for current active PG version

pig ext install -y pg_anon -v 18  # PG 18
pig ext install -y pg_anon -v 17  # PG 17
pig ext install -y pg_anon -v 16  # PG 16
pig ext install -y pg_anon -v 15  # PG 15
pig ext install -y pg_anon -v 14  # PG 14

dnf install -y pg_anon_18       # PG 18
dnf install -y pg_anon_17       # PG 17
dnf install -y pg_anon_16       # PG 16
dnf install -y pg_anon_15       # PG 15
dnf install -y pg_anon_14       # PG 14

apt install -y postgresql-18-pg-anon   # PG 18
apt install -y postgresql-17-pg-anon   # PG 17
apt install -y postgresql-16-pg-anon   # PG 16
apt install -y postgresql-15-pg-anon   # PG 15
apt install -y postgresql-14-pg-anon   # PG 14

Preload:

shared_preload_libraries = 'anon';

Create Extension:

CREATE EXTENSION anon;

Usage

Sources:

• PostgreSQL Anonymizer 3.1.3 README
• Masking functions
• 3.1.3 changelog
• Official documentation

anon is PostgreSQL Anonymizer. It applies declarative masking rules for protected query access, produces anonymized data sets, and provides pseudonymization and randomized-response helpers. Use it when realistic data must remain useful without exposing the original sensitive values; treat masking policy, role grants, and access to the unmasked database as part of the security boundary.

Core Workflow

Load anon for sessions in the target database, install the extension, and enable transparent dynamic masking. New connections pick up database-level settings.

ALTER DATABASE app SET session_preload_libraries = 'anon';

\connect app
CREATE EXTENSION anon;
ALTER DATABASE app SET anon.transparent_dynamic_masking = true;

Mark a login as masked and attach masking rules to sensitive columns:

CREATE ROLE reporting LOGIN;
SECURITY LABEL FOR anon ON ROLE reporting IS 'MASKED';
GRANT pg_read_all_data TO reporting;

SECURITY LABEL FOR anon ON COLUMN customer.last_name
  IS 'MASKED WITH FUNCTION anon.dummy_last_name()';
SECURITY LABEL FOR anon ON COLUMN customer.phone
  IS 'MASKED WITH FUNCTION anon.partial(phone, 2, $$******$$, 2)';

Queries made as reporting see the transformed values. Privileged users still see the originals, so do not grant masked roles a path around the policy.

Masking Strategies

• Dynamic masking transforms results for roles labeled MASKED without rewriting the table.
• Static masking permanently rewrites selected data and is appropriate for disposable development or test copies.
• Anonymous dumps and replicas produce sanitized exports or downstream copies.
• Masking views and data wrappers expose a deliberately reduced or transformed projection.
• Pseudonymization uses deterministic transforms when joins or repeated values must remain consistent.

Important Objects

• anon.dummy_*, anon.random_*, and anon.partial(...) generate or partially conceal values.
• anon.hash(text) and anon.digest(text, text, text) provide deterministic transformations. In 3.1.2 they were marked RESTRICTED to limit brute-force exposure.
• anon.ldp_grrm(value, epsilon, max_v) and anon.ldp_grrm_pttt(value, truth_probability, max_v) implement generalized randomized response for local differential privacy.
• anon.ldp_truth_probability(...) and anon.ldp_lie_probability(...) help inspect randomized-response probabilities.
• Security labels on roles and columns define who is masked and how each value is transformed.

Operational Notes

anon is superuser-installed and non-relocatable. Test every policy with the same grants and connection path used by the intended consumer. Randomization is not automatically deterministic; use a confirmed pseudonymization function when stable equality is required. Static anonymization is destructive, so run it on a copy and verify constraints and application behavior afterward.

Version 3.1.3 reruns missing ARM builds and changes release metadata, with no new SQL workflow. The material delta since 3.1.1 is the 3.1.2 security hardening for anon.hash and anon.digest; deployments using those functions should upgrade rather than relying on the old labels.