It was pretty nerve-wracking to announce ProGet’s shift from SQL Server to PostgreSQL. As a former diehard Microsoft SQL Server fan, I somewhat expected an inbox filled with hate mail. But instead, the response was overwhelmingly positive.

Although most of the respondents favored the shift, 29.3% still preferred SQL Server. But it isn’t out of some zealous loyalty to a favored database product. Instead, their DBAs don’t support PostgreSQL. And ProGet’s shift would mean more work for them.

That’s when it hit me. As a product company, we totally dropped the ball here. ProGet’s database should NOT be your team’s burden, it’s ours. There’s no good reason for your DBAs to even think about ProGet, let alone spend their limited time managing a part of it.

In this article, I’ll walk you through where we went wrong and how ProGet 2025+ with PostgreSQL will correct these mistakes and significantly reduce your total cost of ownership (TOC).

What’s the ProGet Database For, Anyway?

Unlike most databases that a DBA is responsible for, the ProGet database isn’t some sprawling, mission-critical dataset like an ERP or financial records. Instead, it’s just:

• File/Metadata Index: A quick look-up for packages, containers, and assets you’ve added to ProGet that’s faster to search/read than the files on disk
• Software Configuration: Users, permissions, API keys, replication settings – basically whatever you can configure in the UI is stored in the database

The database is obviously a key component of ProGet, but ultimately it’s just persistent storage that may as well be data files stored on disk. It’s not something end-users should ever have to manage.

SQL Server: The Wrong Choice in 2025

When we launched our first product almost fifteen years ago, SQL Server seemed like the only real option. Not only were we experienced in it, but Microsoft released a free version that was relatively easy to install. And there weren’t a lot of other options for a .NET shop like ours.

But today? It’s the wrong choice, especially for a product company like Inedo.

⚠ So Damn Expensive – Even When “Free”

72.4% of survey respondents run ProGet on a shared SQL Server instance, instead of the SQL Server Express that can be installed with ProGet. Even if, somehow, you had no licensing costs with your shared SQL Server, the real cost is the time and effort it demands from you and your team.

When ProGet’s database is hosted on a shared server, its performance can drag down other databases—or take a hit itself if something else hogs resources. This becomes the DBA’s problem, and is just another thing to add to their workload.

Although SQL Server was easy for us to code against, it effectively shifted the maintenance and support of a database engine to our users. Just as you shouldn’t have to manually clean up package files, your team shouldn’t have to babysit ProGet’s database either.

⚠ Maintenance & Upgrades: More DBA Work

A surprising 61.3% of survey respondents perform some kind of routine maintenance on the ProGet database, whether that’s monitoring performance, updating statistics, or rebuilding indexes. Most of this work is performed by DBAs.

⚠ Backup & Restore: More Complex

For a proper backup of ProGet, you need both the database and content files on disk. When SQL Server is installed on the same server as ProGet, this can be done with a VM snapshot – but only 22.4% of respondents do that.

Everyone else? They’re stuck coordinating a database backup job with the DBA team, and a file backup job with the IT team. Restoring the database is the same headache.

⚠ Slower Support: Locked Out by Design

When DBAs manage the database, ProGet administrators rarely get dbo access. That locks them out of meaningful troubleshooting—no quick queries to diagnose issues or patch a data problem. Instead, they’re stuck waiting on a DBA to run a query, which can delay support responses significantly.

⚠ Inheriting SQL Server’s Bugs

To make matters worse, SQL Server’s problems become our problems. And these have just gotten worse with Microsoft effectively abandoning the SQL Server ecosystem. We’ve seen regressions in newer versions cause issues in ProGet, and we have to maintain a litany of workarounds to support older, unpatched SQL Server versions.

PostgreSQL: Reducing Your TOC with ProGet 2025+

The database is a core part of ProGet, and we should be the ones maintaining it—not you. PostgreSQL makes that possible. Just like we handle platform upgrades (.NET 6 to .NET 8) and internal libraries, we’ll take care of the database engine automatically.

Starting with ProGet 2025, you’ll have two primary database hosting options:

• Embedded: For single-server ProGet, a custom build of PostgreSQL that’s been security-hardened, stripped of unneeded features, and optimized for ProGet will run on the same server (or Docker container) as ProGet itself
• InedoDB: For clustered (multi-server) installations, the same custom build of PostgreSQL will be packaged as “InedoDB” and installable on Windows (or used as Docker container); this will be used exclusively by ProGet servers in the cluster

In both cases, ProGet handles upgrades, backups, and maintenance of the database.

This custom build of PostgreSQL means that we can test and control database engine versions so you don’t have to. And like with all other ProGet components, when you rollback to a previous version of ProGet, the custom build is also rolled back.

For clustered setups, you’ll need to update InedoDB occasionally, but we’ll mention that in the upgrade notes and/or software. We’ll also offer an External Database option that’s primarily intended for cloud-based setups like Azure PostgreSQL.

How to Migrate to the New Database

We’re going to be making this transition as smooth as possible. Both SQL Server and PostgreSQL will be fully supported in ProGet 2025 and 2026, giving you plenty of time to evaluate and explore the migration. And we’ll even be rolling out a PostgreSQL preview in ProGet 2024 in the coming weeks.

Database Export/Import

One feature we’ll be shipping soon in ProGet 2024 is a database export that will allow you to export the ProGet database (SQL Server or PostgreSQL) as a single compressed file.

This is a little different than a backup, in that it’s intended to be imported as a PostgreSQL database on a new installation. This will not only make trying out the new PostgreSQL database much simpler, but help in the long run with server migration and even support.

Automatic Migration Wizard

ProGet will also offer a built-in migration tool that looks something like this:

We expect most users will switch to using this tool. If there are any issues, it’ll be easy to switch back to SQL Server.

Summary: Thanks for the Feedback

I truly appreciate all of your feedback, especially all of the comments and additional context. It really pushed me to rethink the approach.

In retrospect, we should not have let ProGet’s database become your maintenance burden, and ProGet 2025+ fixes that. With PostgreSQL, we’ll be able to handle the database engine maintenance and make ProGet even easier to maintain.

If you’ve got any thoughts on the new options or have more concerns about the switch, don’t hesitate to let me know.