Laravel Migration Views Laravel Package

Product Decisions This Supports

• Where the reporting/aggregation layer lives. Treating "view vs. table vs. app-side query logic" as a versioned, reversible product decision rather than a DBA ticket or a hand-run SQL script. Because a view definition becomes just another migration, the decision can be made, reviewed, and unmade inside a sprint — which moves reporting features from one-way door to cheap experiment, and lets you say yes to a dashboard request without committing to a permanent schema artifact.
• Roadmap: framework upgrade readiness. v1.12 is a compatibility-only release adding Laravel 13 support — no new API, no deprecations, no remediation work. It is a checklist item cleared at near-zero cost, and it de-risks the Laravel 13 program on a dependency that sits directly in the deploy path.
• Build vs. buy. The alternatives are a homegrown CREATE VIEW helper, per-environment manual scripts, or leaving the logic in application code. This is a thin, MIT-licensed, single-purpose package that already handles cross-engine DDL plus rename/create-or-replace and rollback. Effort alone makes an in-house build hard to justify, and exit cost is low because view migrations are plain SQL that can be reproduced with DB::statement.
• Use cases it unlocks or de-risks: BI tool connections that expect stable, named relations; denormalized read models for dashboards and exports; compatibility shims over legacy tables during a schema refactor; a single reporting contract shared by several Eloquent models so the definition cannot drift between them.
• Environment parity and onboarding. Views ship with php artisan migrate, so a fresh environment, a CI run, or a new engineer gets the same read models as production with no runbook step and no staging-vs-prod drift.
• Schema drift becomes a diff. A migration-managed view definition turns "why does prod's report differ from staging's?" into a code review rather than an investigation — a direct reduction in support load and a measurable win for the on-call rotation.
• Decision to make explicitly, not by default: whether materialized views are in scope. The package description lists only standard views, while internal assessment material references PostgreSQL-only materialized-view macros with manual refresh. If refresh lifecycle is on the roadmap, that is a separate design with a separate owner — settle it before scoping any dashboarding item, not after.

When to Consider This Package

Adopt when:

• Reporting or aggregation SQL is already depended on by multiple consumers and currently lives in wiki pages, BI tool configs, or one person's memory.
• You want views versioned, reviewable, and rollback-able alongside the tables they read from, in the same deploy pipeline.
• You are on Laravel with MySQL, PostgreSQL, SQLite, or SQL Server and are on — or planning — a current major; v1.12 explicitly covers Laravel 13.
• Migrations are already your team's uncontested source of truth for schema, so views are a natural extension rather than a second governance path.
• The views are long-lived and shared: the ceremony of one migration file is repaid the first time a report definition changes and someone has to prove what changed.

Look elsewhere when:

• Your DBA or platform team owns schema changes through separate tooling; a second migration path creates governance conflict rather than removing it.
• You need warehouse-grade view lifecycle — refresh scheduling, incremental materialization, partition awareness. The documented core is plain views across four engines; any materialized-view support is PostgreSQL-specific with a manual refresh story that becomes your problem, not the package's.
• You need heavily vendor-specific view SQL (window functions, dialect hints, index hints) tuned per database. The package generates DDL; it does not abstract the SQL, but the abstraction can obscure which dialect you are actually targeting.
• Views are throwaway or single-consumer; a migration file is overkill for a query only one endpoint reads.
• You are not on Laravel — there is no value outside the migration system.
• Your support policy requires a vendor with an SLA. This is a 226-star, single-maintainer community package with zero dependents — a real consideration for a dependency in the critical deploy path, though blast radius is contained because views are additive and droppable. Zero dependents is a discoverability signal, not a quality signal, but it does mean no ecosystem pressure keeps it maintained.

How to Pitch It (Stakeholders)

For executives: This is a small, actively maintained open-source dependency that moves our reporting and read-model definitions out of tribal knowledge and into the same versioned, reviewed, tested pipeline as the rest of our database schema. The practical payoff is fewer production-vs-staging surprises, no manual SQL step during deploys, and a clean audit trail of who changed which report logic and when. The v1.12 release adds Laravel 13 support with no breaking changes and no new surface area — a maintenance signal that keeps our framework upgrade unblocked, not a reason to replatform. Cost is negligible and risk is low because views are additive and reversible; the worst case is dropping a view and falling back to the prior query pattern. Fund it as a hygiene line item, not a roadmap initiative — it removes friction rather than opening new product surface.

For engineering: v1.12 is compatibility-only — Laravel 13 support, no API changes, no deprecations, nothing to remediate. It is a thin wrapper that emits CREATE VIEW / DROP VIEW (plus rename and create-or-replace) through Laravel's schema builder, so a view definition is just a migration: standard up/down, standard rollback, standard code review, supported across MySQL, PostgreSQL, SQLite, and SQL Server. Adoption is a Composer require plus one migration file; no config to publish, service provider auto-discovered. Scope it honestly: it manages plain views; materialized views, if present at all, are PostgreSQL-only with manual refresh and uneven behavior in a SQLite test suite, so scheduled refreshes are a separate design decision — flag that early. Four conventions make or break it: one migration per view ordered after its dependencies; always pair up() with a matching down() so rollbacks don't leave orphaned views silently shadowing table names on the next deploy; avoid select * in view definitions so base-table changes fail loudly at migration time; and treat view column names as a stable public contract, since CREATE OR REPLACE VIEW cannot change a column list on PostgreSQL without drop-and-recreate plus re-granting permissions. Recommend we adopt it for the reporting layer, land one representative view migration plus a rollback test in CI, verify schema dump/restore round-trips the view, and mark Laravel 13 cleared against this dependency.