With Atlas, we advocate for treating migration directories as deployment artifacts resulting from a structured build process. The preferred approach is to push migration directories to the Atlas Schema Registry. In addition to its role as a migration directory storage, the Schema Registry provides a tight integration with the Atlas CLI and the Atlas Cloud UI, allowing you to deploy migrations, visualize schemas over time, review deployment logs and errors, and more.

However, some users prefer to store their migration directories in S3, typically due to internal policies or requirements.

Question​

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

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

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/

How do I instruct Atlas to not generate RENAME commands for table constraints in schema migrations when running commands such as migrate diff, schema apply, schema plan, etc.?

Question​

How to use the baseline option with ariga/atlas-action/migrate/apply when adopting Atlas for an existing database?

Question​

How can I define functional indexes in MySQL using Atlas HCL syntax?

Question​

Why does atlas schema apply / atlas schema plan fail with an error like this when working with PostgreSQL extensions?

Question​

How can I run init scripts on SQL Server when using GitHub Actions services instead of the Atlas docker blocks?

PostgreSQL extensions are additional modules that extend the functionality of the PostgreSQL database. Examples of popular extensions include PostGIS for geographic data handling, PGVector for vector similarity search, and pgcrypto for cryptographic functions.

Once installed, these extensions provide additional data types and objects that users' schemas can leverage. However, because extensions are managed at the database level (and can only be installed once per database rather than per schema), users may prefer handling these extensions separately from their primary application schema migrations.

For example, if you maintain multiple applications – each with its own schema(s) but several relying on the same PostgreSQL extension – determining which application should handle installation, upgrades, or removal can be challenging. To address this complexity, managing extensions through a dedicated migration process is beneficial. This separation ensures extension-related changes remain isolated.

This guide demonstrates how to use the --include flag (or env.include argument) provided by Atlas to limit migrations specifically to PostgreSQL extensions.

How can I inspect a specific resource, such as a function, view, or table, using the schema --include flag?