Starting in ProGet 2025, we will begin our multi-year journey of saying goodbye to Microsoft’s SQL Server. In its place, we will be switching to an embedded distribution of PostgreSQL with the option to use your own PostgreSQL Server. We also plan to support both databases for at least two major releases, to make the transition as painless as possible. There’s no rush to migrate immediately.

Although we continue to support SQL Server for a while, this is a big change and I want to make sure we do it right, with as much user input and feedback as possible. I created a corresponding PostreSQL Switch Survey just for that. Ultimately, I want this change to translate to big cost savings for you (if you’re licensing SQL Server) and much simpler installation management (if you’re using SQL Server Express).

In this article, I’ll talk about how this change impacts you and give some background into why we’re switching. I’ll also try to convince you to fill out the PostgreSQL Switch Survey to give me feedback.

UPDATE: check out Reflecting on Your Feedback & Improving in ProGet 2025+ to see the survey results and our evolved position

How the Database Switch Impacts Our Users

As you might expect, a database platform change is not something we could (or should) do automatically when you upgrade ProGet. Instead, after you upgrade to ProGet 2025, you’ll need to make two key decisions: where your database will be hosted and when you’ll migrate the data.

Database Hosting: Embedded or External Server

In most cases, we recommend using the embedded database. This will be a full-fledged PostgreSQL server that’s “embedded” in the ProGet installation directory. You’ll be able to control this server from within ProGet and even use popular PostgreSQL tools to connect and query the database. But it will be maintenance free and easier to back up than SQL Server Express.

If you’ve configured ProGet as a Server Cluster, you’ll need to use an external PostgreSQL server that all nodes can connect to. This may seem a bit scary if you’re a Microsoft shop with a DBA team that oversees databases, but you can keep this PostgreSQL installation completely dedicated to ProGet. We’ll do our absolute best to show you how to manage that server and we will have upgrade guidance as well.

Database Migration: Sooner or Later

We plan to build a database migration tool that will do a one-way, one-time copy of all data in your SQL Server database. This will take some time: minutes, maybe an hour, or maybe more. We’ll know once we build and test it against large databases.

Once you switch to PostgreSQL, you can switch back to SQL Server… but new data will not be there. It’ll be like restoring a database backup, and you would do this if there’s some kind of showstopper bug.

Speaking of bugs, we are anticipating them – and you should too. As you’ve probably noticed, we fix bugs really fast. When it comes to database code, we can usually send a patch script.

New Features: Likely PostgreSQL Only

We are only planning to maintain dual-database compatibility for two major releases (ProGet 2025 and ProGet 2026). New features that we ship in ProGet 2026 may not be available unless you switch to PostgreSQL.

Let me know if you have any thoughts or concerns about this migration process in the PostgreSQL Switch Survey.

Why not just support both databases?

We’ve gone down the “dual-database” road before: ProGet 5.0 (2017) included an experimental option for using PostgreSQL on then-experimental Linux edition. But it was rough for everyone, and we decided to remove it a few years later.

Supporting two databases means twice as much database code to maintain. We have hundreds of tables and databases objects… and that’s a lot more room for bugs, and ultimately a lot more time/effort that needs to go into developing and testing.

Although we plan to support both databases for a short period again, it’s not something we will do indefinitely. While I know many users will prefer one database over another, there’s no value in offering that – the cost is way to high given the benefit.

But what about using ORMs, EntityFramework, or another?

Our software’s multi-layer architecture relies on having a lot of the code kept in the database as views and stored procedures. This means that our product is as integrally tied to a database engine as it is to a programming language like C#.

I’m very familiar about so-called “database neutral” technologies, and have written plenty of technical articles on them over my career. While I’m always up for a debate on the technical merits of our architecture (especially over a whiskey), the reality is we could never make such a drastic change to our products.

It’s not even worth entertaining. Simply “translating” our database code from T-SQL to PL/pgSQL will be a lot of work, and those languages are basically the same. If we were to move away from using database code, that would mean translating everything to C#… which would be a multi-year, painful undertaking that no one would want. Especially our customers.

Why We Decided to Switch to PostgreSQL

This should probably be a separate article, but let me give you some context first on why we’re switching. I’ve spent almost my entire career as a diehard Microsoft SQL Server fan. Nearly twenty years ago, I built Express Agent to help others switch to the best database ever (SQL Server 2005), and over the years, I’ve continued to advocate and attend community events as much as possible.

All that said, SQL Server is becoming a nonviable product headed towards obscurity. It obviously still functions, but so does Classic ASP and COBOL. SQL Server’s peak was long ago, and it’s been a decaying product for years now. It’s a shame, because I really liked SQL Server. But so goes the way of technology.

The problems go beyond SQL Server itself – it’s the whole ecosystem. For example, Microsoft killed the vibrant SQL Saturday community (i.e. PASS) a few years ago. It’s in the hands of Redgate now, but without Microsoft’s support, it’ll always be a shadow of the past.

I’m not the only longtime SQL Server user talking about this – in fact, it’s been known in the community for years. SQL Server demigod Brent Ozar offered a similar take:

SQL Server shouldn’t be used for most new applications you build today. If you have an existing app built on it, you’re kinda stuck, but if you’re building a new application, you should use Postgres instead.

Whatever the case, we can no longer tie our future to SQL Server. The decreasing quality and increasing bugs throughout the ecosystem are causing a serious disruptions to our userbase. For example, Issue #2378 effectively prevents SQL Server from being used with .NET8 on Linux. It’s still not fixed as of today.

I can’t really blame Microsoft for this neglect. I wouldn’t want to maintain SQL Server either, especially if if I could charge customers the same amount for hosting Postgres, a database that someone else maintains.

Fortunately, the PostgreSQL community is thriving and growing, and we will join it as yet another SQL Server refuge.

Working with PostgreSQL in Your Enterprise

As I mentioned earlier, you won’t need to worry about database administration at all when you choose the embedded option. But even if you go with an external PostgreSQL, that doesn’t mean the whole enterprise needs to become a PostgreSQL shop – instead, you can just think of PostgreSQL as a thing you need to install/configure when setting up a cluster.

I think this will make your life a bit easier, especially if you have a DBA team that manages the SQL Server that ProGet uses. Instead of having to coordinate with them for backups and restores, you’ll have full control over over the database component – and we’ll have guides for all the things you’ll need to do, like backup, restore, security, maintenance, and so on.

Surprisingly Simple: PostgreSQL Installation and Configuration

We’ll have some more content on this later, but as a longtime SQL Server user, I was surprised how simple PostgreSQL’s installation is – especially in the context of hosting a ProGet database.

SQL Server has some has fairly deep “hooks” into Windows operating system. It seems to do a whole ton of things when running the installer and it takes its sweet time. And then you install SQL Management Studio. That’s fine, and what we all expect.

PostgreSQL, on the other hand, doesn’t do much when you install it. Some files get copied to the program directory and a “data directory” is initialized. This effectively contains the “master” database and all configuration like usernames, ports, and so on. Similarly, there’s a GUI tool called pgAdmin, which is basically like SSMS.

Conceptually, configuration is about the same: the GUI tool lets you control the service and set all sorts of different database properties. You can also “poke around” with the databases and query tables, run stored procedures, and so on.

If your PostgreSQL server is dedicated to ProGet, is unlikely you’d need to do anything beyond the basics. There’s also not a lot to worry about on the security side of things; the only user/access would be your ProGet servers, and you can block network traffic from everything else if you’d like.

The Vast PostgreSQL Ecosystem

Unlike Microsoft-centered SQL Server ecosystem, there are a lot more players in the PostgreSQL ecosystem. The downside to this is too many options, ranging from hobbyists selling shareware to midsize vendors like Redgate, all the way up to Amazon and (surprisingly) Microsoft.

If your organization already uses PostgreSQL, you probably know all this. But if you’re learning about PostgreSQL in this article, it’s going to seem like an intimidating ecosystem to jump into.

One vendor I wanted to point out is EnterpriseDB; they will not only provide “Microsoft-level support” for PostgreSQL, but they can go beyond that and offer Remote DBA services. I don’t think any of this is necessary if you have a PostgreSQL server dedicated to ProGet, but it might put some organizations at ease.

Next Steps: Other Products and Your Feedback

At this time, I’m only thinking about ProGet 2025 – but this is obviously something we will apply to BuildMaster and Otter. Maybe we’ll look to do that in 2026. It really depends on how challenging the switch is for ProGet.

Please take a moment to fill out the PostgreSQL Switch Survey. Even if you don’t care one way or another, I’d love to know that.

It’s very possible that I’m overthinking this switch, but I also want to make sure that I understand and address all of your concerns. If you think our plan is doomed to fail – or we’re missing something big – don’t be shy, let us know.