Level 31
See here, it was discussed a week ago: https://laracasts.com/discuss/channels/general-discussion/seeders-or-migrations-for-production-data
1 like
Sep 5, 2025
8
Level 5
Populating DB Tables with static data?
Is there a recommendation or Laravel Way of populating the database with static data that your site needs to use? It doesn't come from a Model, but it's just static data the site needs. Things like maybe Categories, or available Tags (to pick when making a Post), or other data.
I think Seeders is the way, but I thought that was just for development, and not production
Level 5
@Glukinho oh perfect. Seems the general consensus is migrations for production data and seeders for test data
Level 31
@ctrlaltdelme some are against putting data in migrations, saying migrations are for database structure only. I personally share this opinion.
One reason can be: in migrations you operate on database level (tables and columns), while app data belongs to application level (models and fields along with app logic). It's wrong to mix them in one place.
1 like
Level 5
So you'd say static data for the database should go in seeders? Even for production?
Level 31
No, seeders are for fake data, while developing.
My answer is still there: https://laracasts.com/discuss/channels/general-discussion/seeders-or-migrations-for-production-data?reply=969937
Level 80
@ctrlaltdelme Do it as part of the migration:
public function up(): void
{
Schema::create('categories', function (Blueprint $table) {
$table->id();
$table->string('name')->unique();
$table->timestamps();
});
DB::table('categories')->insert([
['name' => 'Category 1'],
['name' => 'Category 2'],
// And so on...
]);
}
You can’t stop a migration run at an arbitrary point to go off and run some seeders, and then resume migrating, so it’s not going to work in automated environments such as CI and CD. Especially if any subsequent migrations rely on those records existing.
Level 41
I have to disagree with this approach.
First, design-wise, this is not Single Responsibility. Migrations should only involve altering the database structure. Data population is the responsibilities of seeders or some place else.
Second, if this approach regularly used over time, test cases and CI/CD will slow down drastically. Because obviously migrations is run for each test case. We did this before and felt the pain. We can always populate data in test cases using factories or the seed method.
My recommendations are still below.
Level 41
Although it is not highly recommended, you can still use seeders in whichever environment you like.
For a commercial project, I suggest using the laravel-deploy-operations package, which can populate data as part of deployment. It also keeps track of all the changes that have been made, just like migrations.
Please or to participate in this conversation.