Choosing Between SQL Server and PostgreSQL by Project
Two relational databases, two different sets of projects.
Mert Celal Yılmaz · Full Stack Developer · Updated:
Which database ends up on a project usually comes down to the team and the infrastructure, not the language itself. SQL Server and PostgreSQL are both relational: data lives in tables, you query it with SQL. Day to day, for basic CRUD work, they're close enough that the real differences show up more in licensing, tooling, and a handful of performance or feature details rather than in how you write your queries.
I run SQL Server on an apartment management system and a corporate business management platform. YODER, a donation platform, and a hotel reservation AI assistant run on PostgreSQL instead. Which one gets used usually comes down to the infrastructure and the team on that particular project; either way, I go through EF Core and set up the repository layer in Clean Architecture the same way regardless.
My first real hands-on time with PostgreSQL was in university, building the database side of an e-commerce web app with a dynamic cart and order management. Everything from adding an item to the cart to updating an order's status ran through relational modeling I designed myself back then.
The difference I actually run into day to day is how string comparisons behave: SQL Server's default collation is case-insensitive, while PostgreSQL is case-sensitive out of the box. That means the exact same LINQ query through EF Core, even something as plain as an equality filter on a text field, can return a different result set depending on which database it's pointed at, and that's the kind of thing you'd rather catch in a test than notice in production.
EF Core hides a lot of that difference, but not all of it, and assuming a project ports from SQL Server to PostgreSQL by just swapping the connection string is a common way to get burned. Outside of case sensitivity, anywhere raw SQL is used, or engine-specific details like sequences and computed columns, still needs a manual look during migration. Running different modules of the same platform on different database engines on purpose isn't something I reach for either, unless the team or the infrastructure genuinely forces it, since maintaining two separate backup and monitoring setups is just extra operational weight for no real gain.