Fast Enough

Steve Jones, 2019-01-24

Will RDBMS ever be fast enough? It's not likely, and this opinion piece notes that really any database won't be fast enough. Data volumes are exploding and the demands by users are increasing as new creative ideas abound. This means that we will constantly struggle to keep up with the workload demand. I agree with that part of the piece.

Where I start to disagree is with the idea that sticking with the traditional vendors of databases (Oracle, IBM, and Microsoft) is not a great idea. Even if these vendors adopt new technologies that are being put forth by disruptive startups, the author seems to think that we would be better off adopting some alternative technology from the NoSQL space. There's even a nod that younger millennials don't think that the big vendors' software is feasible. 

While I do think that many younger developers get excited by new technologies, I'd note that many of us older developers used to be young and get excited by new technologies as well. We just temper that with some experience to note that there are rarely magic bullets in technology and much of what we choose to implement has its own disadvantages and tradeoffs. While some might be worth making, not all are.

I do think that some of the technologies that have been developed by vendors in the NoSQL space are useful. Microsoft sees that and the Big Data Clusters coming in SQL Server 2019 are an attempt to access more data and make it useful to an organization. The addition of Machine Learning Services in the last two versions was another way in which the "same old, same old" product from this vendor is growing to accommodate the needs of more customers.

That doesn't mean I view all other types of database technologies as useless. Certainly there are problem domains where a graph database or a key-value store might provide lots of advantages. More and more customers and clients are integrating other databases in strategic places. Redis and Elasticsearch are incredibly popular, and they work very well on certain problems.  Other databases are worth investigating, though moving wholesale to a new technology based on a Proof of Concept, no matter how complex, is something I wouldn't recommend.

The challenge, as always, is getting the data to the engine that can process it. Throwing every query and workload onto your OLTP database is a recipe for disaster, though using ETL processes to copy data to other systems is a complex, though viable, alternative. It just takes work.

Systems are never fast enough for all users, but they often work very well for most of us. Don't get caught up in a new technology and expect it to solve all your problems. Likewise don't be close minded when it comes to evaluating another database engine. Follow the DevOps philosophy. Do more of what works, less of what doesn't, experiment, and always be learning.





Related content


Will the next version of Windows be a “Mini-Me” version of Vista? Who knows, and it’s too early to tell, but apparently there’s a mini-kernel version of Windows 7, the one after Vista, which fits into 25MB on disk. That’s a touch lower than the 4GB that Vista takes up. Granted it’s not a full […]

Steve Jones


59 reads

An Hour in Time

Daylight Savings time switches a little later this year. In fact it’s November 4th this year, after having been in October for all of my life. In case you don’t remember which way we move the clocks, here’s a saying: Spring forward, fall back.

5 (1)

Steve Jones


199 reads

Software is Like Building a House

One of the really classic analogies in software is that it’s like building a house. You have a foundation, multiple teams, lots of contractors that specialize in something, etc. And it’s an analogy that’s debated as to its relevance over and over. I won’t go into the correctness of this analogy, but I wanted to comment on it.

Steve Jones

2012-10-08 (first published: 2007-10-05)

289 reads