Joey on SQL Server

Microsoft Ignite 2025: SQL Server 2025 Is Here

With the official release of Microsoft's latest database offering, let's see what was improved and what still needs some work.

• By Joey D'Antoni
• 11/18/2025

Today, at Ignite, Microsoft announced the general availability of SQL Server 2025.

I've written a lot about this release and its "hero" features, such as AI vector search and change event streaming.  You'll learn more about those things later in this column. Still, I wanted to focus on a couple of lesser-known improvements that point to something I have observed in the last few versions of SQL Server: building on strong features and directionality.

For the longest time, one of the most common SQL Server performance problems was contention in the engine's scratch space, tempdb. This contention was not simply about overwhelmed storage, but also about internal constraints that frustrated DBAs, developers and end users. In SQL Server 2014, Microsoft introduced a feature called In-Memory OLTP (aka, Hekaton). Side note: You can finally uninstall it in SQL Server 2025. In both SQL Server 2019 and subsequently 2022, Microsoft rearchitected tempdb, ultimately leveraging In-Memory OLTP, and has basically eliminated the internal bottlenecks around tempdb.

That tempdb story is like many others I see across this release, where a feature that was built upon strong foundations of existing features. For example, Microsoft introduced Accelerated Database Recovery (ADR) in SQL Server 2019, which helped improve crash recovery and restore performance. Building on that is a feature called optimized locking, which takes advantage of the row versioning feature that ADR introduced. With optimized locking, a large update operation no longer needs to maintain row locks for every row, reducing table locks and the overhead of holding so many locks. Now the lock is associated with the transaction ID (TID), a component of ADR, effectively eliminating lock escalation problems.

The hardware limitations of SQL Server Standard Edition have always been a point of contention with many of my customers. Admittedly, SQL Server licensing has always been more customer-friendly than Oracle. However, Standard Edition has not always maintained parity with modern hardware. Microsoft began making efforts in this space with SQL Server 2016 Service Pack 1, where they got as close as possible to developer feature parity. Standard Edition in SQL Server 2025 gets a few significant boosts -- now allowing up to 32 CPU cores and 256 gigabytes of RAM. The standard edition also gets the resource governor (which itself provides additional controls over tempdb utilization per pool). Beyond the Standard Edition, the Express Edition now also supports up to 50 GB of data. Also, there is a standard edition of the developer edition (called Standard Developer), meaning you can test your code against a Standard Edition without a licensed version. Before this change, the Developer Edition mirrored the Enterprise Edition in terms of features and limitations.

I've already written a lot in this space around vector search, but AI is the story of the last five years in tech. An easier way to think about vector search (rather than getting drowned out in AI hype) is that it's like full-text search, but light-years better. With a traditional full-text search approach, if a user inputs "electric wire" and there isn't a hard match, you wouldn't get any results, whereas with vector search, terms like "electrical wiring," "wire electric" and "wiring" might all return results. This fuzzy matching isn't for all scenarios, but for the ones that really work, it's irreplaceable and easy to implement. I recently implemented a variation of this in my current work project. If it were in SQL Server 2025, it would have required zero changes to application code (merely a stored procedure and database change), which is hard to beat. On that theme of directionality, the vector search functionality builds on top of the REST API functionality that came to Azure SQL several years ago.

A feature that will enable new application functionality is Change Event Streaming (CES). SQL Server has had Change Data Capture since SQL Server 2008. That code essentially didn't change and tracked specified objects in the transaction log, writing their changes to tables in the same database. CDC had significant operational and performance overhead and could be tricky to implement. Conceptually, CES is similar, but it operates with a completely new architecture and significantly lower overhead. CES streams its messages in the standardized form of CloudEvents, defined as "A specification for describing event data in a common way." CloudEvents uses the Avro binary JSON format, which makes it compatible with systems built around streaming data, currently only Azure Event Hubs, but I would expect support for Apache Kakfa in subsequent updates. These downstream systems can consume these events and operate on them. A basic example of how you might use this event-driven architecture would be to trigger a business process after an order is received. CES evolved out of the Synapse Link project (some wait types and errors may still refer to Synapse).

Program managers at Microsoft always try to think of software developers. SQL Server 2025 is no exception -- there is a new JSON datatype, JSON-based indexes, and additional JSON functionality, bringing SQL Server closer to PostgreSQL in terms of JSON support. JSON data is stored and retrieved more efficiently than the previous workaround of using NVARCHAR(MAX) columns. There are some new T-SQL operators, including support for Regular Expression (RegEx) pattern matching. There are several adjustments to T-SQL to meet the ANSI SQL standard, including CURRENT_DATE(), || as a concatenation operator, SUBSTRING without length, and UNISTR, which returns the Unicode characters corresponding to the input (this is especially useful to those of you wishing to add emojis to your query results!).

Microsoft has leveraged customer feedback from SQL Server 2022 to make a series of enhancements to Always On Availability Groups. These are largely invisible -- but improve failover performance by changing some default behaviors. For example, the ability for an AG to recover more easily from temporary quorum loss within a cluster, as opposed to dropping into "not synchronizing" and requiring a series of reboots. The other improvements include enhanced health-check diagnostics, which can help you better understand the root cause of unplanned failovers. Another enhancement in the availability space is ZSTD backup compression, which improves on the 2008-era MS_EXPRESS algorithm to better compress backups, which speeds both backup and restore operations.

There's a lot more than I could cover here in SQL Server 2025, but I did my best to summarize what I've seen. I have been using SQL Server 2025 in testing since it was available in private preview. While I haven't pushed production workloads, I have been impressed with the functionality. I'd argue that since SQL Server 2016 (which introduced many major changes), Microsoft has been building on robust features like the query store, columnstore, availability groups, and adding additional functionality to those platforms. I also observe a push towards ANSI standards, and I think there are internal thoughts that realize their biggest competition in the database space is PostgreSQL and MongoDB, not Oracle. I also see better alignment between what's available in managed PaaS services like Azure SQL DB and Managed Instance in terms of development platforms and features.