Database Laravel Package

Product Decisions This Supports

• Build vs. buy for environment tooling. This is a thin wrapper (Composer package, MIT) around the MySQL CLI/mysqldump that exposes Artisan commands for creating, backing up, restoring, and dropping databases. The PM decision it informs is narrow and concrete: do we spend engineering days building internal dev-ops scripts, or vendor ~a few hundred lines of someone else's?
• Developer onboarding as a roadmap item. If "new engineer gets a working local environment" currently takes a documented checklist plus a Slack thread to a senior dev, commands like db:create / db:restore collapse that into a composer setup script. This is a candidate to de-scope from the product roadmap and solve with tooling instead.
• CI/CD and preview-environment scope. Ephemeral per-branch databases (create → migrate → seed → test → drop) are a use case this enables cheaply. That affects whether "preview environments" is a Q2 initiative or a one-sprint chore.
• Test infrastructure strategy. Faster, scriptable reset/restore of fixtures versus hand-maintained SQL dumps and manual DB setup in pipelines.
• Demo and handoff workflows. Snapshot/restore commands make customer demos, sandbox resets, and contractor handoffs repeatable rather than bespoke.
• Explicit "not this" decision. The package is MySQL-only, shell-dependent, and backup-basic. Evaluating it forces the team to state clearly that production backup/DR is a separate, funded concern — not something we accidentally rely on a 4-star package for.

When to Consider This Package

Adopt (or copy the pattern) when all of the following hold:

• The stack is Laravel + MySQL/MariaDB, single database engine, no plans to add Postgres in the next two quarters.
• Scope is local development, CI, or internal tooling — never a system of record for customer data.
• The runtime has mysql/mysqldump binaries on PATH and shell execution isn't blocked (rules out many hardened containers, some shared hosts, and Windows-heavy teams without WSL).
• The team can accept an effectively unmaintained dependency (4 stars, 0 dependents, low opportunity score). Treat it as a vendored snippet you may need to fork, not a strategic dependency — pin the version and assume you own it.
• No compliance requirement (SOC 2, PCI, HIPAA) touches the backup path — there is no encryption, no offsite upload, no retention policy, no audit trail here.

Look elsewhere when:

• You need production backups, PITR, encryption, retention, or restore verification — use managed provider snapshots (RDS/Cloud SQL) or spatie/laravel-backup with offsite storage and monitoring.
• You need multi-engine support, or the app is Postgres-first.
• Security review requires a maintained dependency with an active maintainer, CVE response, and clear ownership.
• Laravel's built-ins already cover you: db:wipe, migrate:fresh, and schema:dump handle most reset/seed flows without a third-party package. Check for overlap before adding a dependency.
• Your environment is containerized with no DB client binaries — a docker compose exec wrapper or a Makefile target solves it with less risk.

How to Pitch It (Stakeholders)

Executives: This is a free, MIT-licensed utility that removes a recurring manual step from developer setup and CI. It costs nothing, adds no vendor relationship, and its blast radius is confined to developer laptops and pipelines — it never touches production data. Expected value is measured in onboarding hours and avoided environment-support tickets, not revenue. Two caveats to state up front: it is a small, low-adoption package, so we should pin the version and expect to own it if the maintainer stops; and it is explicitly not our disaster-recovery story. If we need real backups, that is a separate, funded decision — please don't let this package become the implicit answer.

Engineering: Low-risk Composer install with Artisan commands for create/backup/restore/drop against MySQL. Wire it into composer setup and the CI pipeline; keep it behind dev/CI config so it can't be invoked against production credentials. Before adopting, diff it against db:wipe + schema:dump + migrate:fresh — if those already cover the workflow, we skip the dependency. If they don't, adopt it and budget a day to fork-and-own it if maintenance stalls.