SQL Server versus PostgreSQL needs a full-cost comparison

A license bill rarely decides the future of a corporate database by itself. The choice becomes clear when the three-year increase for the next set of cores and a standby node exceeds the cost of migration, dual operation, and application risk. Before that point, PostgreSQL may look free but turn into an expensive project. After it, SQL Server Standard may remain technically convenient but become financially hard to defend.

I compare these options against the same working topology, not the price of one database product. The estimate includes primary and standby nodes, a test environment, people, support, downtime, code changes, and room for growth. Comparing a SQL Server license on a powerful server with PostgreSQL on one small virtual machine produces an accurate and useless table.

The license cost rises in steps with the core count

SQL Server Standard under the Per Core model is sold in two-core packs, and the computing resource assigned to the instance must be licensed. Microsoft's licensing guidance sets a minimum of four core licenses per physical processor. Licensing an individual virtual machine requires active Software Assurance or a subscription, so the vCPU count in the hypervisor cannot automatically become the final number of licenses to purchase. The contract, product version, and virtualization rights need review by the license supplier.

Microsoft's public SQL Server 2022 pricing page provides a useful control figure: the estimated retail price of SQL Server Standard is USD 3,945 for a two-core pack. Microsoft explicitly calls it an Open No Level estimate, not a commercial quote. At that rate, one production instance gives this arithmetic:

• 8 assigned cores: 4 packs, an estimated USD 15,780.
• 16 assigned cores: 8 packs, an estimated USD 31,560.
• 24 assigned cores: 12 packs, an estimated USD 47,340.

This is not a final estimate in Kazakhstan. It excludes the tenge exchange rate, taxes, contract discounts, Software Assurance, Windows Server, and the standby node. The figures make a different point. Doubling the cores doubles the license line even when the database currently uses only half the capacity. PostgreSQL has no such step: the PostgreSQL License permits use, modification, and distribution without a fee or written agreement.

First record the resource the database will actually receive, not the server model shown in a sales proposal. This query provides a technical starting point for a running SQL Server:

SELECT
    cpu_count AS visible_logical_cpu,
    hyperthread_ratio,
    physical_memory_kb / 1024 AS physical_memory_mb
FROM sys.dm_os_sys_info;

SELECT
    name,
    compatibility_level,
    recovery_model_desc
FROM sys.databases
WHERE database_id > 4
ORDER BY name;

The first result row has the shape visible_logical_cpu | hyperthread_ratio | physical_memory_mb, followed by the user database list. The DMV shows the resource visible to the instance, but it does not interpret the license agreement. Match the result against the VM configuration, physical processor count, contract, and passive-node rights.

Server plus CAL only wins with countable users

The Server plus CAL model can cost less than Per Core when the number of users or devices is small, stable, and provable. On the same Microsoft page, the reference price for a Standard server license is USD 989 and one CAL is USD 230. The simplest boundary is calculated like this:

PerCore = ceil(licensed_cores / 2) * price_2core_pack
ServerCAL = server_count * price_server + cal_count * price_cal
break_even_cal = floor((PerCore - server_count * price_server) / price_cal)

For one eight-core server at these reference prices, Per Core costs USD 15,780. Server plus CAL remains cheaper up to about 64 CALs, and the next CAL moves it beyond that boundary. For 16 cores, the calculated boundary rises to about 132 CALs. These figures check the order of magnitude and do not constitute a purchase quote.

The main trap is not arithmetic but the definition of access. Microsoft's Multiplexing Licensing Guidance says a connection pool, web application, or intermediary service does not reduce the required CAL count. A user who reads or changes SQL Server data through a business application may count as accessing the server indirectly. Do not use the number of database accounts or concurrent connections. Count the users and devices that receive data through an automated process.

Server plus CAL makes sense for a closed system with known employees, such as an internal application at a limited number of workstations. A public portal, mobile application, integration bus, or growing terminal fleet makes that inventory fragile. Per Core costs more at the start in such an environment, but it removes the access recounting risk. PostgreSQL removes this type of license inventory altogether.

PostgreSQL has no license bill but still needs operations

A zero PostgreSQL license price does not mean a zero-cost database. The PostgreSQL License permits free use while expressly disclaiming any obligation to provide maintenance, updates, or fixes. That boundary is honest: the community publishes the code, while the system owner or its contractor remains responsible for the working service.

A three-year PostgreSQL model must include administration, backups with restore testing, monitoring, upgrades, extension management, and on-call coverage. SQL Server needs the same lines. The difference lies in the skills the team already has and the tools it has standardized. A SQL Server license does not replace operations, and a free PostgreSQL package does not create them automatically.

Use this formula to compare equivalent options:

TCO_36 = licenses
       + infrastructure
       + vendor_support
       + internal_labor
       + migration_project
       + parallel_run
       + expected_downtime_loss
       + training
       + exit_cost

Calculate expected_downtime_loss as the probability of a material failure multiplied by the agreed cost of its impact, rather than as a frightening round number. exit_cost includes data export, automation transfer, and support termination. If one option receives a standby node and round-the-clock coverage, the other must receive a comparable service level.

For a new system, PostgreSQL often wins immediately because there is no old T-SQL, migration window, or parallel operation. For an existing system, migration_project + parallel_run can outweigh license savings for several years. The calculation period should therefore match the hardware refresh horizon, usually three or five years, rather than one budget year.

Calculate each year separately because a one-time purchase and recurring expenses behave differently. In year zero, SQL Server carries licenses and implementation, while PostgreSQL carries migration, training, and the parallel environment. In later years, both options incur people, support, and infrastructure expenses, and SQL Server may need new licenses when computing resources increase. Mark licenses already purchased as sunk costs: they matter to cash flow, but they should not make a future option look artificially cheaper.

The migration payback period equals the project and parallel-operation cost divided by the confirmed annual expense difference. If the project is estimated at M tenge, the parallel period at P tenge, and annual savings after the move at S tenge, the period is (M + P) / S. When S is negative or close to zero, the database change does not pay for itself. It then needs another application benefit with its own valuation.

Test sensitivity against four variables: the exchange rate for licenses, core growth, team rates, and the volume of manual conversion. Change one assumption at a time. This shows what actually reverses the choice. If PostgreSQL wins at every exchange rate but loses when conversion hours double, the code needs a deeper audit. If SQL Server wins only without a standby node, the argument concerns an understated availability level rather than the database.

Show all prices either with tax or without it on both sides. Convert tenge expenses and foreign-currency licenses using the same agreed exchange-rate scenario. Do not assign support that the organization will pay regardless of the database entirely to one option. Include only the difference. This accounting looks dull, but it survives a finance committee review.

Application compatibility can end the comparison

If the application vendor certifies only SQL Server, the choice has already been made at the application layer. PostgreSQL's formal ability to store the same tables changes nothing. An unsupported database can remove upgrade eligibility and turn every incident into a dispute between contractors. First obtain a written matrix of supported databases, versions, drivers, and availability modes from the application owner.

For custom software, compatibility splits into several checks. Plain tables, indexes, constraints, and simple queries usually move with manageable work. Risk rises when an application depends on T-SQL, SQL Server Agent, Database Mail, CLR, linked servers, table-valued parameters, optimizer-specific hints, SSIS, or reports that rely on Microsoft behavior.

The AWS Schema Conversion Tool documentation shows the extent of the differences well, even though the tool targets AWS services. It does not promise a mechanical move. SQL Server Agent and Database Mail need an emulation pack, procedures may become functions, duplicate index names need unique replacements, and some system functions become compatibility wrappers. I would treat every such object as a future dependency that needs testing and maintenance, not as a conversion percentage.

Collect actual dependencies before debating licenses:

SELECT
    o.type_desc,
    QUOTENAME(SCHEMA_NAME(o.schema_id)) + '.' + QUOTENAME(o.name) AS object_name
FROM sys.objects AS o
JOIN sys.sql_modules AS m ON m.object_id = o.object_id
WHERE m.definition LIKE '%OPENQUERY%'
   OR m.definition LIKE '%MERGE%'
   OR m.definition LIKE '%xp[_]%'
   OR m.definition LIKE '%sp[_]OACreate%'
ORDER BY o.type_desc, object_name;

SELECT name, enabled
FROM msdb.dbo.sysjobs
ORDER BY name;

An empty result does not prove compatibility, but a nonempty one immediately creates a review queue. Scan repositories separately for T-SQL, connection strings, ORM providers, and queries assembled while the application runs.

Migration costs more than moving tables

Migration cost follows the amount of behavior tied to SQL Server, not the database file size. A terabyte of plain tables can be more predictable to move than a small database with hundreds of procedures, Agent jobs, and reports. Data volume primarily affects copy duration and the cutover window. Platform-specific code volume determines months of engineering work.

Split the project into priced work packages:

1. Inventory covers schemas, database code, jobs, integrations, reports, permissions, RPO, and RTO.
2. Conversion replaces data types, T-SQL, procedures, functions, and operational jobs.
3. Data transfer includes the full load, change delivery, and validation of rows, totals, and control samples.
4. Application validation covers functional, load, locking, and failure scenarios.
5. Cutover includes rehearsal, a change freeze, abort criteria, and return to the source system.

Do not hide application repair inside a line called "database migration." Differences in name casing, NULL behavior, collations, dates, IDENTITY, and sequences may appear only in an uncommon business-process branch. PostgreSQL documents its own types and behavior, but SQL standards compliance does not make it interchangeable with T-SQL.

The cost of downtime does not equal the duration of the copy either. In a full move, the window includes stopping writes, final synchronization, verification, application startup, and the decision to proceed or roll back. If the business permits only a short window, change capture, repeatable runs, and a more involved rollback plan add work. Buying this work is often wiser than attempting a heroic overnight cutover without a rehearsal.

Keep both systems running at least through a period that covers month-end close, a bulk report, or another infrequent cycle. That is where rounding, time-zone, and query-plan differences emerge. Turning off SQL Server immediately after users log in successfully is dangerous, while paying for it indefinitely without an exit date is expensive.

Data validation must prove meaning, not just equal row counts. Compare object and row counts, totals for monetary fields, minimum and maximum dates, the proportion of NULL, business-key uniqueness, and complete sample documents. For large tables, divide checks by primary-key range or date so an error does not disappear in the grand total. Test Cyrillic strings, spaces, empty values, old encodings, and dates at a time-zone boundary separately.

Record which system remains the source of truth at every stage. Dual writes look like a convenient way to reduce risk, but they quickly create conflicting sequences, different commit moments, and a difficult rollback. Unless there is a proven need, it is safer to keep writes in SQL Server, move changes to PostgreSQL, validate reads, and then perform one controlled cutover. If reverse synchronization is required, design it as a separate feature with conflict-resolution rules.

The rollback criterion must be measurable: loss of committed transactions, a p95 breach, an incorrect control report, or failure to complete a business operation within the set time. "If something goes wrong" leaves the decision to a tired manager in the middle of the night. Name the person who declares the rollback and the last moment when a return still fits the window.

Specialists change the economics after launch

Specialist availability cannot be reduced to the number of CVs naming a database. You need someone who has restored your topology, investigated locks, configured replication, and completed an upgrade without breaking the RPO. A developer who has written PostgreSQL queries and an engineer responsible for round-the-clock operations present different risks. The same applies to a SQL Server administrator without Always On experience.

For the Kazakhstan market, collect fresh data over one week because vacancies and rates change faster than the life of this article. Send the same on-call description to three local contractors, count suitable internal staff, and check the replacement hiring time. The request should include database version, volume, node count, support schedule, RPO, RTO, backups, and expected release frequency.

Compare four numbers: the monthly cost of the main team, on-call coverage, a one-off complex intervention, and the time required to hire a replacement. A high rate for an experienced PostgreSQL DBA may still cost less than recurring license expense. A cheap specialist without recovery experience can erase that saving in one prolonged outage. The same logic applies to SQL Server, although an existing Microsoft team often lowers the cost of moving between tasks.

Count training as working time rather than the course fee. After a course, the team still writes procedures, runs a practice restore, and works through its first upgrades with checks. Until a second person can restore the service without the configuration author, the organization depends on one employee, and that is a financial risk.

High availability needs the same topology on both sides

A single primary without a standby cannot be compared with a two-node setup. A SQL Server Standard basic availability group supports one database and one secondary replica, and it does not allow reads or backups on the secondary. Microsoft Learn lists these limits. If an application needs several databases to fail over together or wants to offload reads to a replica, Standard may require a different architecture or a move to a more expensive edition.

PostgreSQL supports physical streaming and logical replication, but that does not produce a finished cluster. The team must choose a failover mechanism, quorum storage, connection routing, WAL archiving, lag monitoring, and a procedure for returning the former primary. Extensions and cluster managers also need versions, owners, and upgrade procedures.

Standby SQL Server licensing depends on purchased rights, Software Assurance, node role, and use case. Do not hard-code an assumption that a passive node is always free. Before purchasing, draw every physical server, VM, container, and access path, then obtain a written supplier calculation for that diagram.

The same acceptance test for both databases is more useful than a feature list. Shut down the primary in a test environment and measure the loss of committed transactions, time until writes recover, and operator actions. Then restore the database from backup to a separate host. If the team cannot demonstrate both results, the stated RPO or RTO exists only in a document.

Performance is not the licensed core count

More cores do not guarantee a proportionally faster SQL Server, but under Per Core they will almost certainly increase the licensing basis. Before buying, measure whether the system is constrained by CPU, memory, storage, locks, or bad query plans. Buying eight more cores for a database waiting on disk or a held transaction makes the license dearer and leaves the delay in place.

Capture a profile for at least a normal day, a period close, and the peak operation. Gather processor load, wait times, reads and writes, storage latency, active data-set size, log growth, long queries, and locks. For a virtual machine, add hypervisor CPU readiness and actual memory limits. A monthly average hides the short peak that prompted the business to request new equipment.

Reducing assigned vCPUs can sometimes produce two savings: it lowers SQL Server cost and forces the team to repair expensive queries. Do not reduce resources before a test. Run peak load against an application copy and retain p95 and p99 response times, throughput, and headroom before saturation. License optimization that creates an unbounded queue costs more than additional core packs.

PostgreSQL removes the per-core license penalty but does not change workload physics. It still needs memory, suitable indexes, statistics maintenance, table-bloat control, and storage with predictable latency. The two databases choose different plans for the same data, so a multiplier cannot transfer SQL Server test results to PostgreSQL. Run the same business operations and compare system limits rather than one impressive query.

Separate vertical growth from workload separation. Reports, integrations, and archival operations can move away from the primary path if the application and freshness requirements allow it. For SQL Server, this may reduce the expensive core count on the main instance, but a new instance also needs a license check. Additional PostgreSQL nodes do not create per-core fees, but they add replication, monitoring, and failure procedures.

A hardware estimate should record assigned cores, frequency, memory, storage type and latency, network paths, and capacity headroom rather than a processor brand. The same profile can then load both proposals. Otherwise, the SQL Server supplier may propose fewer fast cores to control licensing, the PostgreSQL supplier may propose more moderate cores without a fee, and the committee will compare unlike servers.

A pilot turns the argument into an estimate

A pilot should test the costliest risk, not demonstrate that both databases can run SELECT 1. Use a schema copy, representative data volume, two or three heavy queries, one job, one report, and an application path with a complex transaction. Remove personal data or use a synthetic set with the same value distribution.

Write acceptance criteria before the run:

• Schema conversion: number of objects requiring manual repair, agreed maximum, cost in person-days, database architect as owner.
• Peak load: p95 response time, application SLA, cost in person-days and hardware, application team as owner.
• Change transfer: lag behind the source, threshold below the cutover window, cost in person-days, DBA as owner.
• Recovery: actual RPO and RTO, contractual values, infrastructure and on-call cost, operations as owner.
• Rollback: time to return to SQL Server, window limit, cost in person-days, cutover owner.

After the pilot, replace conversion percentages with an object list and hour estimates. Add 20 to 30 percent to unfamiliar work classes as an estimation reserve, but do not automatically add it to the whole budget. If a contractor cannot explain the risk covered by the reserve, it is simply hidden margin.

Stop the PostgreSQL pilot if the application vendor will not support the result, a critical feature requires permanent emulation, or the transfer window still fails after two serious attempts. Recalculate the SQL Server pilot if core growth, a standby site, or CALs push the three-year budget past its limit. Stopping a bad option saves more than carrying an attractive demonstration into a production failure.

The answer changes with the workload

For a new custom system without a hard T-SQL dependency, PostgreSQL usually offers cleaner economics. The team writes portable SQL from the start, builds operations around the chosen database, and avoids paying for two platforms in parallel. The saved license budget is better spent on redundancy, observability, and a second trained administrator.

For a purchased accounting, medical, or industry application certified only for SQL Server Standard, migration for the license alone is often a mistake. The cost of an unsupported application exceeds the database saving. Optimize licensed cores, workload isolation, the CAL model, and server life cycle without changing the supported foundation.

For an internal system with a small fixed employee group, check Server plus CAL. Per Core or PostgreSQL is usually simpler for a portal or many indirect users because CAL inventory becomes its own control process. Recalculate analytics workloads early as core counts grow: the SQL Server license line rises with computing resources, while moving many platform-specific procedures becomes more expensive the longer the decision is delayed.

A system integrator should not select its favorite database. It should produce one register of assumptions. GSE.kz can compare server topology, software, integration, and support in one project while remaining vendor neutral. That register shows licenses, hardware, migration work, and operations separately, so a discount on one line cannot conceal growth in another.

Money becomes decisive after exit costs are included

The financial boundary has a simple test: the accumulated annual expense difference must repay migration, parallel operation, and risk before the next planned upgrade. Calculate it for baseline, slow-growth, and peak scenarios. If PostgreSQL pays back only with a perfect migration and maximum core growth, the choice is fragile. If it repays a conservative migration estimate within an acceptable period, the license difference has become decisive.

Keep SQL Server Standard when application support is mandatory, the existing team is strong, and licensed cores and CALs are predictable. Choose PostgreSQL when the application permits the move, computing demand is growing, the team can own operations, and the pilot confirms performance and failover. An old license does not make future cores free, just as the absence of a license invoice does not make a migration safe.

The first working document should fit on one page: node diagram, cores or CALs, three-year TCO, incompatibility list, migration price, RPO, RTO, and the parallel-operation exit date. Ask the finance, application, and operations owners to sign the assumptions themselves. The brand argument usually ends there because everyone can see which risk the organization is paying for.