Choosing between PostgreSQL and SQL Server

MobilityManager supports two relational database providers: PostgreSQL and Microsoft SQL Server. You select the provider once through the DatabaseProvider setting, and it applies to both the system and tenant databases. This article helps you choose and explains how the setting behaves.

The DatabaseProvider setting

The provider is read from configuration at runtime. Valid values are exactly:

• PostgreSQL
• SqlServer

Set it as an environment variable (DatabaseProvider) or in appsettings.json. Any other value causes the application to throw an Unsupported database provider error at startup, so spelling matters.

Note: Both the system database and every tenant database use the same provider. You cannot mix PostgreSQL for one and SQL Server for the other in a single deployment.

When no provider is configured

If neither a provider nor a connection string is present, each database context falls back to an in-memory database. This lets the application start unconfigured and present the onboarding wizard rather than crashing. In-memory mode is never treated as "configured" and must not be used for real data.

PostgreSQL

PostgreSQL is the default and recommended option, particularly on ARM-based machines and for the Docker Compose stacks, which ship a postgres:16-alpine container. Connection strings use the Npgsql key/value format:

Host=your-db;Database=mobilitymanager_system;Username=app;Password=secret

SQL Server

Microsoft SQL Server is fully supported and is used by the hosted demo environment on Azure SQL. Connection strings use the standard SQL Server format:

Server=tcp:your-server,1433;Initial Catalog=MobilityManagerSystem;User ID=app;Password=secret;Encrypt=True;TrustServerCertificate=False;Connection Timeout=30;

Comparison at a glance

Choosing for your environment

1. Pick the provider your team already operates and can back up confidently.
2. Set DatabaseProvider to the matching value on every instance and background job.
3. Provide SystemConnection and TenantConnection strings in the same format as the provider.
4. Keep the provider consistent across your API pods, seed jobs, and Compose services.

Warning: Migrations are provider-specific. Switching providers after go-live is a data migration project, not a configuration change — decide before you load production data.

Related

• Configuring the database connection strings
• Using the LocalDatabase provider mode
• Migrations and the onboarding redirect on startup
• Backing up and restoring your databases