The removed database still works.

Hi Francesco Manzotti,

Please let us know if the answer was helpful.Please do not forget to "Accept the answer” and “up-vote” wherever the information provided helps you, this can be beneficial to other community members

Hi Francesco Manzotti,

Just checking in to see if the above given solution helped. And, if you have any further query do let us know.

Regards,
Vrishabh

Hi Francesco Manzotti,

Just checking in to confirm—do the steps provided above address your query?"

Thanks,
Vrishabh

Hi Francesco Manzotti,

I've added comments in the Private Message section—could you please take a look and let me know if they address your query?

Thanks,
Vrishabh

Hi Francesco Manzotti,

Based on your comments in the private message, please review the following steps carefully for better clarity, along with the official documentation -

Azure Database for PostgreSQL – Billing After Deletion & Backup Retention

You can rest assured that once you delete an Azure Database for PostgreSQL server (and its resource group), you will not continue to incur charges for the database service. Below is a clear breakdown addressing your questions about backup retention and billing, with references to official Microsoft documentation for verification.

Backup Retention vs. Billing

Backup retention refers to how long Azure keeps your automated backups after deletion, in case you need to restore the data. For Azure Database for PostgreSQL – Flexible Server, the default retention is 7 days and can be extended up to 35 days while the server is active. Importantly, retaining backups does not mean you continue paying for the database service during that period. Once the server is deleted, Azure stops charging for the database’s compute and primary storage. All the compute units and storage allocation associated with your PostgreSQL server are released, so you’re not billed for the server itself after deletion. [Backup and...PostgreSQL] [Resource G...anagement)]

• Billing for the Deleted Server: After deletion, you will not be billed for the PostgreSQL server instance. In other words, you won’t pay for cores, memory, or the database storage that was provisioned, since the server resource no longer exists. This holds true even if backups are retained behind the scenes — those backups don’t equate to an active database running in your account.
• Backup Storage Costs: Azure’s managed database services include a certain amount of backup storage at no extra cost. Azure Database for PostgreSQL Flexible Server provides backup storage up to 100% of your provisioned server size for free. Any backup storage beyond that (for example, if you had a lot of data changes or a long retention period) is charged in GB per month. In practice, right after deletion your remaining backups typically occupy about the same space as your database did (or less, if you hadn’t been using the full storage). This is usually within the free quota. So, unless your backups exceed the free allowance, you won’t incur charges for the retained backups. Even if you do exceed the free backup storage, it would be a relatively small storage charge, not the full cost of a database service. For example, Microsoft’s documentation notes that if you provisioned a 250 GiB server, you get 250 GiB of backup storage free – enough for roughly 35 days of daily backups if each daily backup is ~25 GiB. Only beyond that would extra storage be billed. [Backup and...PostgreSQL]

What Happens When You Delete the Resource Group?

Deleting the Resource Group that contained your Azure Database for PostgreSQL server will indeed remove all resources in that group – including the PostgreSQL server itself, any virtual network or other linked components in that group. After this action: [Resource G...anagement)]

• The PostgreSQL server resource is gone from your subscription (you won’t see it in the Azure portal or CLI). Consequently, Azure stops all meterable services for that server (no compute, no database storage usage).
• Automated backups, however, are handled a bit differently: Azure’s service will still keep the last backups for a short period (up to the retention window) for recovery purposes. These backups are stored in Azure’s internal systems (not in your resource group). They are not user-accessible resources and do not appear in your subscription’s resource list. Their only purpose is to allow a restore in case you realize you need data back. Microsoft’s official guidance for PostgreSQL Flexible Server indicates that even if a server is dropped, its backups remain available for a limited time (approximately 5 days for a dropped server). This is shorter than the usual 35 days retention for an active server, and it’s a safeguard for accidental deletions. [Restore a...PostgreSQL], [Restore a...PostgreSQL]
• Does deleting the RG remove backups? Effectively, yes, in terms of your management – you have no manual control or visibility over those backups after deletion. Azure will automatically purge the backups after the retention period expires. For a dropped server, after the short window (5 days), the backup is permanently deleted by the system. If you kept the server running, backups would cycle out after 7–35 days as per retention policy. But once the server is gone, Azure doesn’t keep the full 35 days of backups indefinitely; it’s primarily up to 5 days for potential restore of a mistakenly deleted server. Bottom line: you do not need to take any action to delete backups – and you are not being charged as if the server were still operational during that retention timeframe. [Restore a...PostgreSQL]

Will I Be Charged During the 35-Day Backup Retention Period?

No – you won’t be paying for the database service itself after deletion, regardless of the 35-day backup retention statement. The confusion here is understandable, so let’s clarify the two aspects of Azure billing post-deletion:

• Database Service Charges: These stop immediately upon deletion of the server. You won’t pay for vCores, memory, I/O, or any kind of “server running” cost after the deletion event. If your Azure bill shows charges for Azure Database for PostgreSQL, those would only accrue up to the time of deletion and cease thereafter.
• Backup Storage Charges: This is the only area where any cost could occur after deletion, but only under specific conditions. Azure does not charge for keeping backups up to a certain size (equal to your DB size). If your backup data exceeds that included size, Azure would charge for the overage in GB/month. However, since you deleted the server, no new backups are being taken (the backup data will just age out). Unless your database was very large and filled the free backup quota, it’s unlikely you’d incur a notable charge for this short retention period. For example, if you had a 50 GB database, you have 50 GB of free backup storage. The retained backups for a few days would typically be well within that. So, in most cases there is zero cost during the retention period. Even in rare cases with extremely large backups beyond the free limit, the cost would be only for the extra GBs of storage, not for the database compute. (For reference, Azure’s pricing for extra backup storage is per GB per month—so if you had, say, 10 GB of backups over the free allotment for a few days, that might be just a small fraction of a month’s charge.) [Backup and...PostgreSQL]

In summary: Deleting your Azure PostgreSQL server means all primary charges stop. Azure will keep the last backup snapshots for a short time (to allow recovery if needed), but this does not equate to continuing full service charges. You might at most see a minor storage cost for backup retention if your backup size was beyond the free included limit, but in many cases there’s no extra charge at all for that period. And since you also deleted the resource group, you’ve successfully removed everything user-manageable associated with that server from your subscription.

References to Official Documentation 📚

To ensure the accuracy of this information, here are excerpts from Microsoft’s official docs:

• Azure PostgreSQL Backup Retention Policy: “The default backup retention period is 7 days, but you can extend the period to a maximum of 35 days.” (Azure Docs – Backup and restore in Azure Database for PostgreSQL). This means Azure keeps the backups for that long for restoration purposes, but it doesn’t imply the server remains active. [Backup and...PostgreSQL]
• Backup Retained After Deletion: “When a server is dropped, the Azure Database for PostgreSQL flexible server backup is retained for five days in the service… within five days from the time of server deletion.” (Azure Docs – Restore a dropped server). This is a special case note that even if you delete the server (or the whole resource group), Azure still keeps a backup for a few days in case you need to restore the deleted server. After that, the backups are cleaned up by Azure. [Restore a...PostgreSQL]
• No Charge for Deleted Resources: “When you delete a resource group, all of its resources are also deleted.” (Microsoft Learn – Azure Resource Manager documentation). Once the PostgreSQL server resource is deleted, it’s not consuming resources, so you are not billed for it. (All Azure billing is resource-based; no resource means no bill.) [Resource G...anagement)]
• Backup Storage Included vs Paid: “Azure Database for PostgreSQL flexible server provides up to 100 percent of your provisioned server storage as backup storage at no extra cost. Any extra backup storage that you use is charged in gigabytes per month.” (Azure Docs – Backup storage cost). This outlines how backup storage billing works. In most deletion scenarios, your backup usage will be within the free limit, so this typically doesn’t result in additional charges. [Backup and...PostgreSQL]

By referencing the above official documentation, you can be confident that deleting the server and resource group will not lead to surprise charges beyond possibly a negligible backup storage fee (and only if your backups were huge). In essence, once everything is deleted, your Azure bill for that PostgreSQL resource should cease. The 35-day retention is about data protection, not continued usage billing.

Hi,

I understand what you wrote, but that's not what's happening in my case.

There’s something I don’t understand. The database is no longer visible in the Azure portal, but it still responds to queries—is that correct? In my last invoice, I paid the full price for the Flexible Server Burstable B1MS database for 744 hours.Another thing: in the list of resource groups, I can no longer see the group with the deleted database, but if I go to Cost Analysis and filter by the last day, I still find it listed. How is that possible? The amounts involved aren’t significant, but I’d rather not keep paying for resources I don’t need.

PS You copied the same text twice

Hi @Francesco Manzotti

Thank you for sharing the additional information. We kindly request you to review the details provided below and verify if all necessary actions have been completed from your end. Once done, please share your feedback so we can proceed with further troubleshooting of the reported issue.

Here’s why this can happen:

• Azure resources that were logically deleted (e.g., from the portal UI) might still exist at the backend due to a failed delete operation, soft-delete, or a stuck resource provider.
• The resource group may appear deleted, but if it contained a resource that failed to delete properly, costs can still be incurred.
• Cost Analysis continues to show charges for active (or recently active) resources, even if they no longer appear in the portal.

What you should do:

Check for orphaned resources using Azure CLI or PowerShell:

You may still find the database with:

az postgres flexible-server list --output table

If it's still listed, delete it explicitly:

az postgres flexible-server delete --name <your-db-name> --resource-group <your-rg-name>

Check for 'hidden' or stale resource groups:

Run:

az group list --output table

If your RG shows up, try:

az group delete --name <your-rg-name>

Review Activity Log for deletion events:

In Azure Portal → Monitor → Activity Log, filter by the relevant time and resource group name. This will show if the delete operation failed.

We truly value your continued patience and understanding as we work to resolve this matter.

Thanks,
Vrishabh

I sent you a private message.

Hi @Francesco Manzotti

Thank you for your patience. Could you please share your response or findings based on the below comment? Once we have that, we can consult with the product team if needed.

Here’s why this can happen:

• Azure resources that were logically deleted (e.g., from the portal UI) might still exist at the backend due to a failed delete operation, soft-delete, or a stuck resource provider.
• The resource group may appear deleted, but if it contained a resource that failed to delete properly, costs can still be incurred.
• Cost Analysis continues to show charges for active (or recently active) resources, even if they no longer appear in the portal.

What you should do:

Check for orphaned resources using Azure CLI or PowerShell:

You may still find the database with:

az postgres flexible-server list --output table

If it's still listed, delete it explicitly:

az postgres flexible-server delete --name <your-db-name> --resource-group <your-rg-name>

Check for 'hidden' or stale resource groups:

Run:

az group list --output table

If your RG shows up, try:

az group delete --name <your-rg-name>

Review Activity Log for deletion events:

In Azure Portal → Monitor → Activity Log, filter by the relevant time and resource group name. This will show if the delete operation failed.

Thanks,
Vrishabh

I replied to you privately on Saturday.

The screenshot of the activity log is provided as the initial post in this conversation. Now i'll sent to you in private again.

Hi @Francesco Manzotti

We’re currently consulting with our internal team regarding your concern and will follow up with you shortly.

Thanks,
Vrishabh

Hello Francesco Manzotti,

Welcome to the Microsoft Q&A and thank you for posting your questions here.

I understand that your removed database still works.

Do the exact forensic steps below (Activity Log JSON, nslookup, pg_postmaster_start_time(), Resource Graph, and meter-level Cost Analysis). Those steps will give incontrovertible evidence you can either act on (delete leftover resources, drop private endpoints) or submit to Azure billing/support for correction. https://learn.microsoft.com/en-us/azure/postgresql/flexible-server/how-to-restore-dropped-server and use the associated links for more details.

1. Activity Log evidence: Portal > Monitor > Activity Log > filter Delete PostgreSQL Server > open JSON > copy resourceId & submissionTimestamp. Check the docs here for restore a dropped server.
2. nslookup the server FQDN from your client machine. (If private IP, look in private DNS.) - https://learn.microsoft.com/en-us/azure/private-link/private-endpoint-dns
3. Connect with psql and run:

   SELECT current_user, current_database(), version();
   SELECT inet_server_addr(), inet_server_port();
   SELECT pg_postmaster_start_time();

Save the output (these are forensic facts). - https://www.postgresql.org/docs/current/functions-info.html

4. CLI resource search across subscriptions:

 az account list -o table
   az graph query -q "Resources | where type=='microsoft.dbforpostgresql/flexibleservers' and name =~ 'YOUR_SERVER_NAME' | project subscriptionId, name, resourceGroup, location"

https://learn.microsoft.com/en-us/azure/governance/resource-graph/samples/advanced

5. Cost Analysis: Portal > Cost Management > Cost analysis > choose date range > Group by Meter & Resource > download usage file for invoice month. Inspect resourceId and meterCategory. Check docs on cost analysis & usage download.
6. If private endpoint/DNS present, list and delete it (portal or CLI):

az postgres flexible-server private-endpoint-connection list --resource-group <rg> --server-name <server>
   az network private-endpoint list
   az network private-endpoint delete --name <pe-name> -g <pe-rg>

https://learn.microsoft.com/en-us/cli/azure/postgres?view=azure-cli-latest

7. If billing looks wrong after analysis, open a Billing support request and attach usage CSV + activity-log JSON + SQL evidence. Create support request from azure portal: https://learn.microsoft.com/en-us/azure/azure-portal/supportability/how-to-create-azure-support-request#go-to-help--support-from-the-global-header

I hope this is helpful! Do not hesitate to let me know if you have any other questions or clarifications.

Please don't forget to close up the thread here by upvoting and accept it as an answer if it is helpful.

Hi @Francesco Manzotti

I’ve requested a few details via the Private Message section—when you have a moment, please share them there. This will help us collaborate effectively with the internal team during the investigation.

Thanks,
Vrishabh