Danpu Laravel Package

Technical Evaluation

Architecture fit

• rah/danpu is a framework-agnostic, pure-PHP MySQL dump library (namespace Rah\Danpu), not a Laravel package. There is no service provider, facade, config publish, or contract binding — it is an infrastructure primitive you would wrap yourself.
• Its design center is the right one for a TPM to care about: it streams schema + data to a file handle rather than building the dump in memory, which makes it viable in memory-constrained PHP-FPM/queue-worker contexts where naive SELECT * + implode approaches fail.
• Because it speaks PDO and takes a DSN/credentials object, it can target the same connection config as Laravel's database.connections.mysql with a thin adapter — low conceptual distance from our existing stack.
• It is a substitute for the mysqldump binary, not for a backup platform. It handles dump generation and (basic) import; it does not handle scheduling, retention, offsite storage, encryption, or restore verification. Those remain ours.

Integration feasibility

• Composer-installable, MIT, single dependency surface. A spike is realistically 1–2 days: wrap Rah\Danpu\Dump config, expose an Export call from an artisan command or queued job.
• The friction is not installation, it is that we must write the Laravel glue ourselves: config object, service binding, exception mapping, logging, and a filesystem/disk abstraction (the library writes to a local path, not to Laravel's Storage disks — we would need a temp-file-then-move pattern to reach S3 or similar).
• Viability hinges almost entirely on the "no shell access" scenario. If our runtime can exec mysqldump, the mature path is spatie/db-dumper or spatie/laravel-db-snapshots; Danpu only wins where the binary is unavailable (managed container images, restricted shared hosting, hardened PaaS) or where binary version drift is a support burden.

Technical risk

• Staleness is the dominant risk. Last release 2018-11-06, pre-dating PHP 7.4 typed properties and the PHP 8.x line. PHP 8 compatibility is unverified: expect deprecation noise at minimum (implicit nullable params, dynamic properties, string-offset syntax, implode argument order) and possible fatals. This must be proven on our exact PHP version before any commitment.
• Adoption signal is weak. 62 stars, 0 dependents, effectively single-maintainer, no visible CI matrix. There is no realistic expectation of upstream security patches. The opportunity score (~23) reinforces that this is not a strategic dependency.
• Correctness surface is asymmetric. A dump library that is subtly wrong is worse than one that is absent: a dump that silently omits a table, truncates a BLOB, or mangles a DEFINER/DELIMITER block is discovered only at restore time — the worst possible moment. Import-side SQL parsing (statement splitting) is historically the fragile part of this class of library.
• Consistency semantics must be verified, not assumed. Whether the export wraps reads in a consistent snapshot / --single-transaction-equivalent for InnoDB is a question we must answer from source, not docs. If it does not, dumps of a live write-heavy database will be internally inconsistent.
• Mitigating factor: MIT + small codebase + zero dependents means we can fork and vendor it. The realistic posture is "adopt as source we own," not "adopt as a maintained upstream."

Key questions

1. Does our production runtime allow exec('mysqldump')? If yes, this entire evaluation is moot and we should use the standard wrapper.
2. Does Danpu run clean on PHP 8.2/8.3 with error_reporting(E_ALL) — fatal-free, not merely deprecation-free?
3. Does the export guarantee a consistent snapshot for InnoDB, and how does it behave for MyISAM/--lock-tables equivalents?
4. How does it handle views, triggers, stored procedures, DEFINER clauses, generated columns, and non-UTF8MB4 charsets?
5. Are we willing to own a fork (patch budget, security response) rather than depend on a 2018 release?

Integration Approach

Stack fit

• Fits Laravel/PHP as an infrastructural library behind our own interface — e.g. DatabaseDumper contract with a DanpuDumper implementation — so it stays swappable for spatie/db-dumper later without touching call sites.
• Map config('database.connections.mysql') into Rah\Danpu\Dump (->host(), ->port(), ->dbname(), ->user(), ->password(), ->file(), ->tmpDir(), plus include/ignore table filters). Keep this adapter the only place that knows Danpu exists.
• Do not attempt to reach S3/SFTP directly from the library. Write to storage/app/backups (or a tmp dir) via tmpDir, then hand off the finished artifact to our existing filesystem/Storage layer for promotion, retention, and offsite copy.

Migration path

• Only migrate if a shell-out exists today and is genuinely a problem. Recommended cutover: run both dumps on a staging database, diff the resulting SQL semantically (table list, row counts, checksums on a sample of tables, schema diff), and only then flip the config flag.
• Keep the shell-out path behind the same DatabaseDumper interface so rollback is a one-line config change.

Compatibility

• Pin the dependency explicitly (rah/danpu), and pin a known-good PHP version range in the wrapper's tests. Run the CI matrix against every PHP minor we ship.
• Verify PDO extension assumptions (it requires pdo_mysql), zlib for compressed output, and available disk in tmpDir for the compression path.
• Verify behavior against MySQL 8 (caching_sha2_password auth, utf8mb4_0900_ai_ci collations, information_schema differences) and, if applicable, MariaDB — this is a likely source of silent breakage given the library's 2018 vintage.

Sequencing

1. One-week spike on a non-production clone: export/import round-trip, verify row counts and schema equality.
2. Build the adapter + contract, no behavior change in production.
3. Shadow-run against staging on a schedule; compare artifacts.
4. Flip the default only after a successful restore drill.
5. Establish the fork policy and patch cadence before step 4, not after.

Operational Impact

Maintenance

• Assume we own this code. Budget a fork in our VCS with a documented patch set (PHP 8 fixes, any MySQL 8 fixes, our logging hooks). Review upstream quarterly but expect nothing.
• Because it is a backup-path dependency, it should be covered by the same change-control and post-deploy verification as the database itself — not treated as a routine composer update.
• Low line-count and zero transitive dependents keep ongoing maintenance cost low; the cost is episodic (PHP upgrades, MySQL upgrades) rather than continuous.

Support

• No vendor, no maintainer SLA, no security advisory channel. Our support story is "internal owner + fork." Assign a named owner; this cannot be an unowned transitive dependency.
• Document the exact known-good PHP/MySQL matrix in-repo so future upgrades don't re-litigate it.

Scaling

• Streaming design is the main plus: memory use should stay roughly flat with database size, which is what allows this to run in a standard worker rather than a fat sidecar.
• Expect the limits to be disk, not memory: dump size, tmpDir headroom for compression, and the destination filesystem. Large databases (tens of GB) will need disk capacity planning and a cleanup contract for partial artifacts.
• No parallelism, no incremental/differential support, no resume. Wall-clock time scales with data size and will contend with production I/O unless run against a replica — plan to point it at a read replica and size the maintenance window accordingly.

Failure modes

• Silent partial dump: process dies mid-write, artifact looks plausible, restore is incomplete. Mitigate with write-to-temp + atomic rename + post-export row-count assertions against information_schema and an explicit "dump complete" trailer check.
• Inconsistent snapshot: concurrent writes produce a referentially broken dump. Mitigate by verifying/forcing transactional consistency, or by dumping from a replica.
• Import parser failures: statement-splitting on DELIMITER blocks, stored routines, triggers, or binary/BLOB payloads. Mitigate by excluding routines/triggers from Danpu's scope and managing them via migrations, and by requiring a successful restore drill as acceptance.
• PHP-version regression: a minor PHP upgrade introduces a fatal in the export path — discovered when the backup silently stops running. Mitigate with a canary scheduled job that dumps a small fixture database daily and alerts on failure or artifact-size deviation.
• Disk exhaustion in tmpDir: compression temp files fill the volume and take down other workloads. Mitigate with quota/size guards and pre-flight capacity checks.
• Silent no-op on schema drift: a new table excluded by an ignore rule or missed by information_schema handling. Mitigate with a table-count assertion comparing source and dump.

Ramp-up

• Low for any mid-level Laravel engineer: the API is a small set of setter methods around Export/Import, and a working prototype is hours, not days. The real ramp-up cost is not the library — it is building the surrounding discipline (restore drills, canary backups, artifact verification) that any backup mechanism requires.
• Because there is no documentation depth or community to consult, institutional knowledge lives entirely with the person who writes the adapter. Require that adapter to be tested and reviewed like production code, not a throwaway script.

Bottom line for the TPM: technically sound design for a narrow constraint (no mysqldump binary), but a stale, single-maintainer, zero-adoption dependency that we would effectively own. Adopt only behind a swappable interface, with a fork policy, a canary backup, and a proven restore drill — otherwise use the standard db-dumper / db-snapshots path.