Db Migration Laravel Package

Product Decisions This Supports

• Build vs. buy for database change management: 2.2.0 makes the package a stronger "buy/adopt" candidate over in-house migration scripts. Multi-database history, baseline marking, and transactional toggles cover the operational edge cases that usually justify custom tooling.
• Multi-tenant / sharded roadmap: Named databases with independent migration histories and a --db selector directly enable per-tenant or per-shard schema evolution — a concrete enabler for scaling decisions rather than a rewrite.
• Production onboarding & baselining: migrate:mark lets teams adopt the tool against an already-live schema by stamping the current version without re-running migrations. This lowers the adoption cost for brownfield products and reduces migration-window risk.
• Release safety / DDL policy: Configurable transaction mode plus --transactional / --no-transactional lets PMs set an explicit data-safety posture per environment (e.g., non-transactional for implicit-commit engines like MySQL DDL), reducing "half-applied migration" incidents.
• Support and onboarding cost: Friendlier errors when the config file is missing removes a common first-run failure, improving developer self-serve and reducing ops escalations.

When to Consider This Package

Consider adopting when:

• You are on a PHP stack (Yii ecosystem in particular) and need programmatic, versioned migrations with multi-database support.
• You run multi-tenant, sharded, or multi-schema architectures where each database needs its own migration history.
• You need to baseline an existing production database without replaying history (migrate:mark).
• You want explicit control over transactional vs. non-transactional migration execution.

Look elsewhere when:

• You are Laravel-native and have no Yii footprint — Laravel's built-in migrations already provide most of this with tighter framework integration and less operational overhead.
• You need broad ORM/engine coverage across frameworks (evaluate Doctrine Migrations or Phinx).
• Your organization standardizes on a single migration tool across polyglot services; a framework-specific package raises the maintenance surface.

Caveat: 2.2.0 is additive — no breaking changes or deprecations identified — so incremental adoption is low-risk.

How to Pitch It (Stakeholders)

For executives: This release strengthens our database change-management story at effectively no migration cost. It adds multi-database support (directly relevant to our multi-tenant/scaling roadmap), a safe way to onboard existing production databases, and configurable transaction safety to reduce incident risk. The upgrade is backward compatible — additive features only — so it is a low-risk, low-effort improvement to operational reliability.

For engineering: Version 2.2.0 delivers three capabilities we have been working around: (1) named databases with separate migration histories and a --db selector — removes custom multi-tenant scripts; (2) migrate:mark — lets us baseline live schemas instead of hand-editing history tables; (3) configurable transaction mode with CLI overrides — gives us per-environment DDL safety policy. Plus a clearer first-run error. No breaking changes; upgrade and validate against our multi-DB environments. Recommendation: upgrade and pilot migrate:mark on a staging copy of an existing database before the next release train.