How to Fix MySQL Error 1364: Field Doesn't Have a Default Value

ERROR 1364 (HY000): Field 'column_name' doesn't have a default value is raised when an INSERT statement omits a column that is defined as NOT NULL with no DEFAULT value, and MySQL's strict SQL mode is active. The error symbol is ER_NO_DEFAULT_FOR_FIELD.

Impact

The failing INSERT statement is rejected entirely — no row is written. In a multi-statement transaction, the transaction remains open but the current statement is rolled back, which can leave an application in an unexpected state if not handled explicitly.

Developers most commonly encounter this error after a schema migration adds a new NOT NULL column without a default, or when deploying application code against a MySQL instance where STRICT_TRANS_TABLES (or STRICT_ALL_TABLES) is enabled. ORMs such as ActiveRecord, Hibernate, and SQLAlchemy will surface this as a database exception — for example, ActiveRecord::StatementInvalid, org.hibernate.exception.GenericJDBCException, or sqlalchemy.exc.OperationalError — wrapping the underlying MySQL message.

Common Causes

A NOT NULL column with no DEFAULT was added to an existing table and the application's INSERT logic was not updated to supply a value for it. This is the most common cause after a schema change.
Strict SQL mode is enabled (STRICT_TRANS_TABLES or STRICT_ALL_TABLES in sql_mode). Without strict mode, MySQL would silently insert an implicit default (empty string, 0, or '0000-00-00'). With strict mode, the same statement raises error 1364 instead.
An ORM generates incomplete INSERT statements — for example, when a model object is saved without setting all required fields, the ORM may emit an INSERT that omits the column rather than passing NULL.
The column was recently altered (e.g., NOT NULL constraint added after the table existed, or the DEFAULT clause was dropped) without corresponding application changes.
MySQL 5.7+ default sql_mode includes STRICT_TRANS_TABLES, whereas MySQL 5.6 and earlier did not. Applications migrated from older MySQL versions may start seeing this error without any code changes.

Troubleshooting and Resolution Steps

Identify which column and table are involved.

The error message names the column directly. Confirm the column definition:
```
DESCRIBE your_table;
-- or
SHOW CREATE TABLE your_table\G
```
Look for a column with NOT NULL and no DEFAULT value listed.

Add a DEFAULT value to the column (recommended for most cases).

If a sensible default exists, add it to the schema:

ALTER TABLE your_table
  ALTER COLUMN status SET DEFAULT 'active';
-- or, to change type and default together:
ALTER TABLE your_table
  MODIFY COLUMN status VARCHAR(20) NOT NULL DEFAULT 'active';

Supply the value explicitly in the INSERT statement.

If no universal default makes sense, update the application to always provide the value:
```
INSERT INTO your_table (name, status, created_at)
VALUES ('example', 'active', NOW());
```
Allow NULL by dropping the NOT NULL constraint, if the business logic genuinely permits missing values:
```
ALTER TABLE your_table
  MODIFY COLUMN status VARCHAR(20) NULL;
```
After this change you can omit the column from INSERT statements and it will be stored as NULL.
Check the current sql_mode to understand whether strict mode is in effect:
```
SELECT @@sql_mode;
-- or per session:
SELECT @@SESSION.sql_mode;
```
If strict mode was recently enabled (e.g., after a MySQL upgrade or configuration change), review all INSERT statements that omit NOT NULL columns.
Disable strict mode as a temporary workaround (not recommended for production):

For a single session:
```
SET SESSION sql_mode = REPLACE(@@SESSION.sql_mode, 'STRICT_TRANS_TABLES', '');
```
In my.cnf / my.ini for a persistent change:
```
[mysqld]
sql_mode = "NO_ENGINE_SUBSTITUTION"
```
Without strict mode, MySQL substitutes an implicit default ('', 0, or '0000-00-00 00:00:00' depending on type) and raises a warning instead. This masks data quality problems and is generally not advisable.

Additional Information

Related warnings: Without strict mode, the same situation produces warning 1364 rather than an error. You can retrieve warnings with SHOW WARNINGS; immediately after the query.
Related error 1048: ER_BAD_NULL_ERROR (error 1048) is raised when a NULL value is explicitly inserted into a NOT NULL column. Error 1364 is distinct — it fires when the column is omitted entirely and has no default to fall back on.
MySQL 5.7 and later: STRICT_TRANS_TABLES is part of the default sql_mode, which is why applications that worked on MySQL 5.6 may fail on 5.7+ without any code change.
MySQL 8.0: The default sql_mode also includes NO_ZERO_IN_DATE, NO_ZERO_DATE, and ERROR_FOR_DIVISION_BY_ZERO — check the full mode string when troubleshooting mode-sensitive errors.
ORM behavior: Hibernate's @Column(nullable = false) and SQLAlchemy's nullable=False map to NOT NULL at the DDL level but do not automatically generate a server_default. Set server_default (SQLAlchemy) or columnDefinition (JPA) to avoid the error when columns are omitted from INSERT.

Frequently Asked Questions

Why did this error appear after upgrading MySQL from 5.6 to 5.7? MySQL 5.7 changed the default sql_mode to include STRICT_TRANS_TABLES. On 5.6, omitting a NOT NULL column with no default would silently insert an implicit value; on 5.7 it raises error 1364. The fix is either to add defaults to affected columns or to update application code to supply the values explicitly.

Can I just remove STRICT_TRANS_TABLES from sql_mode to fix this? You can, but it is not recommended. Strict mode protects data integrity by catching missing values at write time rather than silently storing empty strings or zeros. Disabling it means invalid data enters the database without error, which can cause harder-to-debug problems later. Prefer fixing the schema or the application instead.

The column has a DEFAULT in the schema, but I still get error 1364 — why? Double-check the actual column definition with SHOW CREATE TABLE. If the column was altered after the table was created, the DEFAULT clause may not have been preserved. Also verify that the session sql_mode matches what you expect — a connection pool may be connecting with a different mode than your manual session.

How do I find all NOT NULL columns without defaults in a database? Query information_schema:

SELECT table_name, column_name, column_type
FROM information_schema.columns
WHERE table_schema = 'your_database'
  AND is_nullable = 'NO'
  AND column_default IS NULL
  AND extra NOT LIKE '%auto_increment%';

This lists every column that could trigger error 1364 if omitted from an INSERT.