datacharmer/test_db: a sample MySQL and PostgreSQL database for testing servers and applications

What datacharmer/test_db actually gives you

test_db is a relational schema plus exported data, not a library and not a service. The README states the database contains about 300,000 employee records with 2.8 million salary entries, and that the export data is 167 MB. That size is the point: it is small enough to load on a laptop, large enough that a query plan, an index choice, or a replication setup behaves differently than it would against a ten-row fixture. The schema is the classic employees model (employees, departments, dept_manager, dept_emp, titles, salaries), and the README points to the MySQL documentation for usage. The audience is narrow and specific: people testing database servers, testing an application's SQL against realistic volumes, or demonstrating a migration between MySQL-compatible engines and PostgreSQL. The README also says the data was generated, and that inconsistencies were deliberately left in rather than cleaned, so the dataset doubles as a data cleaning exercise. That is an unusual choice and worth knowing before you build assertions on top of it.

How the dump, the partitioned variant and the integrity tests fit together

The repository is a flat set of SQL files plus per-table dump files. employees.sql is the loader that pulls in load_employees.dump, load_departments.dump, load_dept_emp.dump, load_dept_manager.dump, load_titles.dump and the three salary dumps (load_salaries1.dump through load_salaries3.dump). employees_partitioned.sql is an alternative loader that the README describes as installing two large partitioned tables; employees_partitioned_5.1.sql is a second variant, and objects.sql and show_elapsed.sql are auxiliary scripts. The verification path is separate from the load path: test_employees_sha2.sql, test_employees_md5.sql and test_employees_sha.sql each compare a record count and a checksum per table against expected values. The README's sample output shows expected and found CRCs for all six tables, then a third result set with records_match and crc_match columns reading OK and ok. The README states the SHA-256 checksums are identical across all supported MySQL, Percona, MariaDB and PostgreSQL versions, which is what makes a single expected value meaningful when you move the same fixture between engines. A postgresql/ directory sits alongside the MySQL loaders, and the CI badges cover MySQL, Percona, MariaDB and PostgreSQL separately.

Installing test_db and running the first integrity check

The README's installation steps are two: download the repository, then change directory into it. You need a MySQL server 5.0 or newer and a user holding the privileges the README lists, which include SELECT, INSERT, UPDATE, DELETE, CREATE, DROP, RELOAD, REFERENCES, INDEX, ALTER, SHOW DATABASES, CREATE TEMPORARY TABLES, LOCK TABLES, EXECUTE and CREATE VIEW. Once you are in the repository directory, the load is a single redirect into the client:

mysql < employees.sql

If you want the partitioned layout instead, the README gives a second loader. The README notes that from MySQL 9.5 the SOURCE command requires the --commands flag, and that the client's default for --commands is FALSE from 9.x, so the flag has to be passed on each mysql call:

mysql --commands < employees.sql

After loading, run an integrity test. The README recommends test_employees_sha2.sql because it uses SHA2(..., 256) and works on all versions, including 9.6 and later where MD5() and SHA() were removed from the server:

mysql -t < test_employees_sha2.sql

What you should see is three tables of output: expected records and CRCs, found records and CRCs, and a final comparison with records_match and crc_match columns. In the README's example all six tables report OK and ok. If any row differs, the load did not complete as the fixture expects. The MD5 and SHA-1 test files still exist but the README states they will not work on MySQL 9.6 or later.

Where the fixture stops being useful

The data is generated, and the README says so plainly, with inconsistencies and subtle problems left in on purpose. That makes it a poor base for anything that depends on realistic distributions: cardinality estimates on skewed real-world columns, string collation edge cases, or date ranges that match a production calendar. A query that performs well here may not perform well on your data, and an index tuned against these tables proves nothing about selectivity elsewhere. The integrity tests are also version-sensitive in ways that are easy to miss. The README documents that MD5() and SHA() were removed from MySQL starting with 9.6, which silently breaks test_employees_md5.sql and test_employees_sha.sql on those servers; the SHA-256 file is the one that survives. And the load itself is not idempotent in the sense a migration tool expects: it creates and drops objects, so running employees.sql against a database that already holds tables with those names is a destructive operation, which is why the privilege list includes DROP. If you need a fixture that is safe to re-run against a shared instance, this is the wrong tool.

test_db against sakila, and against generating your own data

The repository carries a sakila/ directory, so the natural comparison is internal. Sakila is the other well-known MySQL sample database, but it models a DVD rental business with a different schema shape and a different set of relationships; test_db models an employee hierarchy with salaries and department assignments, and its distinguishing feature is the integrity test suite tied to fixed checksums. If you are testing aggregate queries over time-series-like salary rows, test_db's 2.8 million salary entries are closer to the shape you want. If you are testing a schema with many small lookup tables and join-heavy reporting, sakila's structure may fit better. The third option is generating your own data, which gives you control over distribution and volume but leaves you writing your own verification. The trade test_db makes is the opposite: fixed data, fixed checksums, and no control over what is in it. The README's note that the SHA-256 checksums are identical across MySQL, Percona, MariaDB and PostgreSQL is the strongest argument for it over a homegrown generator, because it turns the fixture into something you can verify after a cross-engine migration.

Maintenance, licence and what upgrading costs

The repository is not archived, and the last push was on 2026-04-10. The most recent tagged release is v1.0.7 from 2020-10-31, so the release cadence and the commit cadence do not match; treat the release tag as a label rather than a signal of how the files change. The README shows active attention to server versions: the tested-versions table covers MySQL 5.6 through 9.6, Percona Server 8.0 and 8.4, MariaDB 10.11, 11.4 and 12.1, and PostgreSQL 16 and 17, and the CI runs on a weekly schedule using ProxySQL/dbdeployer. That is the upgrade cost you should budget for: each new server major version can change how the loader or the test files behave, and the MySQL 9.5 --commands change and the 9.6 removal of MD5() and SHA() are two concrete examples already documented. If your CI pins a server version, the fixture is stable. If you track the newest MySQL, expect the integrity test file to be the part that breaks first. On licensing, the repository metadata does not state a licence, and the README does not either. The README only says the repository was migrated from Launchpad. Without a stated licence, you cannot assume redistribution terms, so check the repository and the original Launchpad project before shipping the dump inside a product or a public image.

Editorial conclusion

Use test_db when you need a non-trivial relational dataset to exercise a server, a migration, or an application query layer, and you want a checksum to tell you the load was correct. Skip it if you need production-shaped data with realistic distributions, or if you need a documented licence, because the repository does not state one. Before adopting it, load employees.sql on the exact server version you target, run test_employees_sha2.sql, and confirm the expected and found CRCs match on all six tables.

Frequently asked questions

Official sources

1. datacharmer/test_db on GitHub
2. Issues
3. README
4. Releases