As Gartner analyst Merv Adrian once told me, “The greatest force in legacy databases is inertia.”
However much CIOs may aspire to digital transformation and modernization, they must still grapple with the reality of their incumbent infrastructure, not to mention their existing employees who know the old technology and may not want to learn new enterprise tech solutions. This is particularly true with databases: once the data is added to the database, there needs to be a compelling reason to move it out.
SEE: Hiring kit: Database Engineer (TechRepublic Premium)
Even so, over the past decade, enterprises have made significant shifts in the databases they use, as DB-Engines’ helpful video of database popularity trends illustrates. We’ve seen big proprietary databases leak market share to NoSQL databases and PostgreSQL. What we have not seen is either a wholesale dismissal of relational databases or a wholesale embrace of non-relational databases.
Why? Because change takes time. Also: because customers aren’t stupid.
Boring is good when it comes to databases
It can be tempting to think enterprises should rip and replace an existing technology with something shiny and new. Tempting, but usually wrong. It’s also easy to believe that the “best tool” can or should be selected in all cases.
But as engineer Dan McKinley has suggested, “The problem with ‘best tool for the job’ thinking is that it takes a myopic view of the words ‘best’ and ‘job.’ Your job is keeping the company in business … And the ‘best’ tool is the one that occupies the ‘least worst’ position for as many of your problems as possible.”
This is highly rational thinking. But we aren’t particularly rational at times with our IT choices.
Too often, developers skew toward using new technology simply because it’s cool or interesting, but they may not fully consider the impact its introduction and ongoing maintenance will have on the rest of the organization. For this reason, McKinley argues enterprises should embrace “boring” technology: solutions with well-understood capabilities and well-understood failure modes.
And then there’s the issue of ongoing operations for new database software. For example, it’s hard to get excited about enterprises embracing a dozen purpose-built databases to solve their graph, time-series, and other needs because of the associated operational overhead. There’s also the mental burden of learning and juggling a number of different databases.
The problem with operational overhead is one reason that, while we’ve seen database options mushroom (DB-Engines now lists nearly 400 databases, which is much higher than the 73 identified in 2012), customers seem to be congregating around relatively few, general-purpose databases.
This database tendency is admittedly “boring,” but, as McKinley argued, boring is good in enterprise tech. So how do enterprises embrace this boredom?
Why incremental database changes might be the right approach
This brings me to a conversation I had with Yugabyte founder and CTO Karthik Ranganathan. We got together to talk about a mutual customer, but we ended up talking about database purchasing trends in general. Yugabyte is an open source distributed SQL database company that extends PostgreSQL.
Some customers have applications that have been operational in some form for years or even decades.
For enterprise IT professionals who hope to change these applications, “rip and replace” will rightly sound daunting, as Ranganathan suggested: “If they have to unwind all that and write [the app] on top of a new stack, it’s probably not going to happen at all.”
Incremental, in other words, might be the right approach for businesses looking to make a change.
SEE: Hiring Kit: Database Administrator (TechRepublic Premium)
Such an incremental approach can also apply to how enterprises embrace new technologies. I’ve worked in and around NoSQL databases for almost a decade, and though they’ve clearly gained in popularity (see the video above), they also just as clearly haven’t eliminated relational databases. Some of that may be due to simple inertia, to borrow from Adrian, but some stems from the reality that different database approaches can be valuable for different business needs.
“Both relational databases and document databases have their place in terms of how developers think and model,” said Ranganathan. “This is not a war that one side wins: NoSQL or SQL. Neither side will ‘win,’ because there’s a real purpose and real value on [each] side.”
At the same time, we’ve seen general purpose databases, like MongoDB and PostgreSQL, become even more general purpose (note that I work for MongoDB). Yugabyte, for example, has extended PostgreSQL to make it more distributed and scalable, among other things. Redis Inc., in similar fashion, keeps adding to Redis to expand it beyond its original primary function as a cache.
As enterprises embrace these and other databases, sometimes they’ll do so at the expense of an existing investment (“or”), but usually it will be an “and” equation where they hold onto pieces of their existing tech stack. Why? Because enterprises are boring, and boring is good.
Disclosure: I work for MongoDB, but the views expressed herein are mine.
