- What is forget-db and what problem does it solve?
- forget-db is a small Laravel package that anonymises confidential database data so production clones can be used safely in staging or development. You map Eloquent models and columns to Faker formatters in a config file, then run an Artisan command that overwrites the matching rows in place. It is a narrow, single-purpose scrubbing utility rather than a full GDPR or data-governance platform. It has no concept of data subject requests, retention policies or consent records.
- How do I install and run forget-db in a Laravel project?
- You pull it in with Composer, publish the package config file, and declare your mappings as Model => ['column' => 'fakerMethod']. You then run php artisan forget-db, which walks the mappings and mutates the rows directly through Eloquent. The integration itself is mechanically simple; the real effort is building a PII inventory for each table and translating it into the mapping file. On modern Laravel versions you will likely need to fork and patch the package before it will even install.
- Which PHP and Laravel versions does forget-db support?
- The last release was July 2020, so it targets PHP 7.x and Laravel 5, 6 and 7 era conventions. There is no PHP 8+ or current Laravel compatibility, and it most likely depends on the abandoned fzaninotto/faker rather than fakerphp/faker. On a modern stack that means a fork-and-patch before Composer will resolve. Check the repository and issue tracker for any newer community forks before committing.
- How do I configure which columns get anonymised?
- Configuration is a single array in the published config file that maps each Eloquent model class to a set of columns and the Faker formatter used to replace them. For example you would pair a User model's email column with a Faker email method and its name column with a Faker name method. Only columns you explicitly list are touched, so anything you forget stays in the database untouched. That makes the mapping file the single source of truth and the main thing you have to maintain over time.
- Does forget-db have a dry-run mode or an audit log of what changed?
- A dry-run or diff mode is not part of the documented 2020 feature set, and there is no built-in audit log describing which rows were changed. Given that anonymisation is destructive by design, this is one of the first things you should add if you fork the package. A --dry-run flag that prints the affected tables and row counts costs very little to implement and prevents the worst failure mode. Until then, always take a verified backup before running it.
- Is it safe to run forget-db against a production database?
- No, it is not designed for production data-subject erasure, and the failure mode is worse than the problem it solves. A misconfigured mapping, a wrong environment or a partially completed run leaves data overwritten and unrecoverable, with no transaction guarantee documented for mid-run failures. The sensible use case is scrubbing a production clone before it lands in staging or development. If you need auditable erasure of a specific person's data, use targeted redaction with a legal record instead.
- What licence is forget-db released under, and can enterprises adopt it?
- The repository metadata reports NOASSERTION, meaning the licence is not machine-classifiable and is not clearly stated in the README. For most enterprises that is a hard stop, and legal is especially unlikely to approve an unclassified licence for a package whose job is to irreversibly destroy data. The pragmatic route is to vendor the source into an internal namespace rather than depend on it through Composer. That sidesteps the licence ambiguity and the supply-chain risk in a single step.
- Does forget-db handle foreign keys, relations and multiple database connections?
- It assumes the standard Laravel Eloquent model layer on a single MySQL or Postgres connection, and there is no documented handling of foreign key constraints or cascading relations. Anonymising a key column in one table can break referential integrity or leave related records de-anonymised. Multi-tenant setups with dynamic connections, raw query access and JSON or document stores fall outside what it supports. Test any FK-constrained schema thoroughly before trusting it.
- Will forget-db automatically pick up new PII columns I add later?
- No. The tool only anonymises what is explicitly listed in the config file, and it has no schema-drift detection or coverage assertion. If a developer adds a new personal data column and nobody updates the mapping, the command still reports success while that column is left fully exposed in your staging database. Treat the mapping file as something that must be reviewed in every migration pull request. Periodic manual audits of the schema against the mapping are the only reliable safeguard.
- Is forget-db still maintained, and what are the alternatives?
- It was last released in July 2020 with a single maintainer, roughly 140 stars and no security or framework tracking since, so treat it as unmaintained. The cleanest option is to copy the pattern into your own codebase, swap in fakerphp/faker, update the command signatures to current Laravel conventions, and add the missing safety rails such as --dry-run, chunking and deterministic seeded output. If you want to stay on a supported dependency, look at actively maintained anonymisation packages or write a small custom Artisan command. The idea is worth borrowing; the artefact is not.