T-SQL Language Changes in SQL Server 2022 Part 2 (2022-09-30)

Daily Coping Tip

Find a new way to use one of your strengths or talents

I also have a thread at SQLServerCentral dealing with coping mechanisms and resources. Feel free to participate.

For many of you out there working in a new way, I'm including a thought of the day on how to cope in this challenging time from The Action for Happiness Coping Calendar. My items will be on my blog, feel free to share yours.

Cloud Databases

Most of us are used to a database that lives on a server somewhere. It might be in our data center or a VM that exists somewhere, but it's really an on-premises type of infrastructure. Even if the VM is in AWS or Azure, this is a single system on a server that we control. We can add HA capabilities to this system, but the model is the same as if the database were on our development workstation.

Note: this doesn't matter if this is an RDBMS like SQL Server or PostgreSQL or a NoSQL type system, such as MongoDB or Neo4J.

That's a comfortable system, and it's how we've built many applications over the years that support our business processes. Many of us default to architecting and thinking about our applications with this model.

These days there are cloud databases, which can be used in this model, but which also have other capabilities. I ran across a piece that noted cloud databases ought to be a part of our modern tech stack, and I tend to agree. These days the need to be more flexible, available, and secure are important for applications. An on-premises database might not meet these needs.

A cloud database is typically a system designed to be more of a PaaS service, with replication, built-in HA, scaling, and more. Azure SQL Database might be considered cloud-native, but I think it lacks some of the features that we might take advantage of in CosmosDB, Couchbase, or CockroachDB. Things like the availability from various types of connections, quick and easy failover and sync from different regions around the world, and low latency for users anywhere.

A few examples are in the article, and I see these types of requirements coming about more and more often as our clients start connecting from different devices in different locales, and at scales that are harder to handle with a single on-premises (or clustered) database system. While you might be able to handle the workload, is it worth it for you to manage some of the infrastructure and administration that a cloud vendor can do instead?

That is why I think you ought to learn about and understand where a cloud database might be useful. While not all of us have clients all over the world needing real-time access from various devices and applications, we might grow into that need. Whether it's clients that are employees or customers, there are increasing demands for flexible ways to handle the growing workloads on our databases. You want to be prepared for when you might exceed the capabilities of the platform you're used to, that way you can decide when adopting a cloud database might make sense.

Steve Jones - SSC Editor

Join the debate, and respond to today's editorial on the forums