27 posts tagged with "faq"

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?

Question​

An AWS RDS MySQL schema creates IAM-authenticated users, for example:

CREATE USER 'app_iam' IDENTIFIED WITH AWSAuthenticationPlugin AS 'RDS';

Running atlas migrate diff (or any command that uses the dev-database) against a standard mysql Docker image fails, because that plugin exists only on RDS:

Error: failed to run `atlas migrate diff`: Error: sql/migrate: read migration directory state:
sql/migrate: executing statement "CREATE USER 'app_iam' IDENTIFIED WITH AWSAuthenticationPlugin AS 'RDS';"
from version "20260602081826": Error 1524 (HY000): Plugin 'AWSAuthenticationPlugin' is not loaded

Must the dev-url point at a real RDS instance, or can the dev-database run locally in Docker?

Question​

Schemas that use postgres_fdw reference an upstream PostgreSQL server (SERVER, USER MAPPING, FOREIGN TABLE). That upstream server is often reachable only from inside the VPC of environments such as staging or production: local workstations and CI runners have no network path to it.

Working with such schemas in Atlas, whether for schema planning, schema testing, or simulating the real setup locally, triggers an FDW connection attempt on the dev-database that fails with errors such as:

08001 could not connect to server "upstream_db"

A common case is a materialized view that selects from a foreign table, which opens the FDW connection at CREATE time. What is the recommended pattern for stubbing the foreign server so that schema design, plan, lint, and diff run hermetically against the dev-database?

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

When I have the same schema deployed across multiple database servers, do I need to plan and approve migrations for each database separately?

Question​

Why does Atlas report a MODIFY COLUMN drift on a generated column in MySQL or MariaDB where the only difference is a character-set introducer, such as _latin1'-' on one side and _utf8mb4'-' on the other, even though I changed nothing?

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.

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

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.

Question​

How can I resolve the pq: out of shared memory error that appears while Atlas loads my schema?