Azure Database for PostgreSQL (Single Server)
Does ZopNight manage Azure Database for PostgreSQL (Single Server)?
PostgreSQL Single Server, the legacy managed Postgres SKU retired in favor of Flexible Server, bills its provisioned vCores continuously and cannot be stopped. ZopNight surfaces every remaining instance through Azure Resource Graph, attaches 60-day utilization and spend data, and recommends migration plus rightsizing so the workload can start earning stop/start savings.
Rules that fire on Azure Database for PostgreSQL (Single Server)
No active rule family targets Azure Database for PostgreSQL (Single Server) today. Rules that used to are retired, and retired rules publish no pages and fire no findings. Scheduling and permissions coverage are unaffected.
At a glance
| Field | Value |
|---|---|
| Scheduling notes | discovery and cost visibility only; Single Server does not support stop/start. |
PostgreSQL Single Server is the legacy managed PostgreSQL offering, retired in favor of Flexible Server. It bills for provisioned compute continuously with no stop capability.
Continuous vCore billing with no off switch
Every Single Server instance meters its provisioned compute tier for all 168 hours of the week, plus provisioned storage and backup retention as separate lines. The generation predates stop/start support, so there is nothing to schedule: an idle Postgres server on this SKU costs the same as a busy one. The retirement of the product line adds a second dimension: beyond the money, each remaining instance is technical debt on an offering Microsoft no longer carries forward.
What discovery shows for legacy Postgres
Discovered via Azure Resource Graph. Azure Monitor metrics (60-day lookback) and Cost Management billing quantify usage and spend, and recommendations flag migration and rightsizing. That utilization history is the useful artifact here: it tells a team, with two months of evidence, whether a server is genuinely busy, merely ticking over, or fully abandoned. Those are three very different migration priorities.
Two costs hiding in every Single Server instance
First, the schedulability gap. An equivalent workload on Flexible Server can stop billing for compute outside working hours; on Single Server that saving is structurally unavailable, so the gap between the two compounds every week the migration slips. Second, habitual over-provisioning: legacy database tiers were often sized once, early, and generously, and a 60-day lookback frequently shows single-digit utilization on servers nobody has reviewed since creation.
Prioritizing the Postgres migration queue
Migrate to Flexible Server to unlock scheduling savings; that is the standing recommendation ZopNight attaches. Sensible ordering: abandoned servers first (delete rather than migrate), then non-production servers whose off-hours idle time converts directly into stop/start savings, then production servers where the win is staying on a supported platform.
Finding legacy Postgres servers in the portal
Azure portal → Azure Database for PostgreSQL servers presents both product generations in one list; filter or sort by the Deployment type column to isolate the Single Server rows that still need a migration plan.