Privacy Policy

Last updated: 23 October 2026

This Privacy Policy explains what information is collected when you visit SQL & Cloud Lab (https://sqlcloudlab.blogspot.com), how it is used, and the choices you have.

Information we collect

This blog does not ask you to create an account and does not collect personal information such as your name or email address unless you choose to provide it, for example when you leave a comment.

Like most websites, this blog and its service providers may automatically collect standard technical information, such as your browser type, device type, approximate location, the pages you visit and the time of your visit. This information is used to understand how the blog is used and to improve it.

Hosting by Blogger

This blog is hosted on Blogger, a Google service. Google may collect and process information about visits to this blog as described in the Google Privacy Policy.

Comments

If you leave a comment, the name and any profile information you choose to use, along with your comment, will be visible to the public. Comments are handled by Blogger and are subject to Google's privacy policy.

Cookies

Cookies are small text files stored on your device. This blog, Blogger and third-party services used on it may use cookies to remember your preferences, measure traffic and serve advertising.

You can block or delete cookies through your browser settings. Some features of the site may not work correctly if cookies are disabled.

Advertising and Google AdSense

This blog may display ads served by Google AdSense and other third-party ad vendors.

  • Third-party vendors, including Google, use cookies to serve ads based on your prior visits to this website or other websites.
  • Google's use of advertising cookies enables it and its partners to serve ads to you based on your visits to this site and/or other sites on the Internet.
  • You may opt out of personalised advertising by visiting Google Ads Settings. You can also opt out of some third-party vendors' use of cookies for personalised advertising at www.aboutads.info.

To learn more, see how Google uses information from sites that use its services.

Analytics

Visitor statistics are provided by Blogger and may also be collected through Google Analytics. These tools report aggregated information, such as page views and traffic sources, and do not identify you personally to us.

Links to other websites

Posts may link to other websites, such as official documentation. We are not responsible for the content or privacy practices of those sites, so please review their policies.

Children's privacy

This blog is intended for a general, professional audience and is not directed at children under 13. We do not knowingly collect personal information from children.

Your rights

Depending on where you live, data protection laws such as India's Digital Personal Data Protection Act or the EU General Data Protection Regulation may give you rights over your personal data, including the right to access, correct or delete it. Because this blog collects very little personal data, most requests can be handled through Google's tools, or you can contact us as described below.

Changes to this policy

This policy may be updated from time to time. Changes will be posted on this page with a new "Last updated" date.

Contact

If you have questions about this Privacy Policy, please leave a comment on any post and we will respond.

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