How to Fix MySQL Error 1049: Unknown Database

MySQL error 1049 surfaces with the message ERROR 1049 (42000): Unknown database '<name>'. The SQLSTATE is 42000 (Syntax Error or Access Rule Violation), the condition name is ER_BAD_DB_ERROR, and it means that MySQL could not find a database with the given name on the current server instance.

What This Error Means

MySQL stores databases as directories inside the data directory configured at server startup (datadir, typically /var/lib/mysql on Linux). When you issue a USE statement, specify a database in a connection string, or use a fully-qualified table reference like mydb.mytable, MySQL looks for a matching directory in that data directory. If no such directory exists, it raises error 1049 immediately — no query is executed.

SQLSTATE 42000 is the "syntax error or access violation" class shared by several MySQL errors. Error 1049 specifically falls on the "database not found" path rather than the permissions path: if the database exists but the connecting user lacks privileges, MySQL raises error 1044 (ER_DBACCESS_DENIED_ERROR) instead. This distinction matters when troubleshooting — 1049 always means the database is absent from the server's data directory, not that access was denied.

The error is raised before any transaction begins, so there is no transaction to roll back. A connection that encounters 1049 during initial database selection (e.g., from a connection string) is simply rejected. A connection that encounters it mid-session (via USE) remains open and the previously selected database, if any, stays in effect.

Common Causes

1. Typo in the database name. MySQL database names are case-sensitive on Linux (because they map directly to filesystem directory names) but case-insensitive on Windows and macOS. A name like MyApp_DB will not match myapp_db on a Linux server.

2. Wrong server or environment. The application is connecting to a development, staging, or replica server where the database has not been created, while the database only exists on a different host.

3. Database was dropped and not recreated. A DROP DATABASE was executed (possibly during a migration rollback or cleanup script) and the schema was never re-applied.

4. Database not yet created after a fresh install. The application schema migrations have not been run against a freshly provisioned MySQL instance, so the database directory does not yet exist.

5. Connection string references the wrong database. The dbname parameter in the JDBC URL, DATABASE_URL environment variable, or ORM config file was updated in one environment but not another.

6. Character set or encoding mismatch in the name. Rare, but database names containing non-ASCII characters can behave differently between client encodings and the filesystem, causing a lookup mismatch.

How to Fix ER_BAD_DB_ERROR

1. Verify the database exists on the target server.

   SHOW DATABASES LIKE 'myapp%';
   

   If the database is not listed, it does not exist on this server instance. Confirm you are connected to the correct host and port.

2. Check for case mismatches on Linux.

   SHOW DATABASES;
   

   Compare the output character-by-character against the name in your connection string. On Linux, Myapp and myapp are different databases.

3. Create the database if it is genuinely missing.

   CREATE DATABASE myapp CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci;
   

   Then run your application's schema migrations or seed scripts against the new database.

4. Correct the connection string or environment variable.

   For a typical connection string:

   mysql://appuser:password@db-host:3306/myapp
   

   Ensure the database component (myapp here) exactly matches the name returned by SHOW DATABASES. Update the relevant config file, .env file, or secret in your deployment environment.

5. Restore from backup or rerun migrations if the database was dropped.

   If the database was accidentally dropped, restore from the most recent backup:

   mysql -u root -p < myapp_backup.sql
   

   Or recreate the schema and restore data through your migration tooling (e.g., rails db:create db:migrate, flyway migrate, liquibase update).

6. Grant privileges after creation (if the database was newly created).

   Creating a database does not automatically grant the application user access:

   GRANT ALL PRIVILEGES ON myapp.* TO 'appuser'@'%';
   FLUSH PRIVILEGES;
   

Additional Information

• Error 1049 has been present since very early MySQL versions and its behavior has not changed across 5.x, 8.0, or 8.4 releases.
• The SQLSTATE 42000 class is shared with error 1064 (ER_PARSE_ERROR) and error 1044 (ER_DBACCESS_DENIED_ERROR). If you are catching exceptions by SQLSTATE alone, differentiate by also checking the numeric error code.
• JDBC / Connector/J throws java.sql.SQLException with SQLState: 42000 and ErrorCode: 1049. The message is Unknown database 'name'.
• Python mysqlclient / PyMySQL raises django.db.utils.OperationalError (Django) or mysql.connector.errors.ProgrammingError with errno 1049.
• Node.js mysql2 emits an error object with code: 'ER_BAD_DB_ERROR' and errno: 1049.
• On Linux, the lower_case_table_names server variable controls case sensitivity for table names but does not affect database name case sensitivity at the filesystem level in the same way across all configurations — always check the actual directory name when diagnosing case issues.

Frequently Asked Questions

Why does the same connection string work on Windows but fail on Linux? MySQL on Windows stores database directories in a case-insensitive filesystem, so MyApp and myapp resolve to the same directory. On Linux the filesystem is case-sensitive, so MyApp and myapp are distinct. A connection string that works on a Windows developer machine may fail on a Linux production server if the case does not exactly match the name used when the database was created.

How do I tell whether error 1049 is a missing database or a permissions problem? Error 1049 means the database does not exist at all. Error 1044 (ER_DBACCESS_DENIED_ERROR) means the database exists but the connecting user has no access to it. Run SHOW DATABASES; as a privileged user — if the database appears in the list, you have a permissions issue (1044 territory), not a missing database.

Can a replica or read replica trigger error 1049? Yes. If a database is created on the primary but replication is lagging or has an error, a read replica may not yet have the database directory. Writes to the primary succeed, but reads directed to the replica get error 1049 until replication catches up or is repaired.

My migration tool created the database, so why is my app still getting 1049? Most likely the database was created on a different host or under a different name. Check that your migration tool's connection configuration and your application's runtime connection configuration point to the same host, port, and use the same database name with identical casing.