Why I’m Moving Miskowin’s Backend from Azure SQL to PostgreSQL

For the past few months I’ve been building Miskowin, a web application that lets users create, track, and share career‑progress plans.

When I started the project it made sense to use Azure SQL because I was comfortable with the platform and could spin up a “serverless” database for only a few dollars a month.

However, in practice the cost and limitations of that setup quickly became apparent. Below are the key issues I ran into, and why I’m now moving to a local PostgreSQL database (with the possibility of an Azure‑hosted instance in the future).

1. Serverless SQL isn’t for “live” web traffic

Serverless Azure SQL is optimized for infrequent queries. When the database sits idle it sleeps, and any request after a period of inactivity incurs a 30‑second warm‑up delay. For a web app that needs to respond instantly, this latency is unacceptable.

Because of the frequent “wake‑ups,” the monthly bill can climb far above the advertised $10–$30 range. In my case, the storage cost alone blew through the budget and is estimated to push into $600/month.

2. Tight but inflexible security

Securing Azure SQL is straightforward: you whitelist Azure services and a handful of static IP addresses. I enabled this for my web app’s Azure App Service and the IPs from my development machines.

The problem? GitHub Actions (which I use for CI/CD) don’t have a fixed IP pool, so my automated tests can’t reach the database unless I constantly update the firewall rules. That’s a maintenance nightmare and introduces gaps in my testing pipeline.

3. The “next step” isn’t worth the cost

Until we have a paying user base that can cover Azure SQL’s expenses, it makes more sense to keep costs under control.

Moving to a local PostgreSQL instance lets me:

• Run the database in Docker on my home server.
• Expose it securely to external traffic (via VPN or a firewall rule).
• Keep the infrastructure simple and inexpensive.

I’ve already refactored Miskowin to use PostgreSQL, and local development has been smooth.

4. A temporary detour: Azure Data Factory

While setting up an Azure Data Factory pipeline to migrate data from SQL to PostgreSQL, I hit connectivity problems.

I’m hopeful these are transient; if not, the next logical step will be to host PostgreSQL on Azure.

A managed Azure PostgreSQL instance would cap the monthly cost around $70 and remove the maintenance overhead of running my own server.

Bottom line

• Azure SQL (serverless) is too slow and costly for a live web app.
• Security restrictions clash with automated CI/CD workflows.
• A local PostgreSQL setup keeps things simple and affordable until we’re ready for a managed cloud service.

I’ll keep you posted on how the migration progresses and whether I eventually switch to Azure‑hosted PostgreSQL. Until then, Miskowin will run on a local Dockerised PostgreSQL instance—fast, reliable, and under budget once I can resolve the connectivity issues and migrate the user data.