About

Hi, I'm Linga, and this is SQL & Cloud Lab: practical guides on SQL Server, Azure SQL and .NET for developers and architects who want answers they can actually use at work.

Who I am

I'm a .NET and SQL Server architect with more than 18 years of hands-on experience building and running enterprise systems: payroll platforms, insurance applications and manufacturing systems, where a slow query shows up as a missed deadline or a bigger cloud bill.

I hold Microsoft certifications in Azure development (AZ-204), Azure administration (AZ-104) and DevOps (AZ-400).

Start here

New to the blog? Pick the guide that matches what you're working on:

What you'll find here

  • Azure SQL and cloud cost guides: choosing the right service and tier, and keeping costs under control
  • SQL Server performance: indexing, execution plans, deadlocks and query tuning
  • Migration guides: moving on-premises SQL Server workloads to Azure
  • .NET and DevOps: data access patterns and CI/CD for .NET applications on Azure

How I write

Every technique here is one I've used on real production systems. Code is tested before it's published, facts are checked against official documentation, and posts are updated when Azure pricing or features change.

Disclaimer

The views on this blog are my own and do not represent any employer or client. Content is for general information; always test changes in a non-production environment and check current pricing before making decisions.

Get in touch

Have a question or a topic you'd like covered? Leave a comment on any post or use the Contact page. I read them all.

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