---
title: The anon extension
subtitle: Protecting sensitive data in Postgres databases
enableTableOfContents: true
updatedOn: '2025-11-07T02:45:10.110Z'
---

The `anon` extension ([PostgreSQL Anonymizer](https://postgresql-anonymizer.readthedocs.io)) provides data masking and anonymization capabilities to protect sensitive data in Postgres databases. It helps protect personally identifiable information (PII) and other sensitive data, facilitating compliance with regulations such as [GDPR](https://gdpr-info.eu/).

This reference guide introduces the `anon` extension's capabilities and masking functions.

<Admonition type="tip" title="Looking for a practical guide?">
For complete step-by-step workflows on anonymizing data in Neon branches, including manual procedures and GitHub Actions automation, see [data anonymization](/docs/workflows/data-anonymization).
</Admonition>

## Enable the extension

<Admonition type="note">
The `anon` extension is currently [experimental](/docs/extensions/pg-extensions#experimental-extensions) and may change in future releases.
</Admonition>

When using the Neon Console or API for anonymization workflows, the extension is enabled automatically. It can also be enabled manually using SQL commands.

### Enable via SQL

When working with SQL-based workflows (such as using `psql` or other SQL clients), enable the `anon` extension in your Neon database by following these steps:

1. Connect to your Neon database using either the [Neon SQL Editor](/docs/get-started/query-with-neon-sql-editor) or an SQL client like [psql](/docs/connect/query-with-psql-editor)

2. Enable experimental extensions:

   ```sql
   SET neon.allow_unstable_extensions='true';
   ```

3. Install the extension:

   ```sql
   CREATE EXTENSION IF NOT EXISTS anon;
   ```

<Admonition type="tip">
When using the Neon Console or API to create branches, the extension is enabled automatically. See the [data anonymization workflow guide](/docs/workflows/data-anonymization) for details.
</Admonition>

## Masking rules

Masking rules define which data to mask and how to mask it using SQL syntax. These rules are applied using `SECURITY LABEL` SQL commands and stored within the database schema to implement the privacy by design principle.

## Masking functions

The `anon` extension provides [built-in functions](https://postgresql-anonymizer.readthedocs.io/en/latest/masking_functions/) for different anonymization requirements, including but not limited to:

| Function Type      | Description                                           | Example                                                                                         |
| ------------------ | ----------------------------------------------------- | ----------------------------------------------------------------------------------------------- |
| Faking             | Generate realistic data                               | `anon.fake_first_name()` and `anon.lorem_ipsum()`                                               |
| Pseudonymization   | Create consistent and reversible fake data            | `anon.pseudo_email(seed)`                                                                       |
| Randomization      | Generate random values                                | `anon.random_int_between(10, 100)` and `anon.random_in_enum(enum_column)`                       |
| Partial scrambling | Hide portions of strings                              | `anon.partial(ip_address, 8, ''XXX.XXX'', 0)` would change `192.168.1.100` to `192.168.XXX.XXX` |
| Nullification      | Replace with static values or `NULL`                  | `MASKED WITH VALUE 'CONFIDENTIAL'`                                                              |
| Noise addition     | Alter numerical values while maintaining distribution | `anon.noise(salary, 0.1)` adds `+/- 10%` noise to the `salary` column                           |
| Generalization     | Replace specific values with broader categories       | `anon.generalize_int4range(age, 10)` would change `54` to `[50,60)`                             |

## Static masking

Static masking permanently modifies the original data in your tables. This approach is useful for creating anonymized copies of data when:

- Migrating production data to development branches
- Creating sanitized datasets for testing
- Archiving data with sensitive information removed
- Distributing data to third parties

### Branch operations and static masking

When using Neon's branch features with static masking:

- Creating a child branch copies all data as-is from the parent
- Resetting a branch from the parent replaces all branch data with the parent's current state
- In both cases, any previous anonymization is lost and must be reapplied

## Practical examples

For complete implementation examples showing how to apply these masking functions in real workflows, see the [data anonymization guide](/docs/workflows/data-anonymization), which covers:

- Creating and anonymizing development branches
- Applying different masking strategies to protect sensitive data
- Automating anonymization with GitHub Actions
- Best practices and safety tips

## Limitations

- Neon currently only supports static masking with the `anon` extension
- With static masking, branch reset operations restore original data, requiring anonymization to be run again
- Additional `pg_catalog` functions cannot be declared as `TRUSTED` in Neon's implementation

## Conclusion

The `anon` extension provides a toolkit for protecting sensitive data in Postgres databases.
By defining appropriate masking rules, you can create anonymized datasets that maintain usability while protecting individual privacy.

## Reference

- [Data anonymization workflow guide](/docs/workflows/data-anonymization) - Practical guide for anonymizing data in Neon branches
- [PostgreSQL Anonymizer Repository](https://gitlab.com/dalibo/postgresql_anonymizer)
- [Official Documentation](https://postgresql-anonymizer.readthedocs.io/en/latest/)
- [Masking Functions Reference](https://postgresql-anonymizer.readthedocs.io/en/latest/masking_functions/)

<NeedHelp/>