Do I need Atlas Cloud to use Atlas?
Question
Do I need Atlas Cloud to use Atlas? We develop locally, run our own CI, and deploy to our own databases.
Do I need Atlas Cloud to use Atlas? We develop locally, run our own CI, and deploy to our own databases.
Why does atlas schema inspect against Cloud SQL list GRANT ... TO "postgres" on every object, and why does schema diff or migrate diff with a local dev database plan a REVOKE from postgres per object?
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?
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?
Terraform can write resource arguments into state and saved plans. HashiCorp's
Terraform state documentation warns that
state files can expose stored secrets. The sensitive flag redacts CLI and UI output, but Terraform can
still record the value in state.
With the atlas_schema resource, Terraform can pass connection metadata while Atlas resolves the
credential when it evaluates atlas.hcl.
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?
When I have the same schema deployed across multiple database servers, do I need to plan and approve migrations for each database separately?
Why does using a dev URL like docker://postgres/15/dev inside the official arigaio/atlas image fail with:
exec: "docker": executable file not found in $PATH?
How do I install Atlas on Windows and set up the PATH environment variable so I can run atlas from any directory?
How can I check the size of my database schemas and count the number of objects in each schema?