Mock Data Generator

A mock data generator is a specialized software utility designed to produce synthetic, structurally accurate, but entirely fictional information for use in software testing, system development, and user interface design. By programmatically generating realistic names, addresses, financial transactions, and user profiles, these systems allow developers to populate databases and test applications without exposing sensitive real-world information. This comprehensive guide will explore the mechanics, history, algorithms, and best practices of mock data generation, equipping you with the knowledge to implement robust data simulation strategies in any software engineering environment.

What It Is and Why It Matters

Mock data generation is the automated process of creating artificial data that mimics the statistical properties, formatting, and relational structures of real-world information. In software engineering, an application is essentially an engine that processes data; to build, test, and refine that engine, developers need fuel. However, using real user data—often containing personally identifiable information (PII) like social security numbers, credit card details, or medical records—poses severe security risks and violates strict privacy frameworks such as the General Data Protection Regulation (GDPR) in Europe or the California Consumer Privacy Act (CCPA). A mock data generator solves this critical problem by fabricating highly realistic "dummy" data that looks and behaves exactly like the real thing, but holds zero actual value or privacy risk.

The necessity of mock data extends far beyond basic privacy compliance; it is a foundational pillar of modern, parallel software development. In a typical agile development environment, frontend engineers designing user interfaces cannot wait weeks for backend engineers to finish building the database and application programming interfaces (APIs). By using a mock data generator, frontend teams can instantly create thousands of realistic JSON objects representing users, products, or blog posts, allowing them to build and test visual components immediately. Furthermore, mock data is essential for quality assurance and performance testing. If a company expects a massive influx of traffic on Black Friday, they cannot simply test their servers with ten manually created user accounts. They must use a generator to instantly synthesize one million user accounts and five million purchase orders, allowing them to simulate heavy server loads and identify architectural bottlenecks before they cause catastrophic system failures in production.

History and Origin of Mock Data Generation

The concept of using dummy data for testing is as old as computer science itself, but the automated generation of realistic mock data has a distinct and fascinating evolutionary timeline. In the 1970s and 1980s, during the era of mainframe computing and early relational databases, developers relied almost entirely on manual data entry or simplistic, hard-coded scripts to test systems. A developer testing a banking application might manually write an SQL script inserting ten rows of fictitious users, typically using placeholder names like "Test User 1" or "John Doe." This approach was notoriously rigid, time-consuming, and failed to account for the chaotic, unpredictable nature of real-world human data input. The turning point arrived in the early 2000s with the rise of dynamic web applications and the open-source movement, which demanded more scalable testing solutions.

In 2004, the Perl programming community saw the release of Data::Faker, one of the earliest widely-adopted libraries specifically designed to generate random, realistic data points like names, phone numbers, and IP addresses using pre-defined dictionaries. However, the true watershed moment for mock data occurred in 2010 when developer Marak Squires and Jason Davies ported the concept to JavaScript, creating Faker.js. Because JavaScript was becoming the dominant language of the web—running both in the browser and on servers via Node.js—Faker.js exploded in popularity. It allowed developers to generate massive amounts of localized, realistic data with just a few lines of code. This library became a foundational dependency for thousands of major corporations.

The history of mock data also includes a dramatic lesson in open-source reliance. In January 2022, the creator of Faker.js intentionally sabotaged his own widely-used library in a protest over corporate exploitation of unpaid open-source labor, causing automated builds to fail at companies worldwide. This event forced the software industry to re-evaluate how mock data tools are maintained, leading to community-driven forks like Faker (maintained by a broader open-source coalition) and the rise of robust, standalone mock data generator platforms and APIs that offer graphical interfaces, guaranteed stability, and multi-format exporting capabilities. Today, the field has evolved even further, incorporating artificial intelligence and machine learning models to generate synthetic data that not only looks real but perfectly mirrors the complex statistical distributions of actual production databases.

How It Works — Step by Step

To understand how a mock data generator creates millions of realistic records in seconds, one must look at the underlying mechanics: a combination of Pseudo-Random Number Generators (PRNGs), extensive data dictionaries, and structural templating. Computers cannot generate true randomness; instead, they use mathematical algorithms, such as the Mersenne Twister, to produce sequences of numbers that appear random. These algorithms start with a "seed" value—often the current system time in milliseconds. When a developer requests a mock data point, such as a random first name, the generator does not invent a name from thin air. Instead, it relies on a massive, pre-compiled array (a list) of real names categorized by locale, such as ["Alice", "Bob", "Charlie", ... "Zoe"].

Let us walk through a complete, step-by-step mathematical and programmatic example of generating a single mock user profile. Suppose our mock data generator is tasked with creating a user with a first name, a last name, and an age between 18 and 65. First, the generator initializes its PRNG. The PRNG produces a floating-point decimal between 0 and 1, for instance, 0.4285. Second, the generator needs a first name. It accesses an array of 1,000 common first names. It multiplies the random decimal by the length of the array (0.4285 * 1000 = 428.5) and rounds down to the nearest whole number (428). It retrieves the name at index 428 from the array, which happens to be "Michael". Third, the process repeats for the last name. The PRNG generates a new decimal, 0.8102. Multiplied by a 2,000-item last name array, it yields index 1620, retrieving the name "Smith". Fourth, to calculate the age, the generator uses a specific mathematical formula for ranging: Minimum + (Random Decimal * (Maximum - Minimum)). If the PRNG outputs 0.1500, the calculation is 18 + (0.1500 * (65 - 18)). This becomes 18 + (0.1500 * 47) = 18 + 7.05 = 25.05. Rounding down, the generated age is 25.

Finally, the generator takes these individual, randomly selected data points and serializes them into the exact structural format requested by the user. It applies string interpolation to combine the first and last name into an email address, perhaps converting them to lowercase and appending a random domain from a dictionary (e.g., michael.smith@example.com). This entire multi-step process, involving dictionary lookups, mathematical ranging, and string manipulation, executes in a fraction of a millisecond. When scaled up within a loop, the generator can output 10,000 completely unique, structurally sound user profiles in under a second, ready to be exported into a developer's database.

Key Concepts and Terminology

To navigate the world of data simulation effectively, you must master the specialized vocabulary used by data engineers and software testers. Misunderstanding these terms can lead to flawed testing strategies and compromised database architectures.

Pseudo-Random Number Generator (PRNG): An algorithm that uses mathematical formulas to produce sequences of numbers that simulate randomness. Because they rely on deterministic mathematics, PRNGs are not truly random, which is actually a massive advantage in testing, as it allows for reproducible results.

Seed / Seeded Randomness: A specific starting integer passed into a PRNG to initiate the random sequence. If you provide a mock data generator with the exact same seed (e.g., Seed: 12345), it will generate the exact same "random" dataset every single time. This is critical for regression testing, where developers need consistent data to ensure their code changes haven't broken existing functionality.

Referential Integrity: A database concept ensuring that relationships between tables remain consistent. In mock data generation, if you generate a mock "Order" that belongs to "User ID 50", a "User ID 50" must actually exist in the mock "Users" dataset. High-quality generators can maintain referential integrity across complex relational data structures.

Data Dictionary / Corpus: The static, internal lists of words, names, addresses, and formats that a generator uses as raw material. A robust generator contains diverse dictionaries covering dozens of languages and locales to simulate global user bases accurately.

Serialization: The process of translating the raw data structures generated in the computer's memory into a specific, standard text format (like JSON, CSV, or SQL) that can be saved to a file, transmitted over a network, or imported into a database.

Synthetic Data: Often used interchangeably with mock data, but technically distinct in modern enterprise contexts. While mock data is typically generated via random dictionary lookups, true synthetic data is generated by machine learning models that have analyzed a real production database and learned its statistical correlations (e.g., ensuring that mock users with the title "Senior Surgeon" are appropriately generated with higher ages and incomes than mock users with the title "Intern").

Types, Variations, and Methods of Data Generation

Not all mock data is created equal. The approach a developer chooses depends entirely on the complexity of the application being tested and the specific requirements of the testing environment. There are three primary methodologies for generating mock data, each with distinct trade-offs regarding speed, realism, and implementation complexity.

Rule-Based and Dictionary Generation

This is the most common and widely used method, powering traditional libraries and standard web-based generators. It relies on predefined lists (dictionaries) and specific formatting rules (Regular Expressions). If a developer requests a phone number, the generator applies a rule like (###) ###-#### and fills the hashes with random digits. If a developer requests a city, it picks randomly from a list of 5,000 global cities. Trade-offs: This method is incredibly fast, computationally inexpensive, and highly predictable. However, it lacks deep logical correlation. A rule-based generator might randomly pair the city "Tokyo" with the street name "123 Texas Cowboy Boulevard," which, while structurally valid as a string, is logically absurd.

Statistical and Distribution-Based Generation

More advanced testing scenarios require data that mimics real-world statistical distributions rather than flat, uniform randomness. In a uniform random distribution, generating ages between 10 and 90 means a 90-year-old is just as likely to be generated as a 30-year-old. In reality, user demographics follow a Bell Curve (Normal Distribution). Statistical generators allow developers to define means and standard deviations. For example, a developer can specify that the average user age is 35, with a standard deviation of 10. The generator uses algorithms like the Box-Muller transform to cluster the generated ages around 35, tapering off toward the extremes. Trade-offs: This requires more configuration and mathematical understanding from the user. It is highly valuable for load testing and performance tuning, where database indexing performance changes drastically based on the statistical distribution of the data.

AI and Machine Learning Generative Models

The cutting edge of data simulation involves Generative Adversarial Networks (GANs) and advanced language models. Instead of manually writing rules, data scientists feed an AI model a massive, anonymized dump of real production data. The AI analyzes the data, learns the hidden correlations (e.g., people in zip code 10021 tend to buy luxury items on Tuesdays), and then generates an entirely new synthetic dataset that perfectly mirrors those complex, multi-variable correlations without containing a single real user's information. Trade-offs: This method is highly computationally expensive, requires massive amounts of initial training data, and is generally overkill for standard web development. However, it is the absolute gold standard for training other machine learning models, financial risk modeling, and healthcare analytics where complex correlations are the entire focus of the study.

Output Formats: JSON, CSV, SQL, and TypeScript

A mock data generator's utility is ultimately defined by its ability to output data in the specific formats required by different engineering disciplines. Modern generators act as universal translators, taking the abstract generated data and serializing it into several industry-standard syntaxes.

JSON (JavaScript Object Notation)

JSON is the undisputed king of web development and API communication. It represents data as nested key-value pairs. Frontend developers building React, Angular, or Vue applications rely heavily on JSON mock data to simulate API responses before the real backend is built. A mock generator can output a highly nested JSON structure, such as a "User" object that contains an array of "Post" objects, which in turn contain arrays of "Comment" objects. This hierarchical formatting allows developers to test complex user interfaces, like multi-level navigation menus or cascading data tables, directly in the browser.

CSV (Comma-Separated Values)

CSV is a flat, two-dimensional file format where each line represents a row of data, and columns are separated by commas. This format is the lifeblood of data science, machine learning, and business intelligence. Data analysts using Python's Pandas library, Microsoft Excel, or Tableau require massive CSV files to test their data visualization dashboards and analytical scripts. A mock data generator outputting CSV strips away hierarchical nesting, flattening the data into a strict tabular format that can easily exceed millions of rows while maintaining a tiny file size footprint.

SQL (Structured Query Language)

For backend engineers and database administrators (DBAs) working with relational databases like PostgreSQL, MySQL, or Oracle, data must be inserted using specific programming commands. A generator outputting SQL does not just provide the raw data; it generates the actual INSERT INTO statements required to populate the database. Crucially, advanced generators handling SQL output will respect relational constraints. They will generate a primary key for a user table, and then meticulously use that exact same key as a foreign key when generating the corresponding INSERT statements for the orders table, ensuring the database does not reject the mock data due to constraint violations.

TypeScript Interfaces and Types

TypeScript is a superset of JavaScript that adds strict static typing to the language, preventing runtime errors by ensuring data conforms to specific structural contracts. Modern mock data generators go beyond just outputting the raw data; they can actually inspect the data they are generating and automatically write the TypeScript interface or type definitions that describe it. For example, if the generator creates a mock user with an ID (number) and a Name (string), it will output interface MockUser { id: number; name: string; }. This saves frontend developers countless hours of manually typing out the structural contracts for their simulated APIs.

Real-World Examples and Applications

To grasp the true value of mock data generation, one must look at how it is applied to solve concrete, high-stakes engineering problems in the real world. Abstract concepts become clear when applied to specific, quantifiable scenarios.

Scenario 1: E-Commerce Load Testing for Black Friday A mid-sized e-commerce company is migrating to a new cloud infrastructure and expects 50,000 concurrent users during a major holiday sale. They cannot test their database performance with their current production database of 10,000 users. The database engineering team uses a mock data generator to create a massive SQL script containing 2,000,000 fictional users, 10,000,000 mock products, and 50,000,000 historical order records. By seeding their test database with this massive volume of data, they can run automated scripts to simulate heavy traffic. They discover that a specific database query related to calculating shopping cart totals takes 4.5 seconds when the database has 50 million rows. Because they used mock data to find this bottleneck in August, they have time to add database indexes, reducing the query time to 0.1 seconds long before the November traffic spike.

Scenario 2: Healthcare Application UI Development A software agency is hired to build a patient portal for a major hospital network. Because medical records are strictly protected by the Health Insurance Portability and Accountability Act (HIPAA), the developers are legally barred from ever seeing real patient data. However, the frontend team needs to design a complex interface that handles edge cases: patients with extremely long hyphenated names, patients with missing insurance providers, and patients with hundreds of historical lab results. The team configures a mock data generator to output 5,000 JSON records of fake patients, specifically injecting intentional edge cases (like 5% of records having null values for "Secondary Insurance"). This allows the UI designers to build robust error-handling states and ensure the layout doesn't break when a name exceeds 40 characters, all while maintaining strict legal compliance.

Scenario 3: Financial Analytics Pagination A developer is building a dashboard that displays stock market trades. The API will eventually return thousands of trades, so the UI must implement "pagination" (showing 50 results per page and allowing the user to click "Next"). To build and test this pagination logic, the developer uses a mock data generator to instantly create a CSV file containing exactly 1,042 fake stock trades. They import this into their local development environment and write the logic to display 20 pages of 50 results, with the final page correctly displaying exactly 42 results. Without a generator, the developer would have had to manually type out over a thousand fake trades just to verify their math was correct.

Common Mistakes and Misconceptions

Even experienced developers frequently mismanage mock data, leading to brittle tests, false confidence in system performance, and wasted engineering hours. Understanding these common pitfalls is essential for mastering data simulation.

The most pervasive misconception is that "mock data is just random gibberish." Beginners often populate their test databases with strings of pure random characters, such as a user whose first name is aX9jK2 and whose email is pL4@qZ.com. While this technically fulfills the database requirement of "insert a string here," it completely invalidates UI testing and regular expression validation. If your application has a validation rule that checks if an email contains a valid top-level domain (like .com or .org), pure gibberish will fail. Mock data must be semantically realistic, not just structurally valid. It must look like human-generated information to properly test the application's logic.

Another critical mistake is ignoring the importance of "dirty" data. Developers have a natural bias toward creating perfect, pristine test scenarios. They configure their mock generators to output 10,000 users where every single user has a perfectly formatted phone number, a complete address, and a valid profile picture URL. Real-world production data is incredibly messy. Users make typos, leave optional fields blank, and use non-standard characters. If you only test your application with pristine mock data, your application will crash the moment a real user inputs a name with an apostrophe (like O'Connor) or leaves their zip code blank. A professional must intentionally configure their mock generator to inject a specific percentage of null values, missing fields, and special characters to ensure the application's error handling is robust.

Finally, developers frequently fail to maintain referential integrity when generating relational data. A junior developer might generate a CSV of 1,000 users and a separate CSV of 5,000 orders. However, if the user IDs in the order file range from 1 to 10,000, but the user file only contains IDs from 1 to 1,000, the database will throw severe foreign key constraint errors upon import. The order records will point to users that do not exist. Generating relational data requires a coordinated, sequential approach where the primary keys generated in step one are explicitly used as the pool of available foreign keys in step two.

Best Practices and Expert Strategies

To elevate your use of mock data from basic placeholder generation to professional-grade system testing, you must adopt the strategies used by elite engineering teams. These practices ensure reliability, repeatability, and maximum testing efficacy.

Always Use Deterministic Seeding: The cardinal rule of automated testing is that tests must be reproducible. If your unit tests fail on a Tuesday, you must be able to run them again on Wednesday and get the exact same failure to diagnose the bug. If your mock data generator uses a truly random, unseeded output, a bug might appear only when a specific, rare edge case is randomly generated, making it impossible to reproduce and fix. By hardcoding a specific seed value (e.g., generator.setSeed(9942)) in your test configuration, you guarantee that the generator will output the exact same 10,000 "random" users every single time the test suite runs. If a bug is found, it stays found until you fix it.

Automate Generation in the CI/CD Pipeline: Mock data should not be a static file that a developer generates once and emails to the team. Static files become outdated as database schemas evolve. Instead, experts integrate the mock data generator directly into the Continuous Integration/Continuous Deployment (CI/CD) pipeline. Every time a developer commits new code, the CI server should automatically spin up an empty test database, run the generator script to populate it with 50,000 fresh, schema-compliant records, run the automated tests against that data, and then destroy the database. This ensures that the mock data always perfectly matches the current state of the application's architecture.

Match Production Statistical Distributions: When performing load testing or query optimization, uniform random data is dangerous. If you generate a mock database where every user has exactly 5 orders, your database engine will optimize its query execution plans based on that perfectly uniform distribution. When you deploy to production, where 90% of users have 1 order and 1% of users have 5,000 orders, the database will choke. Experts profile their production databases to understand the statistical distribution of the data, and then configure their mock generators to match those exact mathematical curves. If production data follows an 80/20 Pareto distribution, the mock data must follow an 80/20 Pareto distribution.

Edge Cases, Limitations, and Pitfalls

While mock data generation is an indispensable tool, it is not a silver bullet. Relying too heavily on simulated data without understanding its inherent limitations can lead to catastrophic blind spots in software quality assurance.

The most significant limitation of rule-based mock data is the phenomenon known as the "Uncanny Valley of Data." Because traditional generators pick data points independently from different dictionaries, they lack contextual real-world logic. A generator might perfectly format a date of birth, a job title, and a salary. However, it might generate a record for a 4-year-old child whose job title is "Chief Executive Officer" and whose salary is $450,000. While each individual field is structurally valid and passes basic type validation, the row as a whole is logically impossible. If your application includes complex business logic—such as an insurance quoting engine that calculates premiums based on the correlation between age, occupation, and income—traditional mock data will cause the logic to behave erratically and produce worthless test results.

Another major pitfall involves memory limitations and performance bottlenecks during the generation process itself. Developers often assume that because a generator can create 1,000 records in 10 milliseconds, it can create 100,000,000 records in a few seconds. However, generating massive datasets in memory, particularly in browser-based tools or Node.js environments, can quickly exceed the system's available RAM, causing the generator to crash with an "Out of Memory" error. When generating datasets larger than a few hundred megabytes, experts must abandon simple array-building techniques and utilize "streaming" architectures. Streaming generates and writes the data to the hard drive one row at a time, keeping the memory footprint incredibly small regardless of whether you are generating ten rows or ten billion rows.

Finally, developers must be wary of localization limitations. A generator might be excellent at producing realistic American addresses and phone numbers, but completely fail when tasked with generating Japanese Kanji names, British postal codes, or Arabic right-to-left text strings. If an application is intended for a global audience, testing it exclusively with US-centric mock data will mask critical UI bugs related to character encoding, string length, and regional formatting standards.

Industry Standards and Benchmarks

In enterprise software development, the generation and usage of mock data are governed by specific industry standards, compliance frameworks, and performance benchmarks. Adhering to these norms separates amateur projects from professional, enterprise-grade engineering.

From a compliance perspective, the use of mock data is heavily mandated by frameworks like ISO 27001, SOC 2 Type II, and the Payment Card Industry Data Security Standard (PCI-DSS). These standards explicitly forbid the use of unmasked production data in lower-level development and testing environments. According to industry best practices, a developer's local machine should never contain a single row of real customer data. Mock data generators are the standard industry solution for fulfilling the "Data Minimization" and "Environment Segregation" controls required to pass these rigorous security audits. If an auditor discovers that a team is testing their application by copying the production database to a staging server, the company will fail their compliance audit, potentially losing major enterprise clients.

Performance benchmarks for modern mock data generators are exceptionally high. In a standard Node.js or Python environment, a high-quality, localized mock data generator should be capable of producing and serializing at least 10,000 complex JSON objects per second on a standard consumer laptop. For flat CSV generation, speeds should easily exceed 50,000 rows per second. If a data generation script takes several minutes to produce a few thousand rows, it is poorly optimized, likely suffering from synchronous blocking operations or inefficient memory management. In massive enterprise load testing, specialized, compiled generators written in languages like Go or Rust are benchmarked to output gigabytes of synthetic data per minute directly into cloud storage buckets.

Comparisons with Alternatives

To truly understand the value of a mock data generator, one must compare it against the alternative methods teams use to populate testing environments. The two primary alternatives are Manual Data Entry and Production Database Cloning (Anonymization).

Mock Data Generator vs. Manual Data Entry: Manual data entry involves human testers physically typing fake information into the application's user interface. Pros: It perfectly mimics the exact pacing and workflow of a real human user, often uncovering UX (User Experience) quirks that automated scripts miss. Cons: It is agonizingly slow, fundamentally unscalable, and incredibly expensive. A human tester might take 5 minutes to create a single complex user profile with an associated order history. Generating the 10,000 records needed for a basic pagination test would take a human hundreds of hours. A mock data generator accomplishes the same task in less than a second. Manual entry is reserved for final, exploratory UI testing, while mock generators handle all structural and volume testing.

Mock Data Generator vs. Production Database Cloning (Anonymization): Database cloning involves taking a direct copy of the live production database and running a script to "mask" or scramble the sensitive fields (e.g., changing real names to fake names) before giving it to developers. Pros: Cloned data provides the absolute highest level of logical realism. Because the underlying data structure was created by real users, all the complex, multi-variable correlations, edge cases, and statistical distributions are perfectly preserved. Cons: It is a massive security risk. Data anonymization is notoriously difficult to get right. If a script misses a single table, or if a user accidentally typed their social security number into an unstructured "Notes" field that the masking script ignored, highly sensitive PII will leak into the development environment. Furthermore, production databases are often terabytes in size, making them extremely slow and expensive to copy and distribute to individual developers. Mock data generators provide a much safer, lighter, and more agile alternative, creating data from scratch with zero risk of accidental privacy breaches.

Frequently Asked Questions

What is the difference between mock data and synthetic data? Mock data typically refers to information generated via rule-based systems and random dictionary lookups, focusing on structural accuracy and rapid generation for basic testing. Synthetic data, in modern contexts, refers to data generated by artificial intelligence and machine learning models that have analyzed a real dataset. Synthetic data not only matches the structure but perfectly replicates the complex, hidden statistical correlations of the original data, making it suitable for training other AI models or performing deep financial analysis.

How do I ensure referential integrity when generating multiple tables? To maintain relationships between tables (like Users and Orders), you must generate the data sequentially. First, generate the parent table (Users) and capture the generated Primary Keys (e.g., User IDs 1 through 1000) into an array or variable in your script. When generating the child table (Orders), configure the generator to randomly select its Foreign Key values exclusively from that saved array of valid User IDs. High-end mock data platforms handle this automatically via graphical relationship mapping.

Can mock data be used to train machine learning models? Standard, rule-based mock data should never be used to train predictive machine learning models. Because standard mock data lacks real-world correlation (e.g., it might randomly assign high incomes to high school students), a model trained on this data will learn nonsensical patterns and fail completely in the real world. You must use AI-driven synthetic data generation, which preserves complex statistical relationships, if your goal is machine learning training.

What is a random seed and why is it important? A random seed is a specific starting number fed into a pseudo-random number generator algorithm. Because computer algorithms are deterministic, providing the exact same seed will always result in the exact same sequence of "random" outputs. This is crucially important in software testing because it allows developers to create reproducible test environments; if a test fails on a randomly generated dataset, using a seed ensures the developer can generate that exact same dataset again to debug the issue.

Why shouldn't I just scramble or mask my production data for testing? While data masking is a valid technique, it carries severe security risks. It is incredibly difficult to perfectly sanitize a complex production database; sensitive information often hides in unstructured text fields, JSON blobs, or error logs that masking scripts miss. A single mistake can result in a massive data breach if that "masked" database is exposed. Generating mock data entirely from scratch guarantees that zero real user data ever enters the testing environment, eliminating the risk entirely.

How much mock data is enough for load testing? The volume of mock data required for load testing depends on your production expectations, but a standard rule of thumb is to generate at least 3 to 5 times your current production volume, or your projected volume for the next 18 months. If your live database has 1 million rows, load testing with 10,000 mock rows is useless, as it will not trigger the memory swapping or index scanning behaviors that cause real-world database bottlenecks. You must test at, or above, real-world scale.