Tag Archives: SQL Server new features

Standard

Posted by

Posted on

June 4, 2026

Posted under

Core

Comments

Leave a comment

SQL Server 2025 Series : SQL Backups Just Got Smaller and Faster – ZSTD Compression Live Demo!

Database backups are one of the most critical parts of any data platform strategy. Whether you are protecting transactional systems, reporting environments, or large enterprise workloads, backups directly influence storage consumption, recovery objectives, operational overhead, and even infrastructure cost.

With SQL Server 2025, backup compression gets a major upgrade through support for ZSTD (Zstandard) compression. This is a significant enhancement for database administrators and architects looking to reduce backup size, improve efficiency, and gain more flexibility in how backup workloads are tuned.

In this post, I will walk through what ZSTD compression is, why it matters, and how to test it using a simple end-to-end backup and restore demo.

What is ZSTD Compression?

ZSTD, or Zstandard, is a modern lossless compression algorithm designed to deliver an excellent balance between:

  • High compression ratio
  • Fast compression speed
  • Very fast decompression
  • Flexible tuning through compression levels

For years, backup compression has helped reduce storage usage and improve I/O efficiency. But as database sizes continue to grow, traditional compression methods may not always provide the best balance between speed and storage savings.

That is where ZSTD becomes exciting.

SQL Server 2025 now allows backups to use the ZSTD algorithm, giving DBAs a newer and more efficient option for compressing database backups.

Why This Matters

As backup volumes increase, organizations typically face a common set of challenges:

  • Backup files consume too much space
  • Backup windows become longer
  • Restore operations need to stay fast and reliable
  • Storage and archival costs continue growing
  • Sending backups across environments or regions becomes more expensive

ZSTD helps address these challenges by improving backup compression efficiency while still maintaining strong decompression performance.

In practical terms, this means you may be able to:

  • Store more backups using less space
  • Improve backup storage utilization
  • Reduce backup repository growth
  • Optimize retention strategies
  • Improve overall operational efficiency

Key Benefits of ZSTD Backup Compression

1. Better Compression Efficiency

One of the biggest advantages of ZSTD is its ability to compress data more efficiently than older approaches in many scenarios. This can result in noticeably smaller backup files, especially for large databases with compressible data patterns.

2. Faster Decompression

Backup is only one half of the story. Restore performance is equally important. ZSTD is known for fast decompression, which is valuable during restore operations when time matters most.

3. Compression Levels for Flexibility

SQL Server 2025 introduces the ability to choose different compression levels when using ZSTD. This is useful because not every environment has the same priorities.

For example:

  • If your priority is faster backup completion, a lower level may be enough
  • If your priority is maximum storage reduction, a higher level may be better
  • If you want a balance, medium can be a good starting point

4. Familiar Backup Workflow

Another great advantage is that ZSTD integrates directly into the backup syntax DBAs are already familiar with. There is no need to redesign the backup process from scratch. You simply use the appropriate compression options while taking the backup.

Demo Objective

In this walkthrough, the goal is to compare:

  1. A normal compressed backup
  2. A ZSTD backup with the default compression level
  3. A ZSTD backup with MEDIUM compression level
  4. A ZSTD backup with HIGH compression level

After each backup, we also validate the backup metadata and restore the database to separate target names and file paths. This gives us a complete end-to-end validation of both backup creation and restore success.

For this demo, we will use the JBFinance database and the exact script provided below.

What We Will Validate

This demo helps validate several things:

  • Backup command executes successfully
  • Backup header can be read
  • Backup file can be restored successfully
  • Different ZSTD compression levels can be tested easily
  • Separate restored copies can be created for comparison and verification

Step 1: Review the Source Database

Before taking backups, it is always useful to review the source database size and file layout.

USE [master]
GO
sp_helpdb JBFinance
GO

This gives you a quick overview of the database structure and helps confirm the logical file names that will later be used during restore.

Step 2: Take a Regular Compressed Backup

First, take a standard compressed backup using the familiar compression option.

BACKUP DATABASE JBFinance to DISK ='C:\temp\ZSTD\JBFinance_normal.bak' with COMPRESSION,STATS=1;
GO

What this does

This command creates a compressed backup of the JBFinance database and writes it to the specified backup location.

Why this matters

This serves as your baseline. You can compare this backup later with the ZSTD-based backups to understand whether ZSTD offers better storage efficiency or operational benefits in your environment.

Step 3: Inspect the Backup Metadata

After the backup completes, inspect the backup header.

RESTORE HEADERONLY FROM DISK ='C:\temp\ZSTD\JBFinance_normal.bak';
GO

Why this step is useful

This confirms that:

  • The backup file is valid
  • SQL Server can read the backup metadata
  • The backup can be used in restore operations

It is also a good verification step before running a restore.

Step 4: Restore the Regular Compressed Backup

Now restore that baseline backup to a separate database name.

RESTORE DATABASE [JBFinance_Normal] FROM  DISK = N'c:\temp\zstd\JBFinance_normal.bak' WITH  FILE = 1,  MOVE N'JBFinance_Data1' TO N'C:\temp\ZSTD\Non-STD\JBFinance_Data1.mdf',  MOVE N'JBFinance_Data2' TO N'C:\temp\ZSTD\Non-STD\JBFinance_Data2.mdf',  MOVE N'JBFinance_Data3' TO N'C:\temp\ZSTD\Non-STD\JBFinance_Data3.mdf',  MOVE N'JBFinance_Data4' TO N'C:\temp\ZSTD\Non-STD\JBFinance_Data4.mdf',  MOVE N'JBFinance_Log' TO N'C:\temp\ZSTD\Non-STD\JBFinance_Log.ldf',  NOUNLOAD,  STATS = 1
GO

Why restore it?

A backup is only useful if it can be restored successfully. This step validates the full backup-and-restore chain.

Step 5: Take a ZSTD Backup Using the Default Compression Level

Now let’s move to the new feature.

BACKUP DATABASE JBFinance to DISK ='C:\temp\ZSTD\JBFinance_ZSTD.bak' with COMPRESSION(ALGORITHM = ZSTD),STATS=1; --Default compression Level is LOW
GO

Important note

When only ALGORITHM = ZSTD is specified, the default compression level is LOW.

Why this is interesting

This gives you a first look at how ZSTD behaves with minimal additional tuning. It is a good starting point for most first-time tests.

Step 6: Validate the ZSTD Backup Header

RESTORE HEADERONLY FROM DISK ='C:\temp\ZSTD\JBFinance_ZSTD.bak';
GO

Again, this confirms the backup is readable and valid.

Step 7: Restore the ZSTD LOW Backup

RESTORE DATABASE [JBFinance_Low] FROM  DISK = N'c:\temp\zstd\JBFinance_ZSTD.bak' WITH  FILE = 1,  MOVE N'JBFinance_Data1' TO N'C:\temp\ZSTD\ZSTD\JBFinance_Data1.mdf',  MOVE N'JBFinance_Data2' TO N'C:\temp\ZSTD\ZSTD\JBFinance_Data2.mdf',  MOVE N'JBFinance_Data3' TO N'C:\temp\ZSTD\ZSTD\JBFinance_Data3.mdf',  MOVE N'JBFinance_Data4' TO N'C:\temp\ZSTD\ZSTD\JBFinance_Data4.mdf',  MOVE N'JBFinance_Log' TO N'C:\temp\ZSTD\ZSTD\JBFinance_Log.ldf',  NOUNLOAD,  STATS = 1
GO

This confirms that a backup created using ZSTD can be restored just as expected.

Step 8: Take a ZSTD Backup with MEDIUM Compression Level

Now let’s test the MEDIUM compression level.

BACKUP DATABASE JBFinance to DISK ='C:\temp\ZSTD\JBFinance_ZSTD_MEDIUM.bak' with COMPRESSION(ALGORITHM = ZSTD, LEVEL = MEDIUM),STATS=1;
GO

Why MEDIUM matters

This is often the level many teams will be interested in because it may provide a stronger balance between:

  • Backup size reduction
  • CPU cost
  • Backup duration

Step 9: Validate the MEDIUM Backup Header

RESTORE HEADERONLY FROM DISK ='C:\temp\ZSTD\JBFinance_ZSTD_MEDIUM.bak';
GO

Step 10: Restore the MEDIUM Backup

RESTORE DATABASE [JBFinance_Medium] FROM  DISK = N'c:\temp\zstd\JBFinance_ZSTD_MEDIUM.bak' WITH  FILE = 1,  MOVE N'JBFinance_Data1' TO N'C:\temp\ZSTD\ZSTD_MEDIUM\JBFinance_Data1.mdf',  MOVE N'JBFinance_Data2' TO N'C:\temp\ZSTD\ZSTD_MEDIUM\JBFinance_Data2.mdf',  MOVE N'JBFinance_Data3' TO N'C:\temp\ZSTD\ZSTD_MEDIUM\JBFinance_Data3.mdf',  MOVE N'JBFinance_Data4' TO N'C:\temp\ZSTD\ZSTD_MEDIUM\JBFinance_Data4.mdf',  MOVE N'JBFinance_Log' TO N'C:\temp\ZSTD\ZSTD_MEDIUM\JBFinance_Log.ldf',  NOUNLOAD,  STATS = 1
GO

This gives you a restored copy from the ZSTD MEDIUM backup for validation and comparison.

Step 11: Take a ZSTD Backup with HIGH Compression Level

Now let’s test the HIGH compression level.

BACKUP DATABASE JBFinance to DISK ='C:\temp\ZSTD\JBFinance_ZSTD_HIGH.bak' with COMPRESSION(ALGORITHM = ZSTD, LEVEL = HIGH),STATS=1;
GO

Why HIGH matters

If your main goal is maximum backup size reduction, this option is worth testing. In some environments, HIGH can offer the most aggressive storage savings, though it may also require more CPU resources during backup creation.

Step 12: Validate the HIGH Backup Header

RESTORE HEADERONLY FROM DISK ='C:\temp\ZSTD\JBFinance_ZSTD_HIGH.bak';
GO

Step 13: Restore the HIGH Backup

RESTORE DATABASE [JBFinance_High] FROM  DISK = N'c:\temp\zstd\JBFinance_ZSTD_HIGH.bak' WITH  FILE = 1,  MOVE N'JBFinance_Data1' TO N'C:\temp\ZSTD\ZSTD_HIGH\JBFinance_Data1.mdf',  MOVE N'JBFinance_Data2' TO N'C:\temp\ZSTD\ZSTD_HIGH\JBFinance_Data2.mdf',  MOVE N'JBFinance_Data3' TO N'C:\temp\ZSTD\ZSTD_HIGH\JBFinance_Data3.mdf',  MOVE N'JBFinance_Data4' TO N'C:\temp\ZSTD\ZSTD_HIGH\JBFinance_Data4.mdf',  MOVE N'JBFinance_Log' TO N'C:\temp\ZSTD\ZSTD_HIGH\JBFinance_Log.ldf',  NOUNLOAD,  STATS = 1
GO

This completes the end-to-end validation of all backup variants in the test.

Full Demo Script

For convenience, here is the complete script exactly as provided for the demo.

--- ZSTD Compression
USE [master]
GO
sp_helpdb JBFinance
GO
BACKUP DATABASE JBFinance to DISK ='C:\temp\ZSTD\JBFinance_normal.bak' with COMPRESSION,STATS=1; 
GO  
RESTORE HEADERONLY FROM DISK ='C:\temp\ZSTD\JBFinance_normal.bak';  
GO 
RESTORE DATABASE [JBFinance_Normal] FROM  DISK = N'c:\temp\zstd\JBFinance_normal.bak' WITH  FILE = 1,  MOVE N'JBFinance_Data1' TO N'C:\temp\ZSTD\Non-STD\JBFinance_Data1.mdf',  MOVE N'JBFinance_Data2' TO N'C:\temp\ZSTD\Non-STD\JBFinance_Data2.mdf',  MOVE N'JBFinance_Data3' TO N'C:\temp\ZSTD\Non-STD\JBFinance_Data3.mdf',  MOVE N'JBFinance_Data4' TO N'C:\temp\ZSTD\Non-STD\JBFinance_Data4.mdf',  MOVE N'JBFinance_Log' TO N'C:\temp\ZSTD\Non-STD\JBFinance_Log.ldf',  NOUNLOAD,  STATS = 1
GO  
-------
BACKUP DATABASE JBFinance to DISK ='C:\temp\ZSTD\JBFinance_ZSTD.bak' with COMPRESSION(ALGORITHM = ZSTD),STATS=1; --Default compression Level is LOW
GO  
RESTORE HEADERONLY FROM DISK ='C:\temp\ZSTD\JBFinance_ZSTD.bak';
GO  
RESTORE DATABASE [JBFinance_Low] FROM  DISK = N'c:\temp\zstd\JBFinance_ZSTD.bak' WITH  FILE = 1,  MOVE N'JBFinance_Data1' TO N'C:\temp\ZSTD\ZSTD\JBFinance_Data1.mdf',  MOVE N'JBFinance_Data2' TO N'C:\temp\ZSTD\ZSTD\JBFinance_Data2.mdf',  MOVE N'JBFinance_Data3' TO N'C:\temp\ZSTD\ZSTD\JBFinance_Data3.mdf',  MOVE N'JBFinance_Data4' TO N'C:\temp\ZSTD\ZSTD\JBFinance_Data4.mdf',  MOVE N'JBFinance_Log' TO N'C:\temp\ZSTD\ZSTD\JBFinance_Log.ldf',  NOUNLOAD,  STATS = 1
GO   
-------
BACKUP DATABASE JBFinance to DISK ='C:\temp\ZSTD\JBFinance_ZSTD_MEDIUM.bak' with COMPRESSION(ALGORITHM = ZSTD, LEVEL = MEDIUM),STATS=1;
GO 
RESTORE HEADERONLY FROM DISK ='C:\temp\ZSTD\JBFinance_ZSTD_MEDIUM.bak';
GO 
RESTORE DATABASE [JBFinance_Medium] FROM  DISK = N'c:\temp\zstd\JBFinance_ZSTD_MEDIUM.bak' WITH  FILE = 1,  MOVE N'JBFinance_Data1' TO N'C:\temp\ZSTD\ZSTD_MEDIUM\JBFinance_Data1.mdf',  MOVE N'JBFinance_Data2' TO N'C:\temp\ZSTD\ZSTD_MEDIUM\JBFinance_Data2.mdf',  MOVE N'JBFinance_Data3' TO N'C:\temp\ZSTD\ZSTD_MEDIUM\JBFinance_Data3.mdf',  MOVE N'JBFinance_Data4' TO N'C:\temp\ZSTD\ZSTD_MEDIUM\JBFinance_Data4.mdf',  MOVE N'JBFinance_Log' TO N'C:\temp\ZSTD\ZSTD_MEDIUM\JBFinance_Log.ldf',  NOUNLOAD,  STATS = 1
GO  
------
BACKUP DATABASE JBFinance to DISK ='C:\temp\ZSTD\JBFinance_ZSTD_HIGH.bak' with COMPRESSION(ALGORITHM = ZSTD, LEVEL = HIGH),STATS=1;
GO 
RESTORE HEADERONLY FROM DISK ='C:\temp\ZSTD\JBFinance_ZSTD_HIGH.bak';
GO
RESTORE DATABASE [JBFinance_High] FROM  DISK = N'c:\temp\zstd\JBFinance_ZSTD_HIGH.bak' WITH  FILE = 1,  MOVE N'JBFinance_Data1' TO N'C:\temp\ZSTD\ZSTD_HIGH\JBFinance_Data1.mdf',  MOVE N'JBFinance_Data2' TO N'C:\temp\ZSTD\ZSTD_HIGH\JBFinance_Data2.mdf',  MOVE N'JBFinance_Data3' TO N'C:\temp\ZSTD\ZSTD_HIGH\JBFinance_Data3.mdf',  MOVE N'JBFinance_Data4' TO N'C:\temp\ZSTD\ZSTD_HIGH\JBFinance_Data4.mdf',  MOVE N'JBFinance_Log' TO N'C:\temp\ZSTD\ZSTD_HIGH\JBFinance_Log.ldf',  NOUNLOAD,  STATS = 1
GO

What to Observe During the Demo

When you run this demo in your environment, pay close attention to the following:

1. Backup File Size

Compare the sizes of:

  • JBFinance_normal.bak
  • JBFinance_ZSTD.bak
  • JBFinance_ZSTD_MEDIUM.bak
  • JBFinance_ZSTD_HIGH.bak

This helps you understand how each compression option affects storage savings.

2. Backup Completion Time

Capture how long each backup takes to complete. Higher compression levels may reduce backup size further, but they can also use more CPU.

3. Restore Success

Each backup should restore successfully into its own database copy. This confirms backup reliability and end-to-end usability.

4. Compression Trade-Offs

The best compression level is not always the smallest file. In many real-world environments, the right choice depends on:

  • Backup window
  • CPU availability
  • Storage cost
  • Restore expectations
  • Workload sensitivity

4. My Test details

Table showing backup types, their corresponding backup times, restore times, and backup sizes in GB.

Practical Guidance

Here are a few practical recommendations when evaluating ZSTD backup compression in your environment.

Start with LOW or MEDIUM

If you are testing this feature for the first time, LOW or MEDIUM is a practical place to begin.

Measure Before Standardizing

Do not assume one level is best for every database. Compression results vary depending on:

  • Data types
  • Existing data compression
  • Row patterns
  • Repetitive versus random data
  • Binary or already compressed content

Test Restore Performance Too

Do not focus only on backup size. Make sure you also validate restore workflows, especially for recovery-critical systems.

Use Realistic Data

Whenever possible, test this against an actual workload or database that resembles production.

Final Thoughts

ZSTD compression in SQL Server 2025 is a meaningful enhancement for modern backup strategies. It gives database professionals more flexibility in how they balance storage efficiency, backup throughput, and operational cost.

The biggest advantage is not just smaller backup files. It is the ability to tune compression behavior based on your environment and priorities.

If your organization manages large backups, retention-heavy workloads, or storage-sensitive environments, this feature is definitely worth testing.

The script used in this post provides a simple and effective way to compare:

  • Standard compressed backup
  • ZSTD LOW
  • ZSTD MEDIUM
  • ZSTD HIGH

and validate the complete backup-and-restore workflow.

Watch the Full Demo

I’ve recorded a complete walkthrough of this setup on my YouTube channel JBSWiki. If you’re a visual learner, go check it out!

👉 Watch here:https://www.youtube.com/watch?v=gFzRdmz13xQ

Thank You,
Vivek Janakiraman

Disclaimer:
The views expressed on this blog are mine alone and do not reflect the views of my company or anyone else. All postings on this blog are provided “AS IS” with no warranties, and confers no rights.

Standard

Posted by

Posted on

August 26, 2024

Posted under

SQL Server 2022

Comments

Leave a comment

SQL Server 2022: IS [NOT] DISTINCT FROM Predicate

SQL Server 2022 introduces a new predicate, IS [NOT] DISTINCT FROM, which simplifies the comparison of nullable columns. This feature is a boon for developers who often struggle with the nuanced behavior of NULL values in SQL comparisons. In this blog, we’ll explore how this new predicate works, its benefits, and provide a detailed business use case to illustrate its practical application.

Business Use Case: Analyzing Customer Orders

Imagine a retail company, JB Retail, that maintains a database (JBDB) to track customer orders. The company wants to analyze orders to identify customers who have updated their email addresses. However, due to some data migration issues, there are instances where old and new email addresses might be stored as NULL values.

To accurately identify customers who have changed their email addresses (or those whose email addresses are currently NULL but were previously not NULL), the IS [NOT] DISTINCT FROM predicate becomes very useful. This new feature allows us to simplify the logic and handle NULL comparisons more gracefully.

Setting Up the JBDB Database

First, let’s create the JBDB database and set up a sample table CustomerOrders to illustrate our use case.

-- Create JBDB database
CREATE DATABASE JBDB;
GO

-- Use the JBDB database
USE JBDB;
GO

-- Create CustomerOrders table
CREATE TABLE CustomerOrders (
    OrderID INT PRIMARY KEY,
    CustomerID INT,
    OldEmail NVARCHAR(255),
    NewEmail NVARCHAR(255),
    OrderDate DATE
);
GO

-- Insert sample data into CustomerOrders
INSERT INTO CustomerOrders (OrderID, CustomerID, OldEmail, NewEmail, OrderDate)
VALUES
    (1, 101, 'old_email1@example.com', 'new_email1@example.com', '2024-01-15'),
    (2, 102, 'old_email2@example.com', NULL, '2024-02-20'),
    (3, 103, NULL, 'new_email3@example.com', '2024-03-05'),
    (4, 104, 'old_email4@example.com', 'old_email4@example.com', '2024-04-10'),
    (5, 105, NULL, NULL, '2024-05-12');
GO

Understanding IS [NOT] DISTINCT FROM Predicate 🧩

The IS DISTINCT FROM predicate compares two expressions and returns TRUE if they are distinct (i.e., not equal or one is NULL and the other is not). The IS NOT DISTINCT FROM predicate, on the other hand, returns TRUE if they are not distinct (i.e., equal or both are NULL).

This is particularly useful when dealing with nullable columns, as NULL values are traditionally not equal to anything, including themselves, in SQL. The new predicate addresses this challenge.

Example Queries

Finding Customers Who Have Updated Their Email Address

    SELECT CustomerID, OldEmail, NewEmail
FROM CustomerOrders
WHERE OldEmail IS DISTINCT FROM NewEmail;

    This query identifies customers whose email addresses have changed. The IS DISTINCT FROM predicate ensures that it catches cases where either the old or new email could be NULL.

    Finding Customers Whose Email Address Remains Unchanged

    SELECT CustomerID, OldEmail, NewEmail
FROM CustomerOrders
WHERE OldEmail IS NOT DISTINCT FROM NewEmail;

    This query retrieves customers whose email addresses have not changed, including cases where both old and new emails are NULL.

      Detailed Business Use Case 🎯

      Let’s dive deeper into how JB Retail can use these queries to improve their customer relationship management. The company plans to send personalized emails to customers whose email addresses have been updated, acknowledging the change and ensuring it was intentional.

      Business Workflow

      Identify Updated Emails: The company will first use the IS DISTINCT FROM query to extract a list of customers with updated emails.

      SELECT CustomerID, OldEmail, NewEmail
FROM CustomerOrders
WHERE OldEmail IS DISTINCT FROM NewEmail;
      1. This query helps them identify cases where:
        • The old email was NULL and the new email is not, indicating a new addition.
        • The new email was NULL and the old email is not, indicating a removal.
        • Both emails are different but not NULL, indicating an actual change.
      2. Personalized Communication: Once the list is prepared, JB Retail can use it to send personalized communication to these customers. This step ensures that customers are aware of the changes and can report if the change was not authorized.
      3. Customer Service Follow-up: For cases where both old and new emails are NULL, the company can follow up with these customers to update their contact information, ensuring they do not miss out on important communications.

      Find Customers with NULL Values in Either Old or New Email

      This query helps identify customers where either the old or new email address is NULL, but not both.

      SELECT CustomerID, OldEmail, NewEmail
FROM CustomerOrders
WHERE OldEmail IS DISTINCT FROM NewEmail
AND (OldEmail IS NULL OR NewEmail IS NULL);

      List Orders with Same Email Address Before and After

      This query lists orders where the email address remained the same before and after, but takes NULL into account.

      SELECT OrderID, CustomerID, OldEmail, NewEmail
FROM CustomerOrders
WHERE OldEmail IS NOT DISTINCT FROM NewEmail
AND (OldEmail IS NOT NULL AND NewEmail IS NOT NULL);

      Find Orders with NULL Emails in Both Old and New

      This query identifies orders where both the old and new email addresses are NULL.

      SELECT OrderID, CustomerID, OldEmail, NewEmail
FROM CustomerOrders
WHERE OldEmail IS NOT DISTINCT FROM NewEmail
AND OldEmail IS NULL;

      Identify Changes Where Old Email is NULL and New Email is Not

      This query finds orders where the old email address was NULL and the new email address is not NULL.

      SELECT OrderID, CustomerID, OldEmail, NewEmail
FROM CustomerOrders
WHERE OldEmail IS DISTINCT FROM NewEmail
AND OldEmail IS NULL
AND NewEmail IS NOT NULL;

      Find Orders Where Both Emails are Different or Both are NULL

      This query lists orders where the old and new emails are either both different or both NULL.

      SELECT OrderID, CustomerID, OldEmail, NewEmail
FROM CustomerOrders
WHERE (OldEmail IS DISTINCT FROM NewEmail
AND OldEmail IS NOT NULL AND NewEmail IS NOT NULL)
OR (OldEmail IS NULL AND NewEmail IS NULL);

      These queries leverage the IS [NOT] DISTINCT FROM predicate to handle various scenarios involving NULL values, providing flexibility and clarity in managing data comparisons. Feel free to adapt these queries based on your specific needs!

      Conclusion 🏁

      The introduction of the IS [NOT] DISTINCT FROM predicate in SQL Server 2022 is a significant enhancement for database developers and administrators. It simplifies the handling of NULL values in comparisons, making queries more readable and efficient.

      In the case of JB Retail, this feature enables a more accurate and efficient way to handle email updates, ensuring that the company maintains accurate customer contact information and strengthens its customer relationship management processes.

      With these new tools at your disposal, handling NULL values in SQL Server has never been easier! 🎉

      For more tutorials and tips on SQL Server, including performance tuning and database management, be sure to check out our JBSWiki YouTube channel.

      Thank You,
      Vivek Janakiraman

      Disclaimer:
      The views expressed on this blog are mine alone and do not reflect the views of my company or anyone else. All postings on this blog are provided “AS IS” with no warranties, and confers no rights.

        Standard

        Posted by

        Posted on

        August 25, 2024

        Posted under

        SQL Server 2022

        Comments

        Leave a comment

        Mastering LAG and LEAD Functions in SQL Server 2022 with the IGNORE NULLS Option

        SQL Server 2022 introduced a powerful enhancement to the LAG and LEAD functions with the IGNORE NULLS option. This feature allows for more precise analysis and reporting by skipping over NULL values in data sets. In this blog, we’ll explore how to use these functions effectively using the JBDB database, and we’ll demonstrate their application with a detailed business use case.

        Business Use Case: Sales Data Analysis

        Imagine a retail company, JBStore, that wants to analyze its sales data to understand sales trends better. They aim to compare each month’s sales with the previous and next months, ignoring any missing data (represented by NULL values). This analysis will help identify trends and outliers, aiding in better decision-making.

        Setting Up the JBDB Database

        First, let’s set up the JBDB database and create a SalesData table with some sample data, including NULL values to represent months with no sales data.

        -- Create JBDB database
CREATE DATABASE JBDB;
GO

-- Use the JBDB database
USE JBDB;
GO

-- Create SalesData table
CREATE TABLE SalesData (
    SalesMonth INT,
    SalesAmount INT
);

-- Insert sample data, including NULLs
INSERT INTO SalesData (SalesMonth, SalesAmount)
VALUES
    (1, 1000),
    (2, 1500),
    (3, NULL),
    (4, 1800),
    (5, NULL),
    (6, 2000);
GO

        LAG and LEAD Functions: A Quick Recap

        The LAG function allows you to access data from a previous row in the same result set without the use of a self-join. Similarly, the LEAD function accesses data from a subsequent row. Both functions are part of the SQL window functions family and are particularly useful in time series analysis.

        Using LAG and LEAD with IGNORE NULLS

        The IGNORE NULLS option is a game-changer, as it allows you to skip over NULL values, providing more meaningful results. Here’s how you can use it with the LAG and LEAD functions:

        Example 1: LAG Function with IGNORE NULLS
        SELECT 
    SalesMonth,
    SalesAmount,
    LAG(SalesAmount, 1) IGNORE NULLS OVER (ORDER BY SalesMonth) AS PreviousMonthSales
FROM 
    SalesData;

        In this example, LAG(SalesAmount, 1) IGNORE NULLS retrieves the sales amount from the previous month, skipping over any NULL values.

        Example 2: LEAD Function with IGNORE NULLS
        SELECT 
    SalesMonth,
    SalesAmount,
    LEAD(SalesAmount, 1) IGNORE NULLS OVER (ORDER BY SalesMonth) AS NextMonthSales
FROM 
    SalesData;

        Here, LEAD(SalesAmount, 1) IGNORE NULLS retrieves the sales amount from the next month, again skipping over NULL values.

        Practical Example: Analyzing Sales Trends

        Let’s combine these functions to analyze sales trends more effectively.

        SELECT 
    SalesMonth,
    SalesAmount,
    LAG(SalesAmount, 1) IGNORE NULLS OVER (ORDER BY SalesMonth) AS PreviousMonthSales,
    LEAD(SalesAmount, 1) IGNORE NULLS OVER (ORDER BY SalesMonth) AS NextMonthSales
FROM 
    SalesData;

        This query provides a complete view of each month’s sales, the previous month’s sales, and the next month’s sales, excluding any NULL values. This is incredibly useful for identifying patterns, such as periods of growth or decline.

        Detailed Business Use Case: Data-Driven Decision Making

        By utilizing the IGNORE NULLS option with LAG and LEAD functions, JBStore can:

        1. Identify Growth Periods: Detect months where sales increased significantly compared to the previous or next month.
        2. Spot Anomalies: Easily identify months with unusually high or low sales, excluding months with missing data.
        3. Trend Analysis: Understand longer-term trends by comparing sales over multiple months.

        These insights can inform marketing strategies, inventory planning, and more.

        Calculate Difference Between Current and Previous Month’s Sales:

        SELECT SalesMonth, SalesAmount, SalesAmount - LAG(SalesAmount, 1) IGNORE NULLS OVER (ORDER BY SalesMonth) AS SalesDifference FROM SalesData;

        Identify Months with Sales Decrease Compared to Previous Month:

        WITH CTE AS (
    SELECT 
        SalesMonth,
        SalesAmount,
        LAG(SalesAmount, 1) IGNORE NULLS OVER (ORDER BY SalesMonth) AS PreviousMonthSales
    FROM 
        SalesData
)
SELECT 
    SalesMonth,
    SalesAmount,
    PreviousMonthSales
FROM 
    CTE
WHERE 
    SalesAmount < PreviousMonthSales;

        Find the Second Previous Month’s Sales:

        SELECT SalesMonth, SalesAmount, LAG(SalesAmount, 2) IGNORE NULLS OVER (ORDER BY SalesMonth) AS SecondPreviousMonthSales FROM SalesData;

        Calculate the Rolling Average of the Last Two Months (Ignoring NULLs):

        SELECT SalesMonth, SalesAmount, (SalesAmount + LAG(SalesAmount, 1) IGNORE NULLS OVER (ORDER BY SalesMonth)) / 2 AS RollingAverage FROM SalesData;

        Compare Sales Between Current Month and Two Months Ahead:

        SELECT SalesMonth, SalesAmount, LEAD(SalesAmount, 2) IGNORE NULLS OVER (ORDER BY SalesMonth) AS SalesTwoMonthsAhead FROM SalesData;

        Identify Consecutive Months with Sales Increase:

        WITH CTE AS ( SELECT SalesMonth, SalesAmount, LAG(SalesAmount, 1) IGNORE NULLS OVER (ORDER BY SalesMonth) AS PreviousMonthSales FROM SalesData ) SELECT SalesMonth, SalesAmount FROM CTE WHERE SalesAmount > PreviousMonthSales;

        Find Months with No Sales and Their Preceding Sales Month:

        SELECT SalesMonth, SalesAmount, LAG(SalesAmount, 1) IGNORE NULLS OVER (ORDER BY SalesMonth) AS PrecedingMonthSales FROM SalesData WHERE SalesAmount IS NULL;

        Calculate Cumulative Sales Sum Ignoring NULLs:

        SELECT 
    SalesMonth,
    SalesAmount,
    SUM(ISNULL(SalesAmount, 0)) OVER (ORDER BY SalesMonth ROWS BETWEEN UNBOUNDED PRECEDING AND CURRENT ROW) AS CumulativeSales
FROM 
    SalesData;

        Identify the First Month with Sales After a Month with NULL Sales:

        SELECT SalesMonth, SalesAmount, LEAD(SalesAmount, 1) IGNORE NULLS OVER (ORDER BY SalesMonth) AS FirstNonNullSalesAfterNull FROM SalesData WHERE SalesAmount IS NULL;

          Conclusion 🎉

          The LAG and LEAD functions with the IGNORE NULLS option in SQL Server 2022 offer a more refined way to analyze data, providing more accurate and meaningful results. Whether you’re analyzing sales data, customer behavior, or any other time series data, these functions can significantly enhance your analytical capabilities.

          Happy querying! 🚀

          For more tutorials and tips on SQL Server, including performance tuning and database management, be sure to check out our JBSWiki YouTube channel.

          Thank You,
          Vivek Janakiraman

          Disclaimer:
          The views expressed on this blog are mine alone and do not reflect the views of my company or anyone else. All postings on this blog are provided “AS IS” with no warranties, and confers no rights.