Running a full-featured Microsoft SQL Server on a Mac used to be a headache, but as of 2026, it is smoother than ever. Thanks to improvements in Docker Desktop and macOS’s Rosetta 2 translation, you can now run the enterprise-grade engine (including the new SQL Server 2025 Preview) directly on your M1, M2, M3, or M4 Mac.
This guide will walk you through setting up a modern SQL Server environment from scratch.
SQL Server’s Query Store captures all executed queries (or a subset based on your capture mode) along with their execution statistics. Viewing the complete list of captured queries helps you understand what’s been tracked and provides a starting point for performance analysis.
When you’re analyzing how events unfold over time in a SQL database, one of the biggest challenges can be efficiently comparing what’s happening now to what comes next. Each event typically appears as its own row with a timestamp, but meaningful insight often comes from understanding how those timestamps relate to one another. Fortunately SQL Server provides some useful tools for this kind of sequential analysis.
Rather than relying on bulky self-joins or multi-step logic, SQL window functions offer a streamlined way to track these transitions. For example, by pairing the LEAD() function with DATEDIFF(), you can instantly measure the gap between consecutive events and surface insights that would otherwise require far more complex queries.
When you’ve forced an execution plan in SQL Server’s query store and later want to allow the optimizer to choose plans freely again, you’ll need to unforce the plan. You might want to do this because you’ve fixed the underlying issue or the forced plan is no longer optimal. Whatever the reason, the solution is straightforward and easy.
SQL Server’s window functions open up some creative possibilities when you need to work with dates. One interesting pattern involves pairing DATEADD() with ROW_NUMBER() to automatically generate sequential dates based on your query results.
This technique gives you a flexible way to calculate dates dynamically without hardcoding values or maintaining separate date tables. This can be useful for doing things like building a scheduling system, creating test data with realistic timestamps, or just spacing events across a timeline.
If you’ve ever wondered why your database queries sometimes seem to wait around doing nothing, or why two users can’t update the same record at the exact same moment, you’re dealing with locks. In SQL Server, locks are the fundamental mechanism that keeps your data consistent and prevents the chaos that would ensue if everyone could modify everything simultaneously.
SQL Server’s Query Store accumulates query execution history, plans, and runtime statistics over time. Eventually you may need to remove this data to free up space, start fresh after troubleshooting, or clear out information that’s no longer relevant. Fortunately, you can clear Query Store data without disabling the feature entirely.
When the optimizer consistently chooses a poor execution plan for a query, you can force SQL Server to use a specific better-performing plan from Query Store. This can provide immediate relief while you investigate and fix the root cause of the poor plan choice.
SQL Server’s Query Store provides a handy way to track query performance over time, making it easier to troubleshoot issues and optimize workloads. To get the most out of it, it helps to understand the various configuration options that control how it collects, stores, and manages data.
Query Store captures query execution history, plans, and runtime statistics over time. If you need to stop this data collection (whether to reduce overhead, troubleshoot issues, or prepare for maintenance) you can disable Query Store on a per-database basis.