Laravel Pk Int To Bigint Laravel Package

Technical Evaluation

Architecture fit The package is a development-time schema tooling utility, not a runtime dependency. It fits cleanly into a Laravel codebase as a require-dev Composer package that generates or executes migrations to widen INT primary keys and their referencing foreign keys to BIGINT. Architecturally it touches the persistence layer only (migrations, schema), with no impact on application code, service providers, or request lifecycle — the lowest-risk integration surface a package of this kind can have. It is best understood as a one-shot remediation tool for legacy schemas built before Laravel defaulted to bigIncrements/id(), not as something you run continuously.

Integration feasibility Installation and first run are trivial (composer require --dev, artisan command). The real feasibility question is whether the generated migrations are correct for your specific schema. Because FK columns must remain type-identical to the columns they reference (InnoDB enforces this), the tool must drop and recreate every FK in the correct order across all tables — this is where edge cases live: composite keys, polymorphic *_type/*_id morph pairs, pivot tables, and cross-database references. Feasibility is high on a clean, conventional schema; it drops sharply on schemas with hand-rolled DDL, non-Laravel-managed tables, or unusual constraint naming.

Technical risk

• Adoption risk (primary): 19 stars and 0 dependents means effectively no production evidence base. Treat the package as a reference implementation to review and possibly vendor, not a trusted black box.
• Destructive-blast-radius risk: widening INT→BIGINT is lossless by itself, but a partial failure (FK dropped, column altered, FK re-add fails) leaves the schema in an inconsistent, half-migrated state. DDL is non-transactional on MySQL, so there is no automatic rollback.
• Driver risk: behavior differs materially across MySQL/MariaDB, PostgreSQL, and SQLite; SQLite requires table rebuilds. Confirm the supported driver matrix explicitly.
• Locking risk: on MySQL, changing a PK column type forces a table rebuild — it is not an online/in-place operation. On a large table this is the dominant risk, not the package's logic.

Key questions

• Which database drivers and versions are officially supported and tested?
• Does it discover and alter all referencing FK columns, including morphs and composite keys, or only those it can infer?
• Is the operation idempotent, and does it detect already-BIGINT columns?
• Does it support/expose ALGORITHM=INPLACE/online-DDL tooling (gh-ost, pt-online-schema-change), or is it plain ALTER TABLE?
• Laravel version matrix — does it rely on Doctrine DBAL for ->change(), or the native Laravel 11+ path?
• What is the maintainer's responsiveness and release cadence?

Integration Approach

Stack fit Fits any Laravel 8–12 project on MySQL/MariaDB (the common case for the increments() legacy pattern), assuming PHP 8.1+ and 64-bit PHP. It composes with the existing migration system rather than replacing it, and does not alter Eloquent behavior — int columns become bigint, both map to PHP int on 64-bit platforms. Flag the 32-bit PHP edge case: BIGINT values will overflow PHP_INT_MAX and silently degrade to float/string.

Migration path

1. Install as a dev dependency in a branch; do not merge to main until validated.
2. Run the package's discovery/scan command against a staging schema cloned from production (structure and realistic row counts, not a truncated copy).
3. Review every generated migration by hand — treat output as a draft PR, not a runnable artifact.
4. Dry-run on a production-sized copy and measure lock duration, binlog growth, and replica lag.
5. Execute in a coordinated maintenance window (or via online-DDL tooling) with a pre-migration snapshot.
6. Verify FK integrity, row counts, and application smoke tests post-run.

Compatibility Confirm the schema is fully managed by Laravel migrations before starting — any table created outside the migration system (legacy dump, manual DDL) will likely be missed or broken. Check that no code relies on column width assumptions (e.g., stored procedures, BI extracts, external consumers reading information_schema).

Sequencing Schema inventory → package evaluation/vendoring decision → staging generation and review → production-sized rehearsal → stakeholder sign-off and window scheduling → execute → verify → document new schema baseline. The package itself is step 2–3; the surrounding process is where the TPM's effort concentrates.

Operational Impact

Maintenance MIT-licensed and low-activity. Do not take a long-term runtime dependency on it: run it, then remove it. If the schema requires repeated remediation across environments, fork and vendor the migrations under your own control rather than pinning to an unmaintained package.

Support No vendor SLA. Support is GitHub issues from a single maintainer. Escalation path is "read the source and patch it yourself" — acceptable for a one-shot dev tool, unacceptable if treated as infrastructure.

Scaling This is precisely the scaling fix: it removes the ~2.1B-row signed INT ceiling before overflow causes primary-key exhaustion and write failures. The caveat is that the migration itself does not scale to very large tables without online-DDL tooling — plan the cutover around table size, not around the package.

Failure modes

• Table locked for hours on large tables; writes fail and requests time out.
• Replica lag / binlog bloat from a large ALTER.
• Partial migration leaves FKs missing — silent referential-integrity loss until a constraint violation surfaces.
• Rollback (down) is expensive and may not faithfully restore dropped constraints.
• Application errors during cutover if connection pools hold stale schema metadata.

Ramp-up Low. A mid-level Laravel engineer can install and run the tool in under an hour. The genuine effort — and where a TPM should staff — is schema review, staging rehearsal, and cutover coordination, not the package itself. Budget roughly one engineer-week for a mid-sized schema, dominated by review and verification rather than execution.