SQL Server to PostgreSQL: Why Switch, and What to Expect

You know SQL Server deeply — the type system, the quirks of T-SQL, what a bad execution plan smells like. Here's the good news up front: almost all of that transfers to PostgreSQL. This series is a translation guide for experienced developers, not a beginner course. You already know the concepts; we'll give you their Postgres names and flag what's genuinely different.

Why teams make the move

The honest first answer is money. SQL Server Standard and Enterprise are licensed per core, and in the cloud — where every core is metered by the hour — that line item gets uncomfortable fast. PostgreSQL is free. Not free-tier free: actually free, with no edition matrix, no CALs, and no license audit ever.

The second answer is momentum. PostgreSQL is open source under a permissive license, it has become the default database for startups, and every major cloud runs it as a managed service: Amazon RDS and Aurora, Azure Database for PostgreSQL, Google Cloud SQL, plus a wave of newer platforms built entirely around it. When you learn Postgres, you learn something you can take to any employer and any cloud.

And a personal answer: this isn't theoretical for me. The server that delivered this very page runs PostgreSQL in production, right alongside .NET applications. I've lived on both sides of this migration, and this series is the guide I wish I'd had.

What transfers unchanged

More than you might fear. The relational model, primary and foreign keys, joins, constraints, transactions, views — identical in spirit and mostly identical in syntax. The large majority of the SQL you write every day runs on PostgreSQL with no changes at all.

Most importantly, your design skills transfer completely. Normalization, entity modeling, choosing keys — none of that is vendor-specific. If you've followed this site's database design series, every step of it applies to PostgreSQL word for word.

What's genuinely different

Here's the honest list — and the roadmap for this series. Each of these is one part:

• The containment model. Instances, databases, schemas, logins and users map differently than you'd guess — and cross-database queries will surprise you. Part 2.
• Data types. boolean is real, NVARCHAR retires, and one timestamp decision causes most migration bugs. Part 3.
• The dialect. T-SQL and PostgreSQL SQL agree on the core and diverge in the daily phrasing — Part 4 is the cheat sheet.
• Stored procedures. PL/pgSQL is a different language than T-SQL, with functions doing most of the work. Part 5.
• No clustered indexes, and MVCC. PostgreSQL stores tables as heaps and handles concurrency without readers blocking writers — which changes some performance instincts. Part 6.
• Backup and restore. No .bak files; a different (and in some ways nicer) story. Part 7.
• The .NET connection. Npgsql, EF Core, and actually moving an app over. Part 8.

A project with momentum

PostgreSQL ships a major version every year, and the current one — PostgreSQL 18, released in September 2025 — is a good illustration of the pace. It introduced an asynchronous I/O subsystem that delivers up to 3× faster reads on some workloads, skip scans that let multicolumn indexes serve more queries, and a built-in uuidv7() function that we'll meet properly in the data types part. This is not a database coasting on its reputation.

Getting a Postgres to play with

The fastest route is Docker — one line and you have PostgreSQL 18 running locally:

docker run --name learn-pg -e POSTGRES_PASSWORD=yourpassword -p 5432:5432 -d postgres:18

Your new toolbox

SSMS doesn't speak Postgres, so you'll adopt a small set of replacements. The one that feels strangest at first — and becomes the one you love — is psql, the command-line client. For a GUI, pgAdmin ships with Postgres, and many .NET developers prefer DBeaver, which feels closest to SSMS.

That's the lay of the land: your skills come with you, the price tag disappears, and the differences are learnable in a focused week. In Part 2 we start with the biggest mental-model shift of all: what instances, databases, schemas, and logins become on the other side.