atlas migrate apply --url $DATABASE_URL fails

[domenkozar]

Error: sql/migrate: execute: read revisions: pq: relation "atlas_schema_revisions.atlas_schema_revisions" does not exist

Using Atlas 0.18.

[a8m]

Hey, @domenkozar 👋

migrate apply is one of the most frequently used Atlas commands, so I suspect there may be something incorrect in your setup unless I'm overlooking something.

If the atlas_schema_revisions table resides in its own schema, it means you are operating on the entire database (or multiple schemas), not just a single one - is it correct? Could you please provide a few commands that reproduce this issue, similar to the one below?

[domenkozar]

I'm not sure what else to provide, I'm using https://neon.tech/ for postgres store.

--revisions-schema public workarounds the issue.

[a8m]

Hey! Just fyi, I found the issue for this - https://github.com/neondatabase/neon/issues/3148. TL;DR, Neon does not respect the search_path parameter and we'll need to work around this.

---

[!IMPORTANT] Update: Neon users, please use: --revisions-schema public until the issue is resolved in Neon side, or Atlas has a special handling for Neon-based URLs.

[jakubno]

@a8m I have the same problem. On a brand new database created on Supabase I am getting:

Error: upsert revision-table id: pq: relation "atlas_schema_revisions.atlas_schema_revisions" does not exist

But atlas_schema_revisions table is present in public schema.

I am running:

atlas migrate apply --env local --url $(POSTGRES_CONNECTION_STRING) --baseline "20000101000000"

I am on:

atlas version v0.27.0

and my atlas.hcl:

// Define an environment named "local"
env "local" {
  // Declare where the schema definition resides.
  // Also supported: ["file://multi.hcl", "file://schema.hcl"].
  src = "ent://pkg/schema/"

  // Define the URL of the Dev Database for this environment
  // See: https://atlasgo.io/concepts/dev-database
  dev = "docker://postgres/15/dev"

  migration {
    // Define the path to the migration directory.
    // See: https://entgo.io/docs/migrate/#migration-directory
    dir = "file://migrations"
  }

  diff {
    skip {
      drop_func = true
      drop_trigger = true
      drop_schema = true
    }
  }
}

If you need anything else, let me know, happy to provide more info.

[NolanTrem]

+1 for @jakubno 's issue here with Supabase.

We're using Hatchet, who uses Atlas, in R2R and I see: relation "atlas_schema_revisions.atlas_schema_revisions" does not exist for their migrations.

[nkuz2]

+1 @jakubno 's issue with Supabase as well @a8m, do you have any thoughts on this besides those mentioned in https://github.com/ariga/atlas/issues/2601?

[a8m]

If the schema revisions table resides in the public schema, you need to set: --revisions-schema public. That's probably because the database you're using does not respect the search_path parameter (like explained here).

By default, Atlas uses the atlas_schema_revisions schema when the scope of work is "database" and not "schema" (you can read more about it here).