Skip to main content

Understanding MySQL Error 1049 (42000): Unknown database

Question

How do I resolve MySQL Error 1049: Unknown database when connecting using a URL like: mysql://user:pass@host:port/<database_name>?

danger

Error: mysql: query system variables: Error 1049 (42000): Unknown database '<database_name>'

What does this error mean, and how can I fix it?

Schema as Code: Directory Structure for HCL Files

Question

How do I configure Atlas to load the database schema from nested directories with HCL files?

 /project
├── main.hcl
├── extensions
└── schemas
└── public
├── public.hcl
├── tables
│ ├── pets.hcl
│ ├── posts.hcl
│ ├── profiles.hcl
│ └── user_groups.hcl
├── functions/
└── types/

Features Not Supported by the Community Release

After upgrading Atlas, you might encounter an error stating "Feature X is no longer supported by this release."

For example:

Error: data.external_schema is no longer supported by this release.

This occurs when you install the community version of Atlas, which lacks some features available only in non-community builds.

How do I resolve out-of-order migration conflicts after a hotfix?

When working with multiple branches and applying hotfixes directly to production, out-of-order migration conflicts may occur if migration files are created with timestamps that don't reflect the actual merge order.

The Problem

Consider this scenario:

Initial state:

  • Master branch:
    • 001_initial.sql
  • Dev branch (PR pending):
    • 001_initial.sql
    • 002_add_posts.sql
    • 004_add_index.sql

After hotfix applied directly to production:

  • Master branch:
    • 001_initial.sql
    • 003_hotfix_add_email.sql ← hotfix added
  • Dev branch (unchanged):
    • 001_initial.sql
    • 002_add_posts.sql
    • 004_add_index.sql

out-of-order migrations

After merging master into dev - the problem:

  • 001_initial.sql - Applied to production
  • 002_add_posts.sql - Dev-only, not applied to production
  • 003_hotfix_add_email.sql - Applied to production
  • 004_add_index.sql - Dev-only, not applied to production

This creates a non-linear migration history where migration files 002 and 004 were created before and after the hotfix timestamp but haven't been applied to production.

Handling drift between my schema and the atlas_schema_revisions table

Question

My revisions table lists the following versions:

mysql> SELECT * FROM  "atlas_schema_revisions";
+-------------------------+---------+-----+
| version | applied | ... |
+-------------------------+---------+-----+
| .atlas_cloud_identifier | 0 | |
| 20251007053111 | 1 | |
| 20251007051222 | 1 | |
| 20250618084333 | 1 | |
+-------------------------+---------+-----+

However, when I inspect the target database, the schema changes from 20250618084333 were never applied. How can I delete the latest row(s) so the revision history reflects the actual state?

Encoding for Atlas' schema files

Question

What encoding is used by Atlas for schema files? How do you avoid encoding issues with PowerShell on Windows?

Answer

Atlas uses UTF-8 to encode schema files and migration files generated by Atlas. UTF-8 is the default encoding on nearly all system terminals, but on Windows, PowerShell uses UTF-16 by default. This can cause an encoding issue when Atlas loads the schema files generated by the inspect command.

Seeding your database with data

Applications often rely on a static dataset to pre-exist in the database in order to function. Examples for such datasets include user roles, country names, or product categories.

The process of populating the database with this initial data is called "seeding". This guide will show you how to seed your database using Atlas.