SQL Server has a feature called Query Store that maintains a history of all execution plans generated for each query over time. Unlike examining the current plan in cache with SHOWPLAN or execution plan tools, Query Store lets you see every plan the optimizer has chosen historically, allowing you to compare performance across plan changes and investigate regressions.
The following examples assume that Query Store is enabled on your database.
If you’ve spent any time working with SQL Server, you’ve almost certainly run into the “Violation of UNIQUE KEY constraint” error.
It’s one of those errors that can show up in a few different ways depending on how your data flows into the database. Sometimes it’s a data quality issue. Sometimes it’s a race condition. Sometimes it’s just a gap in the logic that nobody caught until production. Whatever the cause, there are quite a few different ways to handle it. Some reactively, some proactively. This article walks through the main ones.
If you’re getting SQL Server error 13683 stating “Invalid JSON paths in JSON index“, it sounds like you could be specifying overlapping paths in your JSON index definition.
A JSON index cannot contain overlapping paths.
To fix this, remove the overlap from the specified paths that make up the index definition.
JSON_CONTAINS() is a new function introduced in SQL Server 2025 that lets you check whether a value exists at a specific path in a JSON document. It returns an integer. This is 1 if the value is found, 0 if not, and NULL if any argument is null or the path doesn’t exist. That makes it a natural fit for WHERE clauses when you’re filtering rows based on JSON content.
It’s currently in preview (although this will almost certainly change soon) and only available from SQL Server 2025.
SQL Server added native JSON support back in SQL Server 2016, and as of SQL Server 2025, it officially introduced a dedicated JSON data type. If you’re on an older version, you’ve probably been storing JSON in NVARCHAR(MAX) columns and parsing it with functions like JSON_VALUE() and OPENJSON(). That still works, but the new JSON type gives you validation, better storage, and cleaner semantics.
And along with the JSON type, we get some new JSON related features. Let’s take a quick walk through.
Not every DBMS includes a dedicated PIVOT operator. And even in DBMSs like SQL Server that do provide a PIVOT operator, you might prefer alternatives for better readability or more control over the transformation logic. Fortunately, you can pivot data using standard SQL techniques that work across virtually any relational database.
The main approach is conditional aggregation. This is where you use CASE statements within aggregate functions to selectively pull values into specific columns. It tends to be more verbose than using a PIVOT operator, but it’s also more transparent, more flexible, and completely portable across database platforms.
When you’re designing a database, you need some way to organize your data that makes sense. You could just throw everything into one massive table, but that leads to problems pretty quickly. Duplicate data everywhere, weird update issues, and a general mess that’s hard to maintain.
Normal forms give you a framework for organizing data in a way that avoids these problems. They’re a series of rules or guidelines that help you structure your database tables properly.
This process of organizing data according to normal forms is called normalization, and it’s one of the fundamental concepts in relational database design.
The query plan cache (also called the plan cache or procedure cache) is an area of SQL Server’s memory that stores compiled execution plans for queries and stored procedures. When you execute a query, SQL Server compiles it into an execution plan (basically, a set of instructions for retrieving and processing data). Now, instead of recompiling that plan every time the same query runs, SQL Server stores it in the plan cache for reuse.
This caching mechanism significantly improves performance. Compiling a query plan requires CPU time and resources. The optimizer must analyze statistics, evaluate indexes, consider join orders, and make numerous decisions about the most efficient execution strategy. By caching plans, SQL Server avoids repeating this work for queries that execute repeatedly.
The basic syntax for adding a column in SQL Server is just two lines. But there are enough edge cases to really throw you off guard if you’re not careful. Your actual code will depend on things like, how you define the column, whether the table already has data, what constraints you need, etc. In the real world, there’s quite a bit more to know than just two lines.
This guide walks through all the common scenarios so you have a solid reference regardless of what you’re trying to do.
When you’re managing multiple products across different sales channels or regions, raw data tables don’t usually cut it. You need to see everything at once. For example, which products are crushing it online but underperforming in retail, or which regions are driving growth while others stagnate. A product performance matrix gives you that bird’s-eye view, turning rows of transaction data into a grid that shows patterns instantly.
