Forget Db Laravel Package

Technical Evaluation

Architecture fit. forget-db is a classic Laravel service-provider package: a config file maps Eloquent models to columns and Faker formatters, and an Artisan command walks the mappings and mutates rows in place. It fits a Laravel monolith with Eloquent models and MySQL/Postgres cleanly because it assumes the framework's model layer, config loader, and console kernel. It does not fit multi-tenant schemas with dynamic connections, non-Eloquent data access, raw tables, JSON/document stores, or services outside Laravel. For a TPM, this is a narrow, single-purpose utility rather than a data-governance platform — it anonymises tables, not subjects, and has no concept of a data subject request, retention policy, or consent record.

Integration feasibility. Integration is mechanically simple: publish config, declare Model => ['column' => 'fakerMethod'], run php artisan forget-db. The real effort is governance, not code — you must first produce a PII inventory per table, then translate it into the mapping file, then keep it in sync as schemas evolve. The 2020 release date is the gating issue: the package almost certainly targets PHP 7.x and Laravel 5/6/7-era conventions, and likely depends on the abandoned fzaninotto/faker rather than fakerphp/faker. On any modern Laravel stack that means a fork-and-patch before it will even install — which changes this from "add a dependency" to "own a fork."

Technical risk. High, and mostly non-technical in nature:

• Abandonment. Last release July 2020, single maintainer, 140 stars. No security response, no PHP 8/9/10 compatibility, no framework tracking.
• Licensing. NOASSERTION is a hard stop for most enterprises. Legal cannot approve an unclassified licence for a package that is designed to destroy data irreversibly. This alone likely disqualifies direct adoption.
• Irreversibility. Anonymisation is destructive by design. A misconfigured mapping, a wrong environment, or a partially failed run leaves production data unrecoverable — the failure mode is worse than the problem it solves.
• Silent staleness. When a new PII column is added and the config is not updated, the tool reports success while leaving data exposed. There is no schema-drift detection or coverage assertion.
• Low maturity signals. The 1.41 score and 1.14 opportunity indicate the ecosystem does not see this as a gap worth filling — a signal to borrow the pattern, not the artefact.

Key questions for the maintainer/team.

1. Which PHP and Laravel versions are actually supported, and which Faker package is required?
2. Is the licence clarified anywhere (README, issue tracker) beyond the NOASSERTION metadata?
3. Are writes transactional, chunked, or batched? What happens on mid-run failure?
4. Does it handle foreign keys, relations, and cascading de-anonymisation, or does it break referential integrity?
5. Is there a dry-run / diff mode, and is there any audit log of what was changed?
6. Does it support deterministic (seeded) output so staging datasets remain stable across refreshes?
7. Is there test coverage, and does it include tests for FK-constrained schemas?

Integration Approach

Stack fit. Good for the staging/dev data refresh use case: nightly or on-demand scrubbing of a production clone before it lands in a lower environment. Poor for production data subject erasure, where you need targeted, auditable, reversible-until-verified redaction with a legal record. Treat those as two distinct use cases and only pursue the first with this tool.

Migration path. Given the age and licence, the pragmatic route is vendor or fork, not depend:

1. Copy the source into an internal namespace (App\Support\Anonymisation) rather than pulling it via Composer. This sidesteps the licence ambiguity, the stale constraints, and the supply-chain risk in one step.
2. Replace the Faker dependency with fakerphp/faker, update the config-publishing and command signatures to current Laravel conventions.
3. Add the missing safety rails: --dry-run, --chunk, transaction-per-chunk, a confirmation prompt bound to the environment name, and a post-run coverage report.
4. Reimplement the config loader against your own PII catalogue so the mapping is generated, not hand-maintained.

If the package is only ~a few hundred lines, this is a day or two of work — cheaper than the legal and upgrade review required to depend on it directly.

Compatibility. Assume PHP 7.2–7.4 and Laravel 6/7 as the working envelope. On Laravel 9+ expect: Faker namespace breakage, deprecated console command signatures, and possible config-merge API changes. Verify against your actual composer.json constraints with a throwaway branch before committing to any plan. Do not attempt to run it against a framework version it predates without a test harness.

Sequencing.

1. Discovery — PII inventory and data classification across candidate models; confirm scope is non-production only.
2. Spike — fork into a branch, patch for current PHP/Laravel, run against a disposable database seeded with synthetic PII.
3. Safety layer — dry-run, chunking, environment guard, audit log, coverage assertion.
4. Pipeline — wire into the staging refresh job, not into an interactive developer workflow.
5. Review — DPO/legal sign-off on the fork's provenance and on the irreversibility controls before any production-adjacent use.
6. Defer production DSR workflows to a dedicated, auditable tool.

Operational Impact

Maintenance. Upstream is effectively frozen, so maintenance transfers entirely to your team on day one. Budget for framework-upgrade drift, Faker API changes, and schema-evolution review each time a migration adds a column. The recurring cost is not code maintenance — it is the config curation that keeps the PII map truthful. Assign explicit ownership; an unowned anonymisation config rots into a false sense of compliance.

Support. No vendor, no SLA, single maintainer, community-only. Internal escalation path must be "we own the fork." Document the fork point and divergence so future engineers understand why it is vendored.

Scaling. Eloquent-level row mutation with no visible chunking is the concern. On tables in the millions of rows expect long-running transactions, lock contention, replication lag on the source, and memory pressure from hydrated models. Mitigations: force chunked update() statements, run off-peak, disable model events, and prefer raw updates for large tables. For anything above low millions of rows, this design will need rework rather than tuning.

Failure modes.

• Partial run — process dies mid-table, leaving a mix of real and synthetic data with no rollback. Mitigate with per-chunk transactions plus a resumable checkpoint.
• Wrong environment — the command has no inherent guard against running against production. Mandatory environment allow-list is non-negotiable.
• Schema drift — new PII columns silently excluded, producing a clean-looking but non-compliant dataset.
• Referential breakage — anonymising a foreign key without its parent/child set violates constraints or orphans records.
• Irreversible mistake — a bad mapping destroys data; there is no undo, only restore-from-backup.
• Non-determinism — random output breaks relationships between related records unless the same seed/formatter is applied consistently, which the tool does not enforce.

Ramp-up. Developer ramp-up is low — an hour to read the config and run the command. Organisational ramp-up is the real cost: data classification, DPO review, licence/provenance review, pipeline integration, and an incident runbook for "the scrubber ran somewhere it shouldn't have." Expect the governance work to dominate the engineering work by an order of magnitude.

TPM recommendation. Do not adopt as a dependency. The low opportunity score, stale release, unclear licence, and irreversible failure mode make the risk asymmetric against a modest convenience gain. Use it as a reference implementation: lift the config-driven mapping pattern, harden it with dry-run, chunking, environment guards, and audit logging, and own the result internally. Reserve the production data-subject-request path for a purpose-built, auditable tool with real vendor backing.