TL;DR
Data masking tools replace sensitive values, such as names, card numbers, and health records, with realistic substitutes that keep data usable for testing, analytics, and support without exposing the real thing. The right tool depends on whether you need to protect live production queries, mask copies before they leave production, or both, and how many databases and cloud platforms it has to cover.
Key Takeaways Data masking tools substitute sensitive values with realistic, structurally valid data, while data anonymization permanently strips identifying information instead. Static masking transforms copied datasets before they reach test or development environments, while dynamic masking hides values at query time without changing the stored data. Twelve tools cover most enterprise scenarios, from broad platform coverage with Delphix and Informatica to developer-focused test data with IRI FieldShield and Tonic.ai. Native masking inside Azure, AWS, GCP, Snowflake, and Databricks can handle a single-platform environment, but dedicated platforms earn their cost once masking spans many systems. GDPR, HIPAA, and PCI DSS each treat masked data differently, so the right technique depends on which regulation governs the data, not one default setting. Kanerika has implemented Microsoft Purview-based data governance and security programs for enterprise clients, including a 72% governance improvement for a bank handling PII, PCI, and PHI data. A $4.44 Million Reason Enterprises Cannot Treat Test Data as an Afterthought The average data breach now costs $4.44 million worldwide, according to IBM’s 2025 Cost of a Data Breach Report , and $10.22 million in the United States . A large share of exposed records never touch a production system during the incident itself. Instead, they sit in a test database, a QA environment, or an analytics sandbox where a copy of real customer data was never supposed to live unprotected.
Data masking tools exist because copying production data is unavoidable. Developers need realistic data to build against, analysts need real patterns to test models, and support teams need to see enough of a record to help a customer. Masking lets all three happen without exposing the underlying names, account numbers, or health records.
Watch on YouTube
Susan: Kanerika’s AI Agent for PII Redaction
See how Susan automatically finds and redacts sensitive information across documents and workflows, one of the AI agents Kanerika builds alongside database and pipeline-level masking.
What Is Data Masking? Data masking is the process of replacing sensitive values in a dataset with realistic, structurally similar substitutes, so the data stays usable without exposing the real information underneath. A masked customer record still looks like a customer record. The name, phone number, and account balance are fabricated, but the format, data type, and relationships between fields stay intact.
Masking sits inside a broader data security and governance program, alongside access controls, encryption, data classification, and audit logging. None of those controls replace the others. Classification identifies what is sensitive, and access controls decide who can see it in its original form. Masking removes the sensitive value entirely from environments where nobody needs to see it at all.
Programs that treat masking as an isolated tool purchase tend to protect the production database well. The same programs often leave test, development, and analytics copies wide open, because masking was never framed as one control inside a wider data governance program .
The requirements also differ by where the data lives. A production database benefits from dynamic masking that limits what a query returns based on who is asking. A copy heading to a development environment needs the sensitive values replaced before it ever leaves production. Nobody can revoke access to a file that already left the building.
Data Masking vs Anonymization, Tokenization, and Encryption Data masking and data anonymization solve related problems with different guarantees. Masking substitutes, shuffles, or transforms sensitive values while keeping the dataset structurally realistic. Depending on the technique, the original value can sometimes be recovered by someone with the right key or mapping. Anonymization goes further.
Anonymization removes or generalizes identifying information so thoroughly that no one, not even the organization that anonymized it, can reconstruct who the record belongs to. Kanerika’s guide to data anonymization techniques covers that distinction in depth, including where anonymization and pseudonymization diverge from each other. Teams that land on anonymization instead of masking for a given dataset can compare dedicated data anonymization tools built around that stricter, irreversible standard.
Tokenization takes a different approach again. It replaces a sensitive value with a token that has no mathematical relationship to the original, then stores the mapping in a separate, tightly controlled vault. For example, a payment processor using tokenization can accept a token everywhere in its systems and reserve the actual card number for the one vault that needs it.
How Encryption and Hashing Compare Encryption, including format-preserving encryption, protects data with a reversible mathematical transformation controlled by a key. Anyone holding the key gets the original value back exactly. Format-preserving encryption keeps the output the same length and character type as the input. That is why it shows up in masking discussions, even though it is technically a cryptographic control rather than a masking technique.
Deterministic hashing maps the same input to the same output every time, which preserves the ability to join or match records across systems. The tradeoff is real. A predictable value, such as a common last name or a sequential ID, can sometimes be guessed and matched against a hash even without access to the original dataset. NIST’s de-identification guidance calls out this exact risk directly.
Table 1: Masking vs Anonymization vs Tokenization vs Encryption vs Pseudonymization
Technique Reversible What Changes Typical Use Data masking (static or dynamic) Sometimes, depending on method Sensitive value substituted with realistic fake data Test, dev, analytics, support access Anonymization No Identifying information removed or generalized permanently Public data releases, research datasets Tokenization Yes, via vault lookup Value replaced with a non-mathematical token Payment data, systems needing consistent references Encryption (incl. format-preserving) Yes, via key Value transformed by a cryptographic algorithm Data at rest or in transit, regulated storage Pseudonymization Yes, if the re-identification key is kept separately Direct identifiers replaced with pseudonyms GDPR-governed processing, research
None of these techniques is universally correct. The right choice depends on whether the data needs to come back in its original form and who controls that path back. It also depends on which regulation is setting the floor for that specific data type.
The Four Core Types of Data Masking Static data masking transforms a copy of the data before it reaches a lower-trust environment. A nightly job pulls production data, replaces sensitive fields, and loads the masked version into the test database, so the original values never leave the secure environment at all.
Dynamic data masking works differently. It applies a policy at query time, based on the identity and role of whoever is asking, and the underlying stored data never changes. A support agent might see the last four digits of an account number. A database administrator sees the full masked value or nothing at all, depending on the policy.
Deterministic masking maps identical inputs to identical masked outputs every time. If the same customer ID appears in three different tables, deterministic masking keeps the referential integrity between them, so joins and reports still work correctly against the masked data.
Format-preserving masking keeps the structure, length, and character type of the original value. A masked social security number still looks like nine digits in the right pattern. A masked email address still passes a basic format check, so downstream validation logic does not break.
12 Data Masking Tools Worth Evaluating in 2026 The market splits roughly into two groups. Data management platforms extend masking as one feature inside a broader integration or governance suite. Dedicated masking and test-data platforms, by contrast, treat masking, subsetting, and synthetic data generation as the whole product. The list below draws on functionality each vendor documents publicly.
Delphix (Perforce) focuses on test data management and data virtualization as much as masking itself. It automates sensitive-data discovery across databases, files, and cloud platforms, then applies masking as part of a broader pipeline that also handles data virtualization and refresh automation. Enterprises running large DevOps or QA programs tend to evaluate Delphix first because masking is one part of a wider data-delivery workflow, not a bolt-on.
Informatica data masking sits inside its broader data management and governance suite, which makes it a natural fit for organizations already standardized on Informatica for integration or data quality. Specifically, it supports substitution, shuffling, and encryption-based techniques across a wide range of structured data sources. The tradeoff is that Informatica’s masking strength is most visible to teams already invested in the rest of the platform.
IBM InfoSphere Optim Data Privacy targets large enterprise database estates, particularly organizations running IBM Db2, mainframe systems, or other legacy platforms alongside modern databases. It pairs masking with test data management and subsetting, so teams can shrink a multi-terabyte production database into a realistic, masked test set. It is a common choice in regulated industries with a heavy IBM footprint.
Four Platforms With a Narrower Focus K2view takes an entity-based approach, organizing and masking data around a business entity, such as a customer or an account, rather than table by table. That model helps in distributed, multi-source environments where the same customer’s data is scattered across a dozen systems. As a result, it is worth evaluating when referential integrity across a genuinely fragmented data estate is the hardest part of the problem.
Immuta focuses on policy-driven dynamic masking and fine-grained access control for modern cloud data platforms, including Snowflake and Databricks. Instead of writing masking logic per table, teams define policies once and apply them across many datasets based on attributes like role, purpose, or data classification. It fits organizations that already think in terms of centralized access policy.
Privacera centralizes data access policy and masking across cloud analytics platforms, with a strong emphasis on policy management extended to the cloud. It works well for organizations running a mixed estate of Databricks, Snowflake, and cloud storage that need one policy layer instead of separate rules per platform. Governance teams evaluating a single control plane for access and masking together tend to shortlist Privacera.
IRI FieldShield is built for speed and broad data-source coverage, spanning structured databases, flat files, and mainframe formats. It supports deterministic masking, data classification, and referential integrity out of the box. Its licensing model also tends to be more accessible for mid-market teams than the largest enterprise suites. Testing teams that need masking across many file formats often land on FieldShield.
More Data Masking Platforms Worth Evaluating Kanerika Service
Need Help Choosing and Implementing a Data Masking Tool?
Kanerika evaluates your data estate, maps masking requirements to the platforms you actually run, and implements the program end to end through its data governance service.
Explore Data Governance Services Oracle Data Masking and Subsetting is the default choice for Oracle-heavy estates, particularly organizations running Oracle Database or Oracle Cloud Infrastructure . It masks and subsets data in the same workflow, shrinking a large production database into a smaller, masked test copy in one pass. Outside an Oracle-centric environment, its value drops sharply, since it does not extend meaningfully to other database platforms.
Broadcom Test Data Manager bundles masking with synthetic test data generation and provisioning, aimed at large enterprise QA organizations running complex release cycles. It fits teams that already treat test data as its own discipline, with dedicated staff managing data across many test environments. That is different from a single database administrator handling it as a side task.
Protegrity Data Protection Platform leans toward tokenization and broader data protection, with masking as one technique inside a platform built around protecting data throughout its lifecycle. It supports vaultless tokenization, which avoids the operational overhead of managing a separate token vault. Organizations that need masking and tokenization working from one policy engine tend to evaluate Protegrity closely.
Two Tools Built for Developer Workflows DATPROF Privacy focuses on the test data management side of masking, including subsetting and provisioning alongside the masking itself. It targets teams that need to generate smaller, realistic, masked test environments repeatedly, not just mask a database once. Mid-market teams building a repeatable test-data pipeline, rather than a one-time compliance project, are a good fit.
Tonic.ai targets developers directly, with masking, synthetic data generation, and de-identification designed to fit into existing engineering workflows and CI/CD pipelines. It emphasizes realistic synthetic data over pure substitution in some cases, which helps analytics and machine learning teams that need statistically representative data. Engineering-led organizations gravitate toward Tonic.ai.
Table 2: Data Masking Tool Comparison
Tool Best Fit Deployment Masking Types Delphix DevOps test data and virtualization Cloud, on-prem, hybrid Static, dynamic, deterministic Informatica Enterprise data management suites Cloud, on-prem, hybrid Static, dynamic IBM InfoSphere Optim Large IBM or legacy DB estates On-prem, hybrid Static, deterministic K2view Entity-based, fragmented data Cloud, on-prem Static, deterministic Immuta Policy-driven cloud platforms Cloud (Snowflake, Databricks) Dynamic Privacera Centralized cloud access and masking Cloud Dynamic IRI FieldShield Broad file and DB coverage, mid-market On-prem, cloud Static, deterministic, format-preserving Oracle Data Masking and Subsetting Oracle-centric estates Oracle Cloud, on-prem Static Broadcom Test Data Manager Enterprise QA and test-data programs On-prem, cloud Static, synthetic Protegrity Masking and tokenization together Cloud, on-prem, hybrid Static, dynamic, tokenization DATPROF Privacy Repeatable masked test environments On-prem, cloud Static, subsetting Tonic.ai Developer and CI/CD workflows Cloud, on-prem Static, synthetic
The strongest tool on paper is not always the right one for a given team. An organization masking three Oracle databases for QA does not need K2view’s entity-based architecture. A team with data scattered across fifteen systems, on the other hand, will outgrow Oracle’s native tool almost immediately.
When Native Cloud Masking Is Enough Azure, AWS, GCP, Snowflake, and Databricks all ship native masking capability, and for a focused, single-platform environment, native tools often cover the requirement without a separate purchase. Azure SQL Database’s dynamic data masking applies policies directly in the database, with no application changes required, and grants or revokes unmask permission at the column level.
Google Cloud’s Sensitive Data Protection service , formerly Cloud DLP, detects more than two hundred sensitive data types. It applies masking, redaction, format-preserving encryption, or date-shifting as part of a broader data loss prevention pipeline. Similarly, Snowflake and Databricks both support dynamic masking policies natively inside their platforms, which removes the need for a separate tool if all the sensitive data already lives there.
Native masking loses its advantage the moment sensitive data spans more than one platform. A policy configured in Snowflake does not follow that data when it lands in a data lake, a different warehouse, or a partner’s system. Re-implementing the same logic in five places creates exactly the inconsistency that gives masking programs a bad reputation.
The build, buy, or use-native decision usually comes down to how many platforms actually hold sensitive data today, and how many will in eighteen months.
Eight Criteria for Choosing a Data Masking Tool Feature checklists make every vendor look similar on a call. In reality, the criteria below separate tools that work in a demo from tools that hold up across a real enterprise data estate.
Data source coverage. Confirm the tool reaches every database, file format, and cloud platform actually in scope, not just the ones in the sales demo. A tool that covers ninety percent of a data estate still leaves the remaining ten percent as an unmasked gap someone has to solve manually.Referential integrity. Verify masked values stay consistent across related tables, so joins, foreign keys, and reports keep working against masked data. A tool that masks each table independently, without preserving relationships between them, quietly breaks every downstream report that depends on those relationships.Sensitive data discovery .Static and dynamic support. Few enterprises need only one masking type forever, so confirm the platform genuinely supports both instead of treating one as an afterthought bolted onto the other.Cost, Compliance, and Scale Round Out the List Performance at scale. Masking a multi-terabyte production database on a nightly schedule is a different problem than masking a sample dataset in a demo. A tool that struggles at real volume turns a routine job into an overnight bottleneck.Policy and governance integration. The tool should connect to existing data classification and governance systems instead of maintaining its own disconnected rule set that a separate team has to keep synchronized by hand.Compliance mapping. Ask the vendor to show, not just claim, how the tool supports GDPR, HIPAA, or PCI DSS requirements for the specific data types in scope. Get specifics on which fields map to which regulation.Total cost at real scale. List price rarely reflects cost at production scale. Model licensing against actual data volume and the number of environments needing masking, not the single environment shown in the pilot.Checklist
Enterprise Data Governance Checklist
A practical checklist for scoping classification, masking, and access policies before a governance rollout goes wide.
Get the Checklist → Rolling Out Data Masking Without Breaking Downstream Systems A masking rollout that works in the pilot and fails in production usually skips the same step. Nobody tested what happens when masking goes wrong, only what happens when it goes right. A proof of concept should intentionally probe failure modes, not just confirm that a handful of sample records mask correctly.
Run the pilot against a report or application that depends on referential integrity across multiple tables, not an isolated dataset with no downstream dependencies. If a masked customer ID breaks a join two systems away, that is exactly the failure a small, isolated pilot will never surface until it reaches production.
Get the teams who consume the data involved before rollout, not after. Analysts, support staff, and downstream application owners often discover that a masking policy hides a field they genuinely needed. Finding that out during a pilot costs far less than finding it out after a production cutover.
Questions Worth Asking Every Vendor Vendor evaluations benefit from specific, pointed questions rather than a general feature walkthrough. For instance, ask a vendor to run their tool against a representative sample of the real data estate, including the messiest tables. A clean demo dataset built to make every feature look good will not surface the same problems.
Schema changes are worth probing directly. A masking rule tied to a column that gets renamed or restructured needs to keep working without a manual rewrite. Ask directly how the vendor supports the specific compliance requirements in scope. Then request a reference customer in a similar regulatory environment.
A tool that performs well for a retailer handling payment data is not automatically the right fit for a hospital system governed by HIPAA. Masking is also not a one-time project once it goes live.
New tables, new fields, and new integrations appear constantly, and a masking program that does not get re-scanned on a schedule slowly accumulates blind spots. Teams that treat data masking as an ongoing operational discipline run scheduled discovery scans and policy reviews. That discipline avoids the slow drift that turns a strong initial rollout into a false sense of security eighteen months later.
Datasheet
Elevate Data Governance, Compliance, and Security
See how a unified governance, compliance, and security program supports masking, classification, and access control together.
View the Datasheet → How Masking Needs Change Across Databases, Pipelines, and AI Workloads Masking a single relational database is the easiest version of this problem. A data pipeline moving information from source systems into a warehouse or lakehouse needs masking applied at a specific stage. That stage needs to come early enough that no unmasked copy lands somewhere nobody is tracking.
APIs raise a different question. An API that returns customer data to a partner or a mobile app needs masking applied at the response layer, often dynamically. The right policy depends on who is calling and what they are authorized to see. Getting this wrong means a masking policy that works perfectly inside the database but does nothing for the API sitting in front of it.
AI and RAG Workloads Raise New Risks AI and machine learning workloads add a genuinely new problem. Training data pulled from production systems can carry the same PII, PCI, or PHI as any other copy. A model trained on unmasked data can sometimes surface fragments of that data back out in its outputs. Masking or synthetic data generation before training is becoming a standard control as enterprises scale AI initiatives across more sensitive datasets. It is no longer an optional safeguard.
Retrieval-augmented generation adds another layer to watch. A chatbot or agent pulls live records from a production database to answer a question. In the process, it can inadvertently surface an unmasked field the requesting user was never authorized to see. The risk is highest when the retrieval layer sits outside the access controls the core database already enforces.
Teams building AI agents against sensitive data increasingly apply the same dynamic masking logic used for human users to the AI system’s own service account. A model answering a support question then sees exactly what a human agent in that same role would see, and nothing more.
AI Assessment
How AI-Ready Is Your Sensitive Data Handling?
Kanerika’s AI Maturity Assessment scores your data governance, security, and AI readiness, and flags gaps before they reach a production model.
Start Your AI Assessment → Meeting GDPR, HIPAA, and PCI DSS Requirements With Data Masking GDPR does not name masking directly, but it does define pseudonymization as processing personal data. So it can no longer be attributed to a specific person without additional information kept separately. Masking that meets this bar reduces regulatory risk, but pseudonymized data is still personal data under GDPR, since the mapping back to the individual technically still exists somewhere.
HIPAA offers a more prescriptive path through the Safe Harbor method , which requires removing eighteen specific identifiers from health information before it counts as de-identified. Masking that only substitutes some fields while leaving others, such as admission dates or zip codes, in their original form does not automatically satisfy Safe Harbor.
Teams handling protected health information need to map masking rules directly to that eighteen-identifier list, not assume generic masking is enough on its own.
PCI DSS is the most specific of the three for one data type. Requirement 3.4.1 in Version 4.0 requires masking the primary account number when displayed, showing no more than the first six and last four digits. It also requires rendering any stored PAN unreadable through masking, truncation, tokenization, or strong encryption. A masking tool that cannot enforce that exact display rule is not PCI DSS compliant on its own, regardless of what else it does well.
None of these three frameworks certifies a masking tool directly. Compliance comes from how the tool is configured against the specific data types, roles, and environments in scope. That is why a mature masking program documents the mapping between each regulation’s requirement and the exact policy enforcing it, table by table.
Auditors generally want to see that mapping, not just a vendor’s marketing claim that its product is compliance-ready out of the box.
Data Masking Implementation: How Kanerika Builds Programs That Hold Up in Production Kanerika approaches data masking as one control inside a complete data governance and security program, not a standalone tool deployment. The typical engagement moves through four stages.
Assess. Map the current data estate and classify sensitive fields.Design. Build masking and access policies mapped to the regulations that actually apply.Implement. Deploy and test masking across the identified systems.Hand over. Leave the client’s own team with a governance model they can operate and extend.A regional bank came to Kanerika with data spread across multiple systems and no unified way to classify sensitive fields. Identifying personally identifiable, cardholder, and health-related data was a manual, error-prone process. Kanerika built a Microsoft Purview-based data discovery and classification process that automatically mapped data assets and applied governance policies to personal, cardholder, and health data. It also established data-sharing rules based on sensitivity, so the right information reached the right stakeholders and nothing else did.
The engagement delivered a 72% improvement in the bank’s overall governance posture, measured across the same visibility, classification, and compliance metrics the bank had struggled to track before the project.
Case Study
72% Governance Improvement for a Bank With Microsoft Purview
A regional bank replaced manual, error-prone data classification with an automated Purview-based discovery and policy program covering PII, PCI, and PHI.
Read the Case Study → Common Pitfalls in Real Masking Programs The pitfalls Kanerika’s teams see most often are not technical. A masking policy that only covers the production database while ignoring the six downstream copies analysts have already created protects almost nothing.
A classification process that runs once at project kickoff, instead of continuously as new fields and tables appear, drifts out of date within a quarter. Kanerika also builds Susan, an AI agent that automates PII redaction across documents and workflows, as a complementary capability alongside database and pipeline-level masking.
Kanerika delivers this work through its data governance service , alongside kanSuite, a set of governance services covering strategy, regulatory compliance, and unauthorized access prevention, built on Microsoft Purview. The goal in every engagement stays constant. In other words, sensitive data stays usable for the teams that legitimately need it and invisible to everyone else.
Kanerika is ISO 27001 and ISO 27701 certified, SOC 2 Type II compliant, and GDPR compliant. Those credentials matter directly for a masking or classification engagement, since the firm implementing the controls is held to the same standards the controls are meant to satisfy. Kanerika is a Microsoft Solutions Partner for Data and AI, a Databricks Consulting Partner, and a Snowflake Select Tier Partner. Those credentials shape how its teams approach native-versus-dedicated masking decisions across Azure, Databricks, and Snowflake, rather than defaulting to whichever platform a given consultancy knows best.
The Right Data Masking Tool Depends on Your Architecture, Not the Vendor Ranking No tool on the list above is the correct choice for every enterprise. The right starting point is the data estate itself, not the vendor list. Consider which platforms hold sensitive data today and whether static or dynamic masking fits the access patterns already in play. Also weigh which regulations set the compliance floor for each data type.
A strong product still fails its purpose if sensitive fields get missed during classification, policies apply inconsistently across environments, or a downstream copy of the data slips out unmasked. Treat tool selection as the second decision, after data architecture and classification are already solid, and the twelve platforms compared here become far easier to narrow down.
Frequently Asked Questions
What are the best data masking tools for enterprise databases? The strongest options for large, multi-database enterprise estates are Delphix, Informatica, and IBM InfoSphere Optim Data Privacy, since all three pair masking with broader test data management and governance capability. K2view and Immuta suit organizations with fragmented data or cloud-native platforms specifically. The right choice depends on which databases, file formats, and cloud platforms actually hold sensitive data, not a single universal ranking.
What is the difference between static and dynamic data masking? Static masking transforms a copy of the data before it reaches a test, development, or analytics environment, so the stored values are permanently changed in that copy. Dynamic masking applies a policy at query time based on the requester’s identity, while the underlying stored data never changes. Most enterprises need both, applied to different parts of their data estate.
What is the difference between data masking and data anonymization? Data masking substitutes sensitive values with realistic, structurally valid data, and depending on the technique, the original value can sometimes be recovered through a key or mapping. Data anonymization permanently removes or generalizes identifying information so no one can reconstruct the original record. Masking prioritizes usability, while anonymization prioritizes irreversibility.
Can masked data be reversed or recovered? It depends on the technique. Deterministic masking, tokenization, and format-preserving encryption can all be reversed by someone with the correct key or mapping table, which is why access to that mapping needs its own strict controls. True anonymization is designed specifically to prevent reversal, which is the core distinction between the two approaches.
Is data masking the same as encryption or tokenization? No. Encryption transforms data with a reversible mathematical algorithm controlled by a key, and tokenization replaces a value with a token that has no mathematical relationship to the original, stored separately in a vault. Masking substitutes values to preserve format and usability rather than applying cryptography, though some masking techniques, like format-preserving encryption, borrow cryptographic methods.
Which data masking tools are open source? Microsoft Presidio is a genuinely open-source framework for detecting and anonymizing PII across text, images, and structured data, now moving toward independent community governance. PostgreSQL Anonymizer is a mature open-source extension purpose-built for masking inside Postgres databases, supporting both static and dynamic strategies. Most enterprise-grade dedicated masking platforms remain commercial products.
Does data masking help with GDPR, HIPAA, and PCI DSS compliance? Yes, but the requirements differ by regulation. GDPR treats properly pseudonymized data as reduced-risk personal data, HIPAA requires removing eighteen specific identifiers under its Safe Harbor method, and PCI DSS mandates specific masking rules for how much of a card number can display. A masking program needs to map its rules to the exact regulation governing each data type.
How do you choose between native cloud data masking and a dedicated data masking platform? Native masking inside Azure, AWS, GCP, Snowflake, or Databricks works well when sensitive data lives entirely inside one platform. A dedicated masking platform earns its cost once sensitive data spans multiple databases, clouds, or file formats, since re-implementing the same masking logic separately on each platform creates inconsistency. Most enterprises outgrow native-only masking as their data estate grows.
