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.
The Netflix Sample Database is a learning database based on public data from Netflix’s Engagement Report and Global Top 10 lists. This article walks through the steps involved when installing it on Oracle Database.
For more background on this database, check out Getting Started with the Netflix Sample Database.
If you’re getting SQL Server error 2744 that reads “Multiple identity columns specified for table…“, it looks like you’re trying to define a table to have more than one identity column.
SQL Server restricts identity columns to just one per table. If you try to add another one, you’ll get the above error.
The easiest way to address this issue is to leave the table with one identity table and be done with it. But that might not always be practical. Maybe you need a column that increments a different value than the identity column. Fortunately, there are ways of doing that.
The Netflix sample database is a learning database based on public data from Netflix’s Engagement Report and Global Top 10 lists. This guide walks you through installing it on PostgreSQL.
For more background on this database, see my introduction to the Netflix Sample Database.