- How do I install and configure dragon-code/migrate-db in a Laravel application?
- Install it with Composer, publish the package config file, and declare both the source and target connections in config/database.php. You then map the Eloquent models or tables you want to transfer and run the package's Artisan commands. There are no services, daemons, or external storage to set up, so a staging proof of concept is usually a one-day job.
- Does this package migrate the database schema as well as the data?
- No. It moves rows, not DDL, so tables, indexes, constraints, and column definitions must already exist on the target database. Manage the schema with Laravel migrations or your native tooling first, then use this package to copy records across. Treating it as a schema tool is a common misuse and will lead to failures.
- Which database engines can I transfer data between?
- Any combination supported by Laravel's database connections, including MySQL, PostgreSQL, SQLite, and SQL Server. The package reads through Eloquent on one connection and re-inserts through a second connection. Cross-engine moves such as MySQL to PostgreSQL work but require an explicit audit of column type mapping.
- Is dragon-code/migrate-db still maintained?
- The repository is archived, and the last release landed shortly before archival, which suggests a final compatible version rather than an actively developed project. It is a single-maintainer package with a modest adoption footprint and no dependents, so there is effectively no downstream validation surface. If you adopt it, plan to fork, vendor, or mirror the pinned version internally so a future Packagist or GitHub removal cannot break your run.
- Which Laravel and PHP versions does the final release support?
- Check the final release's composer.json constraints on Packagist before anything else, because an archived package will never gain support for newer PHP or Laravel majors. Pin both laravel/framework and this package in composer.json and validate the pair in CI. If your target is a recent Laravel version or PHP 8.4+, verify compatibility explicitly rather than assuming it.
- Can I re-run the transfer without duplicating rows or hitting primary key conflicts?
- Do not assume the transfer is idempotent. Repeated runs can duplicate rows or fail on primary-key and unique-index conflicts, particularly with auto-increment or UUID keys. Decide up front whether you will truncate the target between runs or implement a key strategy, and test a second run in staging before relying on it.
- How does it handle foreign keys and insert order?
- Because the transfer is driven by Eloquent models, relationship ordering can be respected if you declare the order correctly in your mapping. It does not infer your foreign key graph for you, so tables with dependencies need an explicit sequence. Verify constraint behavior on the target and confirm ordering with a full staging run.
- Will it run out of memory on large tables?
- That depends on whether the package chunks and streams results or hydrates full result sets, which you should confirm in the source before committing. Measure wall-clock time and peak memory per table against your largest dataset in staging rather than extrapolating from small tables. If memory is a problem, transfer large tables in smaller mapped batches.
- Can I migrate MySQL data to PostgreSQL when tables contain JSON, ENUM, binary, or timezone columns?
- It can work, but these are exactly the types that do not round-trip cleanly between engines. Eloquent casts and attribute mutators help, yet you should audit every flagged column and spot-check the loaded values. Generated columns, ENUM handling, and timezone-bearing timestamps deserve particular attention before a production cutover.
- What are the alternatives if I just need a same-engine copy?
- For same-engine moves, native tooling such as mysqldump and pg_restore is faster, simpler, and better validated than a model-driven transfer. This package earns its place mainly when source and target engines differ and you want Eloquent casts and relationships respected. In a non-Laravel or polyglot estate, the value proposition largely disappears and native utilities win.