WORKFLOW GUIDE / POSTGRESQL & MYSQL

Production-like data.
Personal details replaced.

Select a useful subset, include the related records you need, and review masking before copying to a lower environment.

01 / A SMALLER, MORE USEFUL DATASET

Start with the test case.
Choose the rows that explain it.

Copy selected records instead of restoring a whole production dump. Use a WHERE condition, primary-key selection or a row limit. Review the scope and target permissions before copying.

ILLUSTRATIVE FILTER · customerscountry = 'GB'

A filter defines the subset. A row limit alone does not guarantee a representative sample.

02 / KEEP THE RELATIONSHIPS IN VIEW

A row rarely stands alone.

An order needs its customer. A useful order test may also need its line items. Choose the related parent and child rows to include, then inspect dependency order and constraints.

Related-row inclusion is a choice. Review cycles, existing target rows and required references for your dataset.

03 / REPLACE SELECTED DETAILS

Keep useful structure.
Review what gets replaced.

Assign masking rules column by column. Consistent rules and deterministic seeds can map repeated values to consistent replacements across related records.

Source · synthetic exampleOriginal test values
customer_id
10492
name
Alex Morgan
phone
000-000-0107
Target · after maskingSelected columns replaced
customer_id
10492
name
Alex Morgan
phone
000-000-0192

Synthetic example. Only selected columns change; identifiers and unselected values remain.

LIVE IN-MEMORY MASKING PLAYGROUND

Test Reusable Masking Rules

Experience how dbhydrate masks columns in local workstation memory before sending data over the network. Deterministic replacements maintain parent/child foreign key integrity across tables.

Local RAM Only · 0 Cloud Relays

The same seed ensures identical masked outputs across related tables (e.g. users.id and orders.user_id).

Live Transformation Preview
SOURCE (PROD)customer_email : varchar(255)
TARGET (DEV/SANDBOX)Safe for Lower Envs

Architectural Guarantee

Row values are never written to disk unencrypted, and never sent to third-party AI APIs. Masking takes place directly in volatile workstation memory through local streaming buffers before batch INSERT into your target database.

04 / REVIEW BEFORE YOU COPY

The final values deserve
a final look.

Review connections, tables, masking and target settings together. Inspect warnings, confirm the copy and validate that the resulting dataset supports the intended test.

PostgreSQL example: review sensitive columns and masking rules before copying data
dbHydrate workspace · select to enlargeDesign preview · PostgreSQL example data

Masking is one part of a privacy review. Check indirect identifiers, access and retention requirements for the resulting dataset.

THE LAST MILE / ENVIRONMENT SETTINGS

Set the values your
test environment needs.

Column overrides run after masking. Inspect their final values and constraints. For example, set notifications to off, choose sandbox payment settings, or use a local authentication callback.

notifications_enabled = FALSEpayment_gateway_mode = 'sandbox'auth_domain = 'localhost:3000'

Keep the review practical.

Connections, row transformation and masking run locally on your computer. Local history preserves SQL and run results; it is not a tamper-proof compliance ledger. Masking rules do not certify compliance or guarantee anonymization.

Read security & privacy details

WORKFLOW QUESTIONS

Masking & subsetting.

Why is deterministic masking critical when copying relational databases?

In relational databases, customer identifiers (such as user IDs or emails) often appear across multiple tables joined by foreign keys or logical relations. If masking generated random replacements on every occurrence, foreign key constraints would break and cross-table queries would return inconsistent data. Deterministic masking uses a fixed cryptographic seed or salt so that the exact same input value always produces the exact same masked replacement across all copied tables.

Does sensitive data ever get sent to an external cloud or AI service during masking?

Never. dbhydrate performs all schema inspection, row filtering, and data transformation in-memory on your local machine using direct TCP or SSH sockets to your database servers. No row values, credentials, or schema definitions are ever sent to an external SaaS proxy or cloud AI service.

How does dbhydrate handle parent and child rows in referential data copying?

When you select rows from a table using a WHERE filter or primary-key selector, dbhydrate analyzes the foreign key graph. You can choose to include parent rows (ensuring foreign key references exist on the target) and child rows (such as copying an order and all its line items). Rows are copied in topological order: parents are inserted before children, and deleted in reverse order if replacing existing records.

What masking algorithms are supported?

dbhydrate supports Faker generators (realistic names, addresses, emails, phone numbers), salted cryptographic hashes (for pseudorandom unique identifiers), regex pattern replacements (e.g. masking social security or credit card numbers while preserving prefixes or suffixes), fixed string/numeric constants, and SQL NULL.

Select. Relate.
Mask. Review.

Choose your product