Contact

Thanks for visiting SQL & Cloud Lab. I'm happy to hear from readers.

Send a message

Use the message form below to send me a private message. It comes straight to me and is not published.Comment on a post

For questions about a specific article, leave a comment on that post. Other readers may benefit from the answer too.

What I can help with

  • Questions or corrections about anything published here
  • Topic suggestions for future guides on SQL Server, Azure SQL and .NET
  • Reporting a broken link or an outdated price or feature

I read every message and try to reply within a few days. I'm not able to offer private consulting or troubleshoot production systems over email.

Comments

Post a Comment

Send a message

Name

Email *

Message *

Popular posts from this blog

SARGable Queries in SQL Server: Why Functions in WHERE Slow You Down

Image
You add the perfect index, run the query, and SQL Server still scans the whole table. One of the most common reasons is a non-SARGable predicate: a WHERE clause written in a way that stops SQL Server from using the index to seek. The fix is usually a small rewrite. What SARGable means SARGable stands for S earch ARG ument- able . A predicate is SARGable when SQL Server can use it to jump straight to the matching rows in an index (an index seek). If you wrap the indexed column in a function or calculation, SQL Server can no longer search the index for a value; it has to calculate the expression for every row, which means a scan. The rule of thumb: leave the column bare on one side of the comparison , and do any calculation on the other side. Common non-SARGable patterns and their fixes Functions on date columns -- Not SARGable: YEAR() runs on every row WHERE YEAR(OrderDate) = 2026 -- SARGable: a range on the bare column WHERE OrderDate >= '2026-01-01' AND OrderDate < ...
Read more

Azure SQL Database vs SQL Server on Azure VM: Cost Comparison (2026)

Image
If you are moving a SQL Server workload to Azure, the first big decision is where it will run: Azure SQL Database (a fully managed database service) or SQL Server on an Azure Virtual Machine (your own SQL Server, running on a VM you control). Both work well. But they bill you in very different ways, and picking the wrong one can quietly double your monthly bill. This guide breaks down what you actually pay for in each option, where the hidden costs are, and a simple way to decide. Quick answer Choose Azure SQL Database for new applications, single databases, variable or spiky workloads, and teams that do not want to manage patching, backups or high availability. Choose SQL Server on an Azure VM when you need full instance control: SQL Agent jobs across databases, SSIS/SSRS on the same box, OS-level access, specific SQL Server versions, or third-party software installed next to SQL Server. Consider Azure SQL Managed Instance when you want near-full SQL Server compat...
Read more

How to Read a SQL Server Execution Plan (Beginner's Guide)

Image
When a query is slow, the execution plan tells you exactly what SQL Server did to run it: which indexes it used, how it joined tables and where the time went. Plans can look intimidating, but you only need a few habits to find the problem in most of them. Estimated vs actual plans SQL Server Management Studio (SSMS) can show two kinds of plan: Estimated plan (Ctrl+L): what SQL Server plans to do, without running the query. Useful for queries that are too slow or too risky to run. Actual plan (Ctrl+M, then run the query): the same plan plus what really happened, including actual row counts and warnings. Use this whenever you can. Turn on IO and time statistics at the same time so you have numbers to compare after each change: SET STATISTICS IO, TIME ON; -- run the query with "Include Actual Execution Plan" enabled SET STATISTICS IO, TIME OFF; Read from right to left Data flows from right to left. The operators on the far right read data from tables and indexes; each operato...
Read more