SQLSTATE[HY000]: General error: 1364 Field 'id' doesn't have a default value in Laravel 6
Stefan Bogdanescu
Founder & Senior Architect · 2026-06-29
# Solving SQLSTATE[HY000]: Field 'id' doesn't have a default value in Laravel
As senior developers working with the Laravel ecosystem, we frequently encounter database errors that seem cryptic at first glance. The error `SQLSTATE[HY000]: General error: 1364 Field 'id' doesn't have a default value` is a classic symptom of a mismatch between how your Eloquent model expects data to be inserted and how the underlying database schema is configured.
This post will walk you through exactly why this error occurs in Laravel applications, especially when dealing with primary keys, and provide concrete solutions for fixing it.
## Understanding the Error: The Mismatch Between Eloquent and the Database
The error message originates from your database (likely MySQL or MariaDB) and indicates that when your application attempts an `INSERT` operation into the `stages` table, it is omitting a value for the primary key column named `id`, and this column has no defined default value to fall back on.
In Laravel, when you use methods like `Model::create([...])` or assign attributes directly to a model instance before saving (`$stage->save()`), Eloquent expects to handle the primary key automatically. This automatic handling relies heavily on specific configurations set within your database migration.
When you define a column as a primary key but do not specify auto-incrementing behavior (or a default value), the database engine refuses the insertion because it cannot determine what value to use for that critical field.
## Analyzing Your Code and Migration
Let's examine the components you provided:
**Your Migration:**
```php
$table->uuid('id')->primary();
// ... other fields
```
**Your Controller Logic (The point of failure):**
```php
$location= Stage::create([
'code' => $request->code,
'name' => $request->name,
'description' => $request->description
]);
```
The issue lies in the definition of the `id` column within your migration. While using UUIDs is a valid choice for distributed systems, when Laravel attempts to insert data without explicitly providing an `id`, it often defaults to expecting a standard auto-incrementing integer primary key, or requires specific functions to handle UUID generation correctly upon insertion.
## The Solution: Correcting Your Database Schema
The fix almost always involves ensuring your migration properly defines the primary key with automatic incrementation, which is the most common pattern for relational database design in Laravel applications.
### Option 1: Using Standard Auto-Incrementing IDs (Recommended)
For most standard Laravel projects, using an auto-incrementing unsigned big integer as the primary key is simpler and more performant than UUIDs unless you have a specific need for globally unique identifiers across multiple independent databases.
Modify your `CreateStagesTable` migration to use the standard Laravel convention:
```php
use Illuminate\Database\Migrations\Migration;
use Illuminate\Database\Schema\Blueprint;
use Illuminate\Support\Facades\Schema;
class CreateStagesTable extends Migration
{
public function up()
{
Schema::create('stages', function (Blueprint $table) {
// Use the standard auto-incrementing integer for the primary key
$table->id(); // This generates an auto-incrementing BIGINT primary key
$table->string('original_id', 36)->default('0')->index();
$table->string('code', 10)->index()->nullable();
$table->string('name', 100);
$table->string('description', 200)->nullable();
$table->char('created_by', 36)->index();
$table->char('edited_by', 36)->index()->nullable();
$table->timestamps();
// Foreign key constraints remain the same...
$table->foreign('created_by')->references('id')->on('users');
$table->foreign('edited_by')->references('id')->on('users');
});
}
public function down()
{
Schema::dropIfExists('stages');
}
}
```
By using `$table->id();`, you instruct the database to automatically manage the creation and incrementing of the `id` column, resolving the missing default value issue instantly. This aligns perfectly with best practices advocated by the [Laravel documentation](https://laravelcompany.com) regarding Eloquent models.
### Option 2: Fixing UUID Implementation (If UUID is Mandatory)
If you absolutely require UUIDs, you must ensure your database setup supports generating them upon insertion. If you are using MySQL, this often involves using a default function or ensuring the column definition explicitly handles defaults, though relying on Laravel's standard features often requires custom casting or middleware for complex UUID handling. For simplicity and compatibility within the framework, sticking to `$table->id()` is generally the most robust approach unless UUID generation is a core architectural requirement.
## Conclusion
The error `Field 'id' doesn't have a default value` is fundamentally a database schema issue exposed by an Eloquent operation. The solution is not in the controller or model logic, but in ensuring your migration correctly defines the primary key with auto-incrementing capabilities. By switching to Laravel's idiomatic `$table->id()` method, you ensure that your application and database work together seamlessly, adhering to the principles of clean, maintainable code that we strive for at [Laravel Company](https://laravelcompany.com). Always review your migrations before running them to prevent these common pitfalls!