The engineering team at Alasco recently published a detailed write-up by Bahram Aghaei on how they give engineers anonymized, production-like data for every pull request. Their internal tool, Dumpster, is in their own words "a glue around several open-source projects", with Greenmask at its core, and it cut restore time from 4.5 hours to under one.

We think it is a great example of open-source test data management: a team assembling a complete, production-grade solution from composable building blocks, and owning every part of it.

The Problem Every Growing Team Hits

Sooner or later, every product team wants development environments that look like production. Migrations need to be tested against realistic schemas and realistic data volumes, and bugs are far easier to reproduce on data that behaves like the real thing.

But you cannot simply clone production. As the Alasco team puts it, "copying a live database leaks personally identifiable information (PII) and breaks regulations". The data has to be transformed before it ever reaches a developer's environment.

Buy First, Build Later

Alasco did not start by building. They started with off-the-shelf tools, and described their approach as "buy first, build later". Using existing products helped them learn which capabilities their engineers actually relied on, and saved them time while they did.

Once those requirements were clear, the build turned out to be small. Dump, anonymization and restore were already available as open source. What was left was the glue that connects them to Alasco's own infrastructure and workflows.

Dumpster: Glue Around Open Source

Dumpster is deliberately thin. Greenmask does the heavy lifting, and Dumpster integrates it with the rest of Alasco's stack:

Every Sunday at midnight, a cron job dumps the database from a read replica through Greenmask and writes a compressed, anonymized dump to S3. A cleanup job keeps only the two most recent successful dumps. When an engineer adds the deploy-dump label to a pull request, the PR environment restores the latest dump and reports the status to Slack.

Dumpster itself only adds what is specific to Alasco: the schedule, dump retention, a CLI for on-demand restores, the PR label and Slack notifications.

Why Greenmask Fits

Dumpster can stay this thin because Greenmask already covers the hard parts of the pipeline:

• PostgreSQL-native. Greenmask builds on pg_dump and pg_restore, so the schema is handled by PostgreSQL's own tools and Greenmask focuses on transforming the data.
• Storage built in. Dumps can be written to a local directory or S3-compatible storage, and restore reads them back from the same place.
• Deterministic when needed. The hash engine produces the same output for the same input, so transformed values stay consistent across tables and runs.
• Checks before you ship. validate shows transformed data next to the original, so rule changes can be reviewed before the next scheduled dump.

Rules as Code

One change Alasco highlights is where the anonymization rules live. Previously they were configured in a vendor UI. Now, excluded tables and per-column transformations are stored in a YAML file in the codebase, so they are reviewed in pull requests and versioned together with the schema they describe.

For example, Alasco uses the RandomPerson transformer to replace first and last names in their core_contact table with generated values. A simplified illustration of such a rule:

Illustrative transformation rule

- schema: public
  name: core_contact
  transformers:
    - name: "RandomPerson"
      params:
        columns:
          - name: "first_name"
            template: "{{ .FirstName }}"
          - name: "last_name"
            template: "{{ .LastName }}"

This means that when a migration adds a column with personal data, the rule that covers it can ship in the same pull request.

The Architectural Win: Decoupling Anonymization From Restore

According to Alasco, the most important design decision was separating the two stages:

1. Dump and anonymize on a schedule, once a week.
2. Restore on demand from the latest existing dump, without re-running anonymization.

Previously, every restore paid the full cost of anonymization. Now a PR environment only has to load a dump that is already prepared. As a result, restore time dropped from 4.5 hours to under one hour, and Alasco also reports substantially lower operational costs.

A Practical Detail Worth Knowing

The Alasco write-up includes a technical detail that applies to any PostgreSQL setup where one address fronts several replicas, managed or self-hosted.

To keep a dump consistent, Greenmask exports a snapshot from its main transaction, and every worker connection imports it via SET TRANSACTION SNAPSHOT. This happens on every dump, not only with --jobs greater than one, because the workers always use their own connections. An exported snapshot exists only on the server that created it, so, as Alasco notes, "every connection during a dump has to hit the same server".

Alasco pins Greenmask to the first read-only replica in their RDS cluster rather than letting the connection pool round-robin across replicas. The same applies to any setup that spreads new connections across several replicas, such as an Aurora reader endpoint, a Kubernetes read-only Service, or HAProxy in front of Patroni replicas: point Greenmask at a single replica's own endpoint.

Why This Works: Open Source as Building Blocks

A few takeaways stand out:

• Data stays in your infrastructure. The whole pipeline runs inside Alasco's own environment, from the read replica to S3 and the PR environments. For a compliance-driven use case, that matters.
• A solid core keeps the glue thin. Greenmask covers dump, transformation and restore end to end, so the integration layer stays small enough for one team to own.
• Open code is transparent. Behavior such as snapshot handling is documented and can be checked in the source, so teams know exactly how their data is handled.
• Configuration becomes part of engineering. Rules in YAML, reviewed in PRs and versioned with the code, fit naturally into how teams already work.

Thank You, Alasco

We are grateful to Bahram Aghaei and the Alasco team for sharing their experience so openly. Write-ups like this help other teams make better decisions, and they help us understand how Greenmask is used in the real world.

Read the full story on the Alasco tech blog: Anonymised production data with Dumpster.

Want to build something similar? Start with the Greenmask playground, set up S3 storage, and see how Greenmask and OpenEverest take test data management further.

Are you running Greenmask in production? We would love to hear your story and feature it here. Reach out via support@greenmask.io, Discord, or GitHub.