Danpu Laravel Package

Product Decisions This Supports

• Build vs. buy for a database export capability. Writing a correct MySQL dumper is deceptively expensive: identifier quoting, NULL vs 'NULL', binary/BLOB columns, charset and collation, AUTO_INCREMENT resets, views, triggers, routines, foreign-key ordering, and memory behavior on large tables. This package is a pure-PHP implementation of that, so the decision is roughly "adopt a small library" vs. "spend a sprint re-discovering edge cases." The library's narrow, single-responsibility surface makes the evaluation cheap.
• Feature: user- or admin-triggered data exports. Supports roadmap items like "Download my data" (GDPR/CCPA portability), tenant offboarding exports, and per-account snapshots — features that are almost always requested but rarely prioritized until a compliance or churn event forces them.
• Feature: scheduled backups without shell access. Because it runs in-process rather than shelling out to mysqldump, it unblocks backup features on restricted hosting/PaaS where exec() is disabled or the MySQL client binary isn't installed. This is a real segmentation decision: it expands where the product can be deployed, not just how.
• Operational tooling, not customer-facing differentiation. Pre-deployment snapshots, staging-to-local refreshes, and anonymized fixture generation for test environments. These are internal velocity wins; treat them as engineering-enablement spend rather than product roadmap.
• Roadmap signal: database portability. Choosing this package quietly commits the export path to MySQL. If multi-database support (PostgreSQL, MariaDB variants) is on the 12-month roadmap, this becomes a fork-in-the-road decision rather than a tactical utility pick.

When to Consider This Package

Adopt when:

• The data store is MySQL/MariaDB only, with no near-term plan to change.
• You need dump generation inside the PHP process — no shell, no mysqldump binary, no external agent.
• Your export volumes fit a streaming-to-file, memory-bounded model, and you can tolerate writing to local disk or a stream before shipping to object storage.
• You are comfortable vendoring or pinning a small dependency and patching it yourself. The last tagged release is from November 2018, so there is no expectation of upstream responsiveness, PHP 8.x regression fixes, or security triage.
• You want a small, auditable code surface over a heavier framework-bound backup package.

Look elsewhere when:

• You need non-MySQL engines, logical replication, binlog/PITR, or incremental backups — this is a full-dump tool, not a backup strategy.
• You need compliance-grade guarantees (encryption at rest, retention policy, restore verification, audit trail, SLA). Use managed snapshots (RDS/Cloud SQL) for the system of record and reserve this for user-facing exports.
• Your platform runs modern PHP with strict deprecation handling and you cannot absorb the maintenance of an unmaintained dependency.
• You want orchestration — scheduling, retention, upload, restore — which this does not provide; it only produces the dump payload. Pair it with a scheduler and storage layer, or pick a package that owns more of that flow.

How to Pitch It (Stakeholders)

To executives: This is a small, MIT-licensed utility that lets us ship "export my data" and pre-deploy backup features without building a database dump engine from scratch. It removes a multi-week engineering risk for a narrow, well-understood problem and works in our hosting constraints where shelling out to MySQL tooling is not an option. The trade-off is that it is a point tool, not a backup strategy — it does not give us retention, encryption, or restore guarantees, so it complements rather than replaces managed database snapshots. Cost is near zero; the main obligation is that we own the code if it breaks.

To engineering: Pure-PHP MySQL dumper, streaming and memory-conscious, no shell dependency. Single responsibility: write a SQL dump. Last release 2018 and effectively unmaintained, so we vendor it, pin the version, wrap it behind our own DatabaseExporter interface, and add integration tests against a real MySQL instance covering BLOBs, charset, views, and large-table memory behavior. If it degrades on a future PHP upgrade, the interface lets us swap in mysqldump or an alternative without touching product code. Expected effort: a day to integrate and test, not a sprint.