Disclaimer

Last updated: 23 October 2026

The information on SQL & Cloud Lab (https://sqlcloudlab.blogspot.com) is published in good faith for general information and educational purposes only.

No professional advice

Articles, code samples and recommendations reflect the author's own experience and research. They are not a substitute for professional advice for your specific environment. Every system is different, so always test changes in a non-production environment and take a backup before applying them to production.

Accuracy and pricing

Cloud services, features and prices change frequently. While every effort is made to keep content accurate and up to date, no guarantee is given that information is complete, current or error-free. Always confirm current pricing and features in the official documentation, such as Microsoft Learn and the Azure Pricing Calculator, before making decisions.

Limitation of liability

Any action you take based on information from this blog is strictly at your own risk. The author will not be liable for any losses, outages, data loss or costs arising from the use of this website or its content.

Personal views

The opinions expressed here are the author's own and do not represent the views of any current or past employer or client.

External links

This blog links to external websites for reference. These links are provided for convenience; there is no control over their content, availability or privacy practices, and a link does not imply endorsement.

Advertising and affiliate links

This blog may display advertising, including Google AdSense, and some posts may in future contain affiliate links. If you buy through an affiliate link, the blog may earn a small commission at no extra cost to you. Any such links will be clearly disclosed, and they never influence the recommendations made here.

Trademarks

Microsoft, Azure, SQL Server, .NET and other product names are trademarks of their respective owners. This blog is independent and is not affiliated with, sponsored or endorsed by Microsoft or any other company mentioned.

Consent

By using this website, you agree to this disclaimer. It may be updated from time to time, and changes will be posted on this page.

Comments

Post a Comment

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