Run Postgis migrations on Azure requires superuser permissions

[rhuesken]

Unfortunately, the solution provided for #3713 does not work for us.

I also tried "modelBuilder.HasPostgresExtension("public");"

The error I get is "42501: Because postgis isn't a trusted extension, only members of "azure_pg_admin" are allowed to use CREATE EXTENSION postgis".

I included my original comment below.

Scripting migrations is cumbersome and error prone, please assist in finding a solution that works in our setup.

Hi,
We are on EFCore / Npgsql / Net10, and we have the same issue on Azure Postgres. The following command is always added to the modelsnapshot, regardless if I add a check or not (using modelBuilder.HasPostgresExtension):

NpgsqlModelBuilderExtensions.HasPostgresExtension(modelBuilder, "postgis");

On Azure, the superuser has the permissions to install extensions in schema public. However, we run migrations under a different user (and in different schemas), so we cannot use the superuser account. I found that on Azure, the following SQL runs without errors under the "migrations" user (in January 2026):

CREATE EXTENSION IF NOT EXISTS postgis with schema public;

Please note: this statement now (April 2026) also gives the error mentioned above, so my original suggestion would no longer help...

However, this SQL is never generated, even when I provide

modelBuilder.HasPostgresExtension("public", "postgis");

Is there a workaround (other than script the migration and apply that script manually)? Or would it be possible to fix the generated code for the HasPostgresExtension method...

Originally posted by @rhuesken in #3496

[roji]

#3713 was only about not attempting to create the extension when initial creating the history table.

What exact kind of solution are you looking for here? if Azure requires you to create the PostGIS extension as an admin user, there's nothing the EF PG provider can do about that. You may need to set up your database - including the extension - outside of EF, and then apply EF migrations to it.

[rhuesken]

Currently, we have an Azure instance with the following accounts:

• Superuser (with the "azure_pg_admin" role) who is able to install trusted extensions. Consequently, we always use this account to setup the (postgis) extensions in a database, which usually happens only during installation / creating new databases. The credentials of this user are only known to a small number of employees.
• "Migrations" user, which owns the various schemas in the database and creates the tables. This happens more often and may become part of our CI/CD pipeline.

We prefer to keep these permissions in separate accounts.

Under net8/pg16 this worked fine, under net10/pg17 we ran into the troubles with the extension check ("CREATE EXTENSION IF NOT EXISTS postgis;"). I have tested this again, and I found that also the following statement gives the error:

CREATE EXTENSION IF NOT EXISTS postgis with schema public;

An option to explicitly skip the extension check (making it the responsibility of the developer) would be helpful.

[roji]

Under net8/pg16 this worked fine

How so? AFAIK we were still doing the same CREATE EXTENSION IT NOT EXISTS in EF 8 (but I might be mis-remembering).

I'm still trying to understand what exact change you're asking for. #3713 already the fixed the issue of the extension getting created during initial setup (migration history table creation). Beyond that, if a regular migration adds the extension, then you can simply edit that migration and manually remove the extension creation - this is perfectly safe to do (we recommend editing migration files when needed). You'd need to do this exactly once (the first time the extension is created), and once you do, it becomes the user's responsibility to ensure that the extension exists in the database (by manually creating it via the superuser user).

So as far as I can tell, you can already do things in the way that you want, and there's not much the PG provider can do to help here.

[rhuesken]

Hi,

In our initial migration, we have already comments around the extension check:

public partial class ProsInitialPoc : Migration
    {
        /// <inheritdoc />
        protected override void Up(MigrationBuilder migrationBuilder)
        {
            // Skip this check, since it results in errors.
            // Manually install postgis in the target database and create the 

            //migrationBuilder.AlterDatabase()
            //    .Annotation("Npgsql:PostgresExtension:postgis", ",,");

            // Run adjusted SQL to include Partitioning clause
            migrationBuilder.SqlFile(Assembly.GetExecutingAssembly(), "Msg.Prospector.Lib.Postgres.Migrations.Sql.InitialImportTracks");

In the DbContext, we have the following line:

protected override void OnModelCreating(ModelBuilder modelBuilder)
        {

            // Explicitly manage PostGIS extension (prevents auto-generation)
            modelBuilder.HasPostgresExtension("postgis");

In the ModelSnapshot // <auto-generated /> on the first line...), there still is a check:

protected override void BuildModel(ModelBuilder modelBuilder)
        {
#pragma warning disable 612, 618
            modelBuilder
                .HasAnnotation("ProductVersion", "10.0.6")
                .HasAnnotation("Relational:MaxIdentifierLength", 63);

            NpgsqlModelBuilderExtensions.HasPostgresExtension(modelBuilder, "postgis");
            NpgsqlModelBuilderExtensions.UseIdentityByDefaultColumns(modelBuilder);

I would like to prevent this check, yet I do not understand how to configure that correctly. And since ModelSnapshot is autogenerated, there is no point in removing it there...

[roji]

The OnModelCreating and ModelSnapshot parts are irrelevant to this discussion; only the migration's Up method determines what actually gets executed.

Please post exact details on when the error happens - is it your very first migration, a later migration... We need more context here.

[rhuesken]

Hi,
Thanks for your efforts to think along.
Let's start with the stacktrace of the error I get when performing an update-database command in the package manager console in VS.

update-database-error.txt

The relevant part of the Up() method is in the comment above, please let me know if this is sufficient context.
Could this be a more generic EFCore issue?

[roji]

Your log shows the error happening during the creation of the migration history table, i.e. on the first run (when the database is first created). That means you're running into #3496, which has already been fixed. However, version 10.0.2 (see the milestone) hasn't yet been released - that should happen within the next few weeks.

[rhuesken]

Thanks, I'll try again later.