Database DevOps · Test data

Test data management: realistic, masked test databases on demand

Test data management is how development and test teams get databases that behave like production without carrying production's personal data or its size. Interkey implements Redgate Test Data Manager for SQL Server, PostgreSQL, Oracle and MySQL teams in Saudi Arabia: it finds the sensitive columns, masks them, cuts the copy down to a representative subset and provisions fresh environments from a pipeline, so a refresh becomes a routine step.

Orientation

At a glance

The engagement in one table, before the detail.

What it solves
Slow manual refreshes, full production copies holding real personal data, and test servers out of disk
The tool
Redgate Test Data Manager: classify, mask, subset, provision and automate
Databases
SQL Server, PostgreSQL, Oracle and MySQL, per Redgate's documentation; your exact versions and editions are confirmed in scoping
Where it runs
On servers you choose, Windows or Linux, so production data can be masked inside your own network
How it is priced
Interkey's work per engagement, after an assessment; Redgate licensing at Redgate's terms
Who supports it
Interkey's database engineers in Riyadh, during set-up and after it

In short, for decision makers

  • The problem: most teams test against a copy of production, or against a copy made months ago. The first exposes personal data; the second hides bugs.
  • The answer: a repeatable process that produces masked, smaller, consistent copies on a schedule or on request.
  • What changes: fewer places holding real customer data, environments refreshed when needed, and a record of what was masked.

What test data management has to cover

Test data management is more than masking. A working setup covers six things for every non-production database.

  • Catalogue. Which tables and columns hold personal or sensitive data, including national ID and Iqama numbers, mobile numbers, IBANs and free-text notes.
  • Masking. Replacing those values with realistic substitutes, the same way everywhere, so joins and application checks still work. Our guide to data masking for test environments compares the methods.
  • Subsetting. Taking a smaller, related slice of production instead of every row, so copies are quicker to build and hold less data.
  • Synthetic test data. Generated values for new features, empty tables and edge cases that production does not contain yet.
  • Provisioning and cloning. Giving each developer, tester or pipeline its own environment, and resetting it after a destructive test.
  • Refresh and record. A schedule, an owner, and a log that shows which copy was made from what, with which rules.

Test data management tools: what Redgate Test Data Manager does

Interkey implements Redgate's tooling for database delivery. According to Redgate's own documentation, Test Data Manager covers the job as follows:

Redgate Test Data Manager capabilities and the decisions that stay with your team
CapabilityWhat the tool doesWhat your team still decides
ClassifyAutomatically finds and categorises data to identify personally identifiable informationWhich proposed columns are truly sensitive, and what sits in free-text fields
MaskDeterministic masking that replaces values with realistic substitutes and keeps referential integrityThe rule per column and the formats your applications validate
SubsetBuilds a smaller, representative slice from a chosen starting table with filter clauses, following foreign key relationshipsHow much data each environment really needs
ProvisionCreates a clone of an entire database instance through Redgate Clone, with masking during provisioning as an optionWho gets which environment, and how often it is reset
AutomateA command line designed for CI/CD pipelines, alongside a graphical interface; runs on Windows and LinuxWhere in the pipeline the refresh runs, and who approves it

Redgate documents the tool for SQL Server, PostgreSQL, MySQL (and MariaDB) and Oracle. Features vary by engine, version and edition, so we confirm yours against Redgate's current documentation during scoping. Redgate describes its clones as having a small storage footprint; how much disk you save depends on your data and is measured in the pilot.

Database subsetting and synthetic test data

A full copy of a large production database is rarely what a test needs. It is slow to restore, fills test servers and exposes every customer record. Database subsetting starts from a chosen table, such as one branch or one month of orders, and follows the relationships so every order keeps its customer, items and payments. Because Test Data Manager follows foreign keys, a schema whose relationships live only in application code needs those relationships written down first, often the first finding of an assessment.

Read more

The subset decides how much data a copy holds; masking decides what the values look like. An unmasked subset still contains real people.

Synthetic test data fills the gaps a copy cannot: a new table before go-live, rare cases testers need on purpose, such as an expired Iqama or a very long Arabic name, and demo environments with no real records. We agree with your testers which cases are generated.

Test data provisioning and database cloning

Test data provisioning turns the wait for an environment into a request: a developer, tester or pipeline asks for a database and gets a masked copy built from an approved image. With Redgate Clone, Test Data Manager can provision a clone of an entire database instance, so each person or pipeline run has its own copy and can reset it after a destructive test.

Read more

Masking happens before anyone outside the production team can connect: the image is masked once, checked, and every clone is made from it. No unmasked "temporary" copy is left on a test server.

Provisioning belongs in the same pipeline as schema changes. Where teams already deploy database changes with Flyway, the refresh step runs next to the migration step, so a test database gets the right schema version and safe data together. Otherwise, start with database version control.

Where teams use it

The same masked, subsetted source serves several kinds of environment, each with its own refresh rhythm.

  • Developer databases. A small, masked copy per developer, reset as often as needed.
  • CI pipelines. A fresh database for each build or test run, created and removed by the pipeline.
  • User acceptance testing. A larger, stable copy, refreshed between test cycles.
  • Vendors and contractors. A masked copy instead of access to production.
  • Training and demos. Synthetic or fully masked data that is safe to show on screen.
  • Performance testing. Here a subset is often too small; a full-size masked copy is the usual answer, and we say so in scoping.

Test data management in Saudi Arabia: data protection and local support

In Saudi Arabia, personal data falls under the Personal Data Protection Law, overseen by the Saudi Data and Artificial Intelligence Authority (SDAIA). A production copy in a test environment is still personal data; which obligations apply is for your data-protection function, and the technology reduces the places where real personal data exists. Our page on PDPL and test data sets out the practical controls in more detail.

Read more

Data residency matters here too. Test Data Manager runs on servers you choose, so the masking can happen inside your own network in the Kingdom, before any copy reaches a cloud environment, an offshore team or a vendor. Interkey's database engineers work from Riyadh, on the Saudi working week, in Arabic and English. Saudi formats, such as national ID and Iqama numbers, mobile numbers, IBANs and Arabic names, are in the masking rules from the first workshop.

How Interkey sets up test data management

  1. Assess.

    How copies are made today, by whom and how often; engines, versions and sizes; who can reach each environment.

  2. Catalogue with your data owners.

    Run classification, then review the proposed list column by column, including free text, with the people who own the data.

  3. Write the rules.

    A masking rule per sensitive column and a subset definition per environment, tested against the formats your applications check.

  4. Pilot on one database.

    Build a masked subset, let a team test on it, and measure refresh time and disk use.

  5. Automate.

    Put the refresh into your pipeline through the command line, with a schedule, an approval where you want one, and a log.

  6. Extend and hand over.

    Add the next databases, document the rules and train your DBAs, or keep Interkey's support from Riyadh.

What drives the cost and the timeline

Interkey quotes per engagement after the assessment, and Redgate licensing is quoted at Redgate's terms alongside that work. The drivers are the number of databases and engines, their size, the sensitive columns and free-text fields, whether relationships are declared in the schema, the number of environments, and how far the pipeline is automated. As a rough estimate, a pilot on one well-structured database is measured in weeks, and an estate of several engines with undeclared relationships in months. The assessment replaces both estimates with a plan.

Questions buyers ask

What is the difference between test data management and data masking?

Masking is one part of it. Test data management is the whole job of producing test databases: finding sensitive data, masking it, cutting the copy down, provisioning environments and refreshing them on a schedule.

Which databases does Redgate Test Data Manager support?

Redgate documents it for SQL Server, PostgreSQL, MySQL (including MariaDB) and Oracle. Features differ by engine, version and edition, so we check your exact setup against Redgate's documentation before you commit to licences.

Can test data be prepared without production data leaving Saudi Arabia?

Yes. The tool runs on servers you choose, so classification, masking and subsetting can happen inside your own network in the Kingdom. Only the masked copy moves on, to places your data classification allows.

How is Redgate Test Data Manager licensed in Saudi Arabia, and what does a project cost?

Redgate licensing is quoted at Redgate's terms, and Interkey's implementation is quoted per engagement after the assessment. The number of databases, sensitive columns and environments drives the work. There is no published price list.

How long does it take to have masked test databases ready?

A pilot on one database with declared relationships is usually a matter of weeks, as an estimate. Several engines or undeclared relationships take longer. The assessment gives you a dated plan.

Is a subset enough for performance and load testing?

Usually not. Performance tests need production-like volumes, so a full-size masked copy is the normal answer there. Subsets suit development, CI and most functional testing.

Next step

Plan your test data setup

Tell us which database engines you run, the rough size of production, how many test environments you keep and how they are refreshed today.

Required field

By sending this form, you agree to our Privacy Notice.

Or directly

+966-11-2180999 [email protected]

Tawuniya Towers, North Tower, 7th Floor, King Fahad Highway, Olaya, P.O. Box 56835, Riyadh 11564, Saudi Arabia

or See what the tool covers

Published by Interkey. Last updated . Interkey is registered in Riyadh, Saudi Arabia under commercial registration 1010156897.