Category: Versions

Peter Eisentraut lays out the explanation:

Upgrades between PostgreSQL major versions are famously annoying. You can’t just install the server binaries and restart, because the format of the data directory is incompatible.

Why is that? Why can’t we just keep the data format compatible?

Perhaps surprisingly, the data format is actually mostly compatible, but not completely. There are just a few things missing that are very hard to solve.

Perhaps I’m not as sympathetic as I should be to the core developers, but there are other RDBMS platforms that have a direct path for upgrade from version to version, so it’s hardly insurmountable.

Brent Ozar announces the numbers:

Every quarter, we publish adoption rate data showing how quickly people are adopting new versions of SQL Server. Today it’s time for the fall 2024 version of our SQL ConstantCare® population report.

SQL Server 2019 is still the king of the hill with almost 3X more market share than any other version!

Here’s how adoption is trending over time, with the most recent data at the right:

Every time I do this, I always lay in the caveat that this is a specific example of a specific customer base for a specific product and so there will be differences from the broader population of SQL Server/Azure SQL installations. But every time, I also say that this is still a useful indicator to review over time.

Given that Microsoft has announced SQL Server 2025, my guess is that 2022’s adoption curve will look a lot like 2017’s, where it never eclipses the prior version (2016 or 2019). Instead, companies will likely move directly to 2025 from 2019.

Brent Ozar has a list:

Today at Microsoft Ignite, Microsoft announced SQL Server 2025. The biggest new features focus on AI and bringing the latest Azure SQL DB features down to your own servers. Here are the top features:

• Call AI services like ChatGPT directly from T-SQL – using T-SQL commands and sp_invoke_external_rest_endpoint
• Vector searches, a native vector data type, and vector indexes with DiskANN – more information in the documentation
• Fabric mirroring – so your data warehouse in Fabric can more easily have a near-real-time copy of your OLTP data sources – similar to how it works in Azure SQL DB
• Regular expression support in T-SQL – to learn more about that, read how it works in Azure
• Optimized locking – like how it works in Azure SQL DB, and you might have noticed a theme here

Of this list, I’m excited for regular expression support and optimized locking. On the latter, I would like RCSI to be the default, but I can understand that this would have a significant “Who moved my cheese?” factor for DBAs, and there are just enough cases when RCSI introduces actual change into an environment.

Fabric mirroring is also fine, and sp_invoke_external_rest_endpoint is something that can be useful, not just for making external calls. As for storing vector data, I will want to see its performance—both in terms of how quickly it loads & retrieves data, as well as how accurate the results are—before I get too excited. DiskANN is a good algorithm and it’s in Cosmos DB right now, but I haven’t been that impressed with the quality of results so far from it in Cosmos.