Database Migrations Laravel Package

Product Decisions This Supports

• Migration authoring strategy. Choosing whether schema changes are owned by PHP developers via Laravel's schema builder or by DBAs/data engineers writing native SQL artifacts. This package enables the SQL-first option.
• Build vs. buy vs. skip. The capability is small enough to be an internal Artisan command. This package is a reference implementation, not a platform bet — the decision it informs is "do we want the SQL-first workflow at all," not "should we depend on this library."
• Roadmap items requiring complex DDL. Triggers, stored procedures, generated columns, table partitioning, full-text indexes, custom types/extensions, and materialized views are awkward or impossible in the schema builder and far safer as reviewed SQL.
• Portability and exit strategy. Plain .sql files are readable outside Laravel and replayable by Flyway, Liquibase, or Sqitch — relevant if a future decision involves migrating frameworks or handing schema management to a platform team.
• Auditability and regulated workflows. SQL files diff cleanly, survive code review by non-PHP reviewers, and can be attached to change-management tickets and DR runbooks.
• Onboarding and hiring. Widens the contributor pool for schema work beyond people fluent in Laravel's schema DSL.
• Decisions this does not support: standardizing on an actively maintained dependency, or any bet where the migration path needs an owner, SLA, or security response process.

When to Consider This Package

Consider the pattern (SQL files as migrations) only if most of these hold:

• A DBA or data engineer owns schema changes and won't work in PHP migration classes.
• The schema needs DDL that Laravel's builder handles poorly: procedures, triggers, partitions, extensions, non-trivial indexes.
• Migrations are reviewed as SQL, or must be exported to external tooling for audit/DR.
• The team accepts vendoring or forking whatever implements it.

Look elsewhere — or implement it internally — if:

• You're a conventional Laravel shop. DB::statement() inside a normal migration covers most raw-SQL needs with zero new dependency.
• Maintenance risk is unacceptable. One star and zero dependents is effectively no adoption signal: no security advisory process, no community support, no verified compatibility with current Laravel or PHP versions.
• You need reliable rollbacks, schema introspection, or driver parity across MySQL/Postgres/SQLite in CI. Plain SQL is per-dialect; the schema builder abstracts that away.
• You're on a long-lived or regulated product where every dependency needs an owner. An unmaintained package sitting on the deploy path — executing arbitrary privileged SQL — is a supply-chain concern, not just a code-quality one.

How to Pitch It (Stakeholders)

Executives. Do not add this package to production. It is a one-star, zero-dependent library with no maintenance signal, and it sits directly on the most privileged path in our release process — it runs arbitrary SQL against production databases. The idea it represents, SQL-first migrations, is worth a fraction of a day to validate; the dependency is not worth the tail risk. If the workflow proves valuable, we absorb roughly a hundred lines of our own code, which we can own, review, and patch.

Engineering. The package is a thin convenience layer: author migrations as plain .sql files instead of PHP classes. The real benefit is workflow, not code — DBAs write schema changes in their native language, complex DDL stops fighting the schema builder, and artifacts stay portable to Flyway/Liquibase later. The real cost is that we'd be trusting an unmaintained dependency to execute SQL against production, with unverified compatibility against our Laravel version and no upstream to escalate to. Recommended path: spike the pattern in a single migration to measure whether the DBA workflow gain is real. If it is, internalize it — a command that discovers and runs .sql files, with checksums and a ledger table, is small and testable. If someone insists on evaluating the package itself, cap the spike at one day, fork it under our org, pin the version, and name an owner before it reaches a shared environment.