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.

Given a large database schema, how can I manage schema migration for a single table without affecting the rest of the schema?

Answer​

Atlas supports the --include flag (or the env.include attribute) to scope operations to specific resources. If you need to manage the lifecycle of a single table (or a set of tables), use this flag to avoid changes to the rest of the schema.

For example, to manage the products table in a MySQL database:

atlas schema apply \
  --url "mysql://root:pass@:3308/db" \
  --to "file://schema.sql" \
  --dev-url "docker://mysql/8/dev" \
  --include "products"

If the connection URL is not bound to a schema, specify the schema name in the pattern:

atlas schema apply \
  --url "mysql://root:pass@:3308/" \
  --to "file://schema.sql" \
  --dev-url "docker://mysql/8" \
  --include "db.products"

This command will only apply changes related to the products table, leaving other tables untouched.

atlas schema apply \
  --url "mysql://root:pass@:3308/" \
  --to "file://schema.sql" \
  --dev-url "docker://mysql/8" \
  --include "*.products"

Read more:

• Exclude Tables
• URL Connection Scope
• Declarative Schema Migration

How to inspect an external_schema data source (ORM schema) in atlas.hcl to confirm it loaded correctly?

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

Question​

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

Question​

Why does atlas migrate diff fail with the following error after running atlas migrate apply?

Error: sql/migrate: connected database is not clean: found table "atlas_schema_revisions" in schema <schema_name>. baseline version or allow-dirty is required

In version control systems like Git, a changeset represents an atomic unit of change. It groups related file modifications under a single hash, allowing them to be reviewed, applied, or reverted together.

In database migrations, a changeset is a unit of schema or data changes made up of SQL statements stored in a migration file, typically executed together in a single transaction.

Question​

How to generate an SQL schema file from an existing migrations directory to quickly set up a database for integration tests?

How do I fix the ModifySchema is not allowed when migration plan is scoped to one schema error?

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?