SQL Server Licensing Costs: What You're Really Paying (and What to Do About It)

01 · The bill

Where the money actually goes

SQL Server is licensed per core, with a four-core minimum per instance, and the pricing is designed to compound. The headline numbers for SQL Server 2022: Enterprise edition lists at roughly $13,748 per two-core pack (perpetual), Standard at roughly $3,717 per two-core pack. Add Software Assurance — about 25% of the license value per year — and you have a recurring bill that most CFOs underestimate because it arrives in three different invoices: the initial license, annual SA, and the hardware or cloud it runs on.

Pricing reference: Microsoft list prices for SQL Server 2022 as of September 2026. Microsoft adjusts list pricing over time and Enterprise Agreements change these materially — verify current rates on Microsoft's SQL Server pricing page before budgeting. Assumptions: perpetual-license list price, before EA discounts, cloud figures at pay-as-you-go rates.

Cloud changes the shape but not the weight. On Azure, SQL Server pay-as-you-go licensing runs about $73 per vCore per month for Standard and $274 for Enterprise. A 16-vCore production instance on Enterprise is therefore roughly $52,000 a year in license alone — before compute, storage, backup, or anyone's salary. On AWS, RDS for SQL Server is license-included only: there is no BYOL option, and the bundled hourly rate runs roughly 2.6x the cost of equivalent PostgreSQL compute (varies by region and instance class — check current AWS pricing). Teams with Microsoft Enterprise Agreements get no BYOL benefit on RDS — the license-included model is fixed.

The third invoice is the one nobody budgets: the cost of staying still. SQL Server 2016 entered its paid extended-security-update term in July 2026. Microsoft's own guidance prices ESUs at roughly 75% of the on-premises license cost annually — 75%, 100%, then 125% across the three-year term. That is up to two and a quarter times the license cost spent entirely on remaining where you are. The subsidy era — free ESUs for moving to Azure — is over. Delay is now priced, and the meter runs every year, against every core.

02 · Why renewals hurt now

The three forces raising your bill

Force one: end-of-support deadlines are stacking. Windows Server 2016 support ends January 12, 2027. SQL Server 2017 follows on October 12, 2027. SQL Server 2016's paid ESU term runs to July 2029. Many mid-market estates are not planning around one deadline — they have three inside 18 months, each one shrinking the planning room and pre-spending the budget. Panic-driven renewals are the most expensive kind.

Force two: edition creep. Features that quietly require Enterprise edition accumulate over the years: online index rebuilds on large tables, table partitioning, data compression, Always On availability groups. Each one was a reasonable engineering choice at the time. Together they lock you into the most expensive edition, and downgrading requires re-architecting the workload that justified them.

Force three: audit risk as a pricing mechanism. License compliance audits are how Microsoft discovers your virtualization sprawl — and under-licensed cores get trued up at list price. We are not saying audits are the strategy; we are saying the complexity of core-based licensing across virtualization, containers, and cloud is the mechanism that keeps bills high. If you cannot produce a clean license map in an afternoon, you are overpaying somewhere.

03 · The options

Your three realistic escape routes

Option A: Renegotiate and right-size. Before anything else, inventory every instance: edition, core count, utilization, and whether the Enterprise features in use are load-bearing. Most estates have Standard-edition workloads running on Enterprise licenses and idle cores licensed at the four-core minimum. A license audit and consolidation often cuts a meaningful share of spend without changing a line of code — measure your own baseline before and after. Do this even if you plan to migrate — it lowers the baseline you migrate from.

Option B: Re-platform to managed SQL Server. Azure SQL Managed Instance or RDS for SQL Server moves the operational burden off your team but keeps the license cost (license-included pricing). This makes sense when your constraint is staffing, not money — or when the ESU clock is forcing a move and you need 18 months of runway before a real migration. It is the most expensive long-term option per transaction.

Option C: Migrate to PostgreSQL. For the majority of transactional workloads, PostgreSQL is a genuine replacement: it covers most T-SQL application patterns, and the gaps — linked servers, SSIS, CLR assemblies, Service Broker — are solvable with architecture changes rather than license fees. The license cost drops to zero; what remains is compute, storage, and the one-time migration effort. Our SQL Server → PostgreSQL migration guide walks through the compatibility analysis in detail.

The honest comparison: Option A is weeks and saves 20–40%. Option B is a quarter and saves operational pain, not money. Option C is 4–9 months for a mid-market estate and removes the license line entirely — but it is an engineering project with real T-SQL conversion work. Anyone who tells you it is free is selling something.

04 · The math

A worked example: 64 cores of Enterprise

Take a typical mid-market estate: 64 licensed cores of SQL Server Enterprise, perpetual licenses owned, Software Assurance current. The SA bill alone is roughly 25% of a ~$440,000 list value — about $110,000 per year, every year, plus hardware or cloud. Over a three-year EA cycle: ~$330,000 in SA for the right to keep patching.

PostgreSQL on equivalent compute: zero license cost. A comparable managed PostgreSQL footprint (RDS or Azure Database for PostgreSQL) for this workload class typically runs $40,000–$70,000 per year in infrastructure — compute, storage, and I/O. The migration effort for a 64-core estate with moderate T-SQL complexity: a 2–3 week compatibility assessment, then 4–6 months of conversion and testing with a small team.

The savings range is real but depends on what you count: against SA alone, most estates save substantially over three years — the exact figure depends on edition mix, EA discounts, and what you count as migration cost. Against license-included cloud SQL Server, the gap is wider. What the range excludes: application rewrite effort for exotic T-SQL, SSIS package conversion, and the organizational cost of running two systems during the cutover window. Run your own numbers with our SQL Server License Savings Calculator — it asks for cores, edition, and your renewal figure, and shows the honest range with caveats.

05 · What to do this quarter

The 90-day plan

• Weeks 1–2: license inventory. Every instance, edition, core count, utilization, and the Enterprise features actually in use. This is the cheapest money you'll ever save.
• Weeks 3–4: workload triage. Classify each database: keep on SQL Server (genuinely needs it), re-platform (needs runway), or migrate (PostgreSQL-ready). In most estates, the largest share lands in "migrate" — the compatibility assessment confirms your actual mix.
• Weeks 5–8: compatibility assessment on the migrate cohort. Schema inventory, T-SQL complexity analysis, dependency mapping for SSIS/SSRS/linked servers. This is the 2–3 week assessment that determines whether the project is 4 months or 14. Our Database Modernization Assessment covers exactly this scope.
• Weeks 9–12: decision and sequencing. With the assessment in hand: commit to the migration scope, sequence the waves (easiest, most valuable databases first), and set the cutover approach per wave — the SQL Server → PostgreSQL migration pattern gives you the blueprint.

The worst outcome is not migrating — it is discovering in October that the ESU invoice, the EA renewal, and the Windows Server deadline all land in the same quarter. That is how companies end up paying 2.25x their license cost to stand still. The second-worst outcome is migrating without the assessment and discovering your SSIS estate halfway through. Do the inventory. It costs almost nothing and changes every decision downstream.

06 · Hidden lines

The costs that don't appear in the license quote

License invoices are only the visible half of SQL Server's total cost. The hidden half is what actually kills budgets, because it arrives as operational friction rather than a line item.

High-availability architecture. Always On availability groups require Enterprise edition, Windows Server Failover Clustering, and at minimum three nodes for quorum. That is triple the compute, triple the licensing, and a clustering competency your team maintains forever. PostgreSQL replication (streaming replication plus a consensus manager) achieves equivalent availability on open-source tooling — the engineering is real, but it doesn't arrive with a per-core invoice.

Backup and disaster recovery sprawl. Log shipping, differential backups, and off-site DR replicas all consume licensed cores. Every DR node that can run production workloads needs licensing. In cloud deployments, this multiplies: primary, secondary, and DR regions each carry license-included hourly rates. PostgreSQL's continuous archiving to object storage costs pennies per gigabyte and doesn't require a licensed standby.

The DBA tax. SQL Server rewards specialization — SSIS, SSAS, SSRS, and the T-SQL dialect each have their own skill markets. Maintaining deep SQL Server expertise on staff is a permanent headcount line. PostgreSQL expertise is broader, cheaper to hire, and transfers across more employers — which is exactly why the talent market for it is healthier. When you price "keep SQL Server," include the fully loaded cost of the people who keep it running, not just the software.

Audit and compliance overhead. Core-based licensing across VMs, containers, and cloud requires continuous license tracking. The larger the estate, the more this becomes someone's part-time job — or a surprise true-up. Open-source databases eliminate this entire category of work: there is nothing to audit because there is nothing to license.

07 · Staying on SQL Server

When SQL Server is still the right call

Honesty requires the counter-case. There are workloads where staying on SQL Server is the right engineering and business decision, and anyone who tells you PostgreSQL fits everything is not someone you should hire.

Heavy SSIS/SSRS estates. If your business runs on hundreds of SSIS packages and paginated SSRS reports, migrating means rebuilding an entire integration and reporting platform — not just converting SQL. The license savings rarely justify that project on their own. Re-platform to a managed service and contain the estate instead.

Deep Enterprise feature lock-in. Transparent data encryption with extensible key management, stretch database patterns, and some Always On topologies don't map one-to-one. These are solvable but expensive to re-architect, and the migration risk may exceed the license savings for a few more years.

Regulatory and vendor requirements. Some ISV applications are certified only on SQL Server. Breaking certification voids support contracts. Don't migrate the database under a certified application unless the vendor blesses the target — the support risk dwarfs the license math.

Team capacity. A migration is an engineering project with a real opportunity cost. If your data team is already underwater on other priorities, a forced migration done badly costs more than another SA renewal cycle. The right move is the assessment now, the project when you can staff it — not a panicked cutover because the ESU invoice arrived.

The decision framework is simple: inventory first, triage second, and let the numbers — not ideology — pick the route per database. Most estates end up hybrid: a migrate cohort, a re-platform-for-runway cohort, and a stubborn remainder that stays on SQL Server for legitimate reasons. That's a fine outcome. What isn't fine is paying Enterprise licensing for all of it because nobody did the triage.