orangehill/iseed: generating Laravel seeders from an existing database

What iSeed is for, and who actually needs it

Laravel's seeding story runs in one direction by default: you write a seeder class by hand, then run it to populate a table. iSeed reverses that. It reads the current contents of a table and writes a new seeder file that would reproduce those rows. The package describes itself as an inverse seed generator, and that is the whole of its scope.

The people who need this are usually in one of three situations. Someone has built up a reference table by hand in a local database (countries, currencies, permission rows, a small product catalogue) and wants that data in version control without retyping it. Someone is moving a fixture set between environments and wants a file rather than a database dump. Someone has a test database that drifted from the seeders and wants to regenerate the seeders from what actually works.

It is not for large production tables. The command reads rows into memory and writes them into a PHP file, so the output size tracks the row count. The --max and --orderby options exist precisely because dumping everything is often the wrong move.

How the command turns table rows into PHP

The entry point is an Artisan command, iseed. The repository layout is conventional for a Laravel package: src/ holds the command and service provider, tests/ holds the test suite, and composer.json declares the package. The README documents the command surface in detail and says nothing about the internal implementation, so the mechanism below is what the documented options imply rather than a description of the source.

Given a table name, the command queries that table, applies any --exclude, --max, --orderby and --direction filters, and emits a seeder class whose class name is derived from the table name. Insert statements are batched according to --chunksize, which is the option that matters when the generated file would otherwise produce one enormous insert. The --database option is the interesting one: when you name a non-default connection, the generated seeder is documented to include a connection specification of the form \DB::connection('mysql2')->table(...), so the file targets the same database it was read from rather than whatever the default connection happens to be at run time.

Two options change the shape of the output rather than its content. --noindex generates the seed as a non-indexed array, and --clean empties database/seeders/DatabaseSeeder.php before writing the new class. The prerun and postrun options attach Laravel event names to the generated seeder: the README states that a prerun listener returning false fails the seed automatically, while a postrun listener returning false lets the seed run and then throws. Those are behavioural differences in the generated file, not in the generation step, and they are worth reading twice before relying on them.

Installing iSeed and generating your first seeder

Installation is a single Composer require. The README states the package supports Laravel 8 through 13 on PHP 8.0 and above, and that older Laravel versions need pinned releases: orangehill/iseed:2.2 for Laravel 5.3.7 and below, orangehill/iseed:1.1 for Laravel 4. On Laravel 5.4 and below you also register the service provider manually; later versions pick it up through package auto-discovery.

composer require orangehill/iseed

Once installed, run the command against a table. This example generates a seeder for a users table:

php artisan iseed users

The README says the output lands in Laravel's seeds directory as UsersTableSeeder.php. If a file with that name already exists, the command will not overwrite it unless you pass --force. That default is worth knowing before you assume a regeneration happened.

php artisan iseed users --force

For a table with columns you never want in a seeder, such as primary keys or timestamps, exclude them by name. Exclusion is applied to every table in the invocation when you list more than one.

php artisan iseed users --exclude=id,created_at,updated_at

If you only want a sample rather than the whole table, cap the row count and control the order the rows are read in. The README pairs --max with --orderby and --direction for exactly this case.

php artisan iseed users --max=10 --orderby=id --direction=desc

By default the command runs composer dump-autoload after generating the file. To skip that, pass --dumpauto=false. On a large or slow project this is the flag that keeps a batch of generations from triggering the autoloader repeatedly.

Where iSeed stops being the right tool

The most important limitation is structural: iSeed copies rows, not schema. It reads an existing table, which means the table must already exist in the target database before the generated seeder can do anything useful. If you are trying to bootstrap a fresh environment, iSeed does not help you create the table; migrations do that, and the seeder it generates assumes the table is there.

There is no documented rollback and no diffing. The command does not compare the generated file against the previous one, so the only guard against clobbering a hand-edited seeder is the default refusal to overwrite, which --force removes. If your team edits generated seeders after generation (adding comments, reordering, splitting the file), regeneration is a destructive operation and the README offers no merge strategy.

Secrets are the second failure mode. A users table read in full will carry password hashes, API tokens, email addresses and whatever else lives in those columns. The --exclude option is the only mechanism the documentation describes for removing them, and it is opt-in: nothing in the README suggests iSeed detects sensitive columns or warns about them. Running php artisan iseed users with no exclusions on a database that holds real accounts produces a file containing those accounts.

Finally, the generated seeder is a PHP file with the row data inlined. Very large tables produce very large files, and while --chunksize controls how the inserts are batched at execution time, it does not shrink the file. For anything approaching production scale, a database dump or a dedicated anonymisation step is the better answer.

iSeed against Laravel's own db:seed and against a SQL dump

The natural comparison is with Laravel's built-in seeding workflow. A hand-written seeder and an iSeed-generated seeder are the same kind of artifact: both are classes under database/seeders that you run with php artisan db:seed. The difference is authorship. A hand-written seeder expresses intent, is small, and survives schema changes because you update it deliberately. An iSeed-generated seeder expresses current state, is as large as the data, and goes stale the moment the table changes. Teams that treat generated seeders as throwaway fixtures get value from iSeed; teams that treat them as source of truth end up maintaining a large file that no one wants to edit.

The second comparison is with a plain SQL dump. A dump preserves schema and data together and is the standard way to move a database between machines. iSeed deliberately does neither: it produces a Laravel-native artifact that runs through the framework's connection handling, which is why the --database option exists and why the generated file can reference a named connection. If your goal is to reproduce a database, use a dump. If your goal is to have a runnable, reviewable seeder class inside the Laravel application, iSeed is aimed at that.

A third, less obvious alternative is to write a small custom Artisan command that queries the table and writes the file yourself. That is more work, but it lets you add anonymisation, column whitelisting and formatting rules that iSeed's option set does not cover.

Maintenance, version compatibility and the licence

The repository is not archived, and the last push was on 2026-06-24. Recent releases track Laravel and PHP compatibility rather than new features: v3.8.0 is labelled as Laravel 13.x compatibility and v3.7.2 as a PHP 8.4 compatibility fix, while v3.8.1 fixes a fatal error in the --prerun and --postrun event hooks. That pattern tells you what to expect from upgrading: the maintainers appear to keep pace with framework releases, and the changelog is the place to check before bumping Laravel.

The upgrade cost is mostly on the Laravel side. Because the package follows Laravel major versions, a Laravel upgrade usually means a corresponding iSeed upgrade, and the README's version table (2.2 for Laravel 5.3.7 and below, 1.1 for Laravel 4) shows that older framework versions are supported through pinned releases rather than the current one. If you are on an old Laravel, you are on an old iSeed.

The licence is BSD-2-Clause, which is permissive and short. It permits use and redistribution with the copyright notice and disclaimer retained; it does not carry the patent grant that some other permissive licences include. Whether that matters for your organisation is a question for your own review process, not something this article can settle.

Editorial conclusion

Adopt iSeed when you need to move a working dataset out of a development or staging database into a seeder file, and you want the column list, chunk size and ordering under your control. Do not adopt it as a migration or schema tool: it copies rows, not table structure, and the README documents no rollback, no diffing and no schema awareness. Before committing generated files, check the --exclude output for columns you meant to drop, confirm the connection named in --database is the one you expect, and open the generated seeder to see whether --noindex or the default indexed array is what your downstream code needs.

Frequently asked questions

Official sources

1. Issues
2. License: BSD-2-Clause
3. orangehill/iseed on GitHub
4. README
5. Releases