How to choose a database (hint: boring is good)
With hundreds of databases to choose from, Yugabyte’s CTO offers insight into how to select the right one for you.
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.
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.
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.
