EF Core migrations always using "postgres" database instead of configured connection string

[Erol Mehmed]

When running `dotnet ef database update`, EF connects to database "postgres" instead of my configured database "taskflow".

1. EF should use the connection string pointing to database "taskflow".
2. EF attempts to connect to database "postgres" and fails with:
3. 3D000: database "postgres" does not exist

[Karthikeyan Palanisamy]

Hi Erol,

Greetings from syncfusion support!

We’ve reviewed your query regarding EF Core migrations connecting to the postgres database instead of taskflow.

This typically occurs because EF Core's design-time tooling is not picking up your intended connection string. Common causes include:

• IDesignTimeDbContextFactory is missing or misconfigured, EF falls back to a default PostgreSQL connection which targets the postgres maintenance database.
• Environment variables / appsettings not loaded at design time, the connection string is read from a source unavailable during dotnet ef execution.
• Wrong connection string key, a typo or incorrect key name causes the fallback behavior.

Recommended Solutions

1. Implement IDesignTimeDbContextFactory

Add a factory class to your project to give EF an explicit connection string at design time:

public class AppDbContextFactory : IDesignTimeDbContextFactory<AppDbContext>
{
    public AppDbContext CreateDbContext(string[] args)
    {
        var optionsBuilder = new DbContextOptionsBuilder<AppDbContext>();

        optionsBuilder.UseNpgsql(
            "Host=localhost;Database=taskflow;Username=youruser;Password=yourpassword");

        return new AppDbContext(optionsBuilder.Options);
    }
}

Place this class in the same project as your DbContext. EF will use it automatically during migrations.

2. OnConfiguring is overriding your connection string

If your DbContext has this:

protected override void OnConfiguring(DbContextOptionsBuilder options)

{

    options.UseNpgsql("Host=localhost;Username=postgres");

}

This overrides everything EF passes in including your real connection string.

Fix

Only configure if EF hasn’t already:

protected override void OnConfiguring(DbContextOptionsBuilder options)

{

    if (!options.IsConfigured)

    {

        options.UseNpgsql(

            "Host=localhost;Database=taskflow;Username=...");

    }

}

Or remove OnConfiguring entirely if you use AddDbContext.

3. Pass the Connection String via CLI

Override the connection string directly when running the command:

dotnet ef database update --connection "Host=localhost;Database=taskflow;Username=youruser;Password=yourpassword"

 4. Verify appsettings.json is Loaded

Ensure your Program.cs or Startup.cs reads configuration properly, and that the key matches exactly:

appsettings.json

{

  "ConnectionStrings": {

    "DefaultConnection": "Host=localhost;Database=taskflow;Username=youruser;Password=yourpassword"

  }

}

Program.cs

builder.Services.AddDbContext<AppDbContext>(options =>
    options.UseNpgsql(builder.Configuration.GetConnectionString("DefaultConnection")));

Note: appsettings.Development.json is only loaded when ASPNETCORE_ENVIRONMENT=Development is set. Confirm this environment variable is configured in your terminal session.

Reference:
https://github.com/npgsql/efcore.pg/issues/72

Please let us know if you need further clarification or assistance

Regards,
Karthikeyan P

[Erol Mehmed]

Hello.

The problem was I had two postgres databases. One local and one in docker, both were on the same port.

[Karthikeyan Palanisamy]

Hi Erol,

Thank you for the update and for sharing the root cause.

Having two PostgreSQL instances (one local and one running in Docker) bound to the same port can easily lead to confusion during EF Core design‑time operations. In such cases, dotnet ef may connect to an unexpected instance depending on which service responds first, resulting in errors like attempting to access the wrong database.

We’re glad you were able to identify and resolve the conflict.

As a best practice, we recommend:

• Ensure only one PostgreSQL instance is listening on a given port at a time, or
• Explicitly separate them using different ports (for example, 5432 for local, 5433 for Docker).
• Always verify the resolved connection string and target host/port when running EF Core CLI commands.

Please feel free to reach out if you have any further questions.

Regards,
Karthikeyan P