• Stairway to Columnstore Indexes Level 1: A First Look At Columnstore Indexes
• A Beginner’s Guide to SQL String Functions
• Take the 2020 State of Database DevOps Survey – win a new iPad
• Free eBook: SQL Server Backup and Restore
• From the SQL Server Central Blogs - Distributing Jupyter Notebooks
• From the SQL Server Central Blogs - Resetting an Azure SQL Database Admin Password

• Renaming Columns

Data Gravity

I've seen a few people use the term data gravity in the last few months. I wasn't quite sure what this meant to me, and it seemed that people used it in a few ways, but someone sent me a link to this short piece on data gravity in the cloud. This piece is really in relation to Salesforce and their goal to build database.com and gather more of their customers' data into a virtualized view where you can access all (or most of your data) from your Salesforce applications.

This isn't a new idea, as the goal of many companies has been to have a unified view of their data. I've often seen this in relation to customers as the single view of a customer. There are numerous explanations of this, as many organizations want to find a way to build this for their own use. I actually think this is a trend, and the changes in SQL Server 2019 with Big Data Clusters, as a more basic platform integration of this concept. We want to query data where it lives, not move it (really, copy it) to another system for analysis.

While there are lots of articles written about data gravity based on that initial blog, it seems that they all relate to the idea of applications and services needing more bandwidth and lower latency to grow. That might be true, but I think we've seen another type of gravity in RDBMS systems. As the amount of data grows, certainly more people want access, and there is a need for higher availability and greater performance. Many of us see this in the systems we build and manage, whether we are developers or administrators.

What I think of as more of an attractive force, however, is the tendency of a system to stagnate a bit and slow down other work. We find it more difficult to grow and change large systems. Our developers become more hamstrung, and we start to struggle to adapt to new requirements. Certainly we struggle to adapt at the speed with which our organizations would prefer we move. There also becomes this gravity that limits the thinking that your staff may have about how to work with the system.

These are the challenges that I see driving many people towards compliant database DevOps solutions. I talk with quite a few customers that want to go faster and more easily adapt to changing requirements in their database systems. However, the gravity and inertia of working a certain way often limits their willingness to adapt to new tools and techniques. Usually there is this cultural gravity more so than technical gravity, which might be the stronger forces. Especially among managers.

Steve Jones - SSC Editor

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