I agree to TechTarget’s Terms of Use, Privacy Policy, and the transfer of my information to the United States for processing to provide me with relevant information as described in our Privacy Policy.

Please check the box if you want to proceed.

I agree to my information being processed by TechTarget and its Partners to contact me via phone, email, or other means regarding information relevant to my professional interests. I may unsubscribe at any time.

Please check the box if you want to proceed.

By submitting my Email address I confirm that I have read and accepted the Terms of Use and Declaration of Consent.

hype as superfast and crazy cheap, hundreds of thousands of workhorse relational databases in use today will be put out to pasture. Who needs a 20th-century relational database when you can have a decidedly more modern NoSQL, columnar or in-memory database -- or even the Hadoop Distributed File System?

Most organizations, it turns out. At least for now.

While the seductive powers of the new database technology are not to be denied, you should resist the siren song of the new, post-relational database vendors. Not because the new database options lack merit -- on the contrary -- but because making your company's next database move a technology decision is the wrong way to go about it. The choice of database should be secondary. Your business goal -- that comes first.

A very good place to start

The choice of database should be secondary. Your business goal -- that comes first.

Consider a battery of practical questions about your project: Are you creating net new applications in support of net new business processes or merely upgrading the ones you already have? Engaging new types of users, data or analysis? Supporting a new line of business or reinvigorating an existing one? Answers to these questions will provide essential criteria for understanding which new database technology, if any, to deploy.

Only then should you look around to see whether a new database is better for the job than something you already have.

Implementing a database of any kind isn't cheap. While many of the new varieties are open source, they aren't free -- and even more costs enter the equation when a project involves migrating an existing relational database to one of the newbies. Myriad complexity issues also stand in the way.

New database technologies, particularly in-memory ones, often need new hardware. Many of the available options promise to lower total cost of ownership over time -- but new hardware will have to be obtained, and that up-front cost must be taken into consideration.

The fine print

Finding people with the right skills is an even bigger issue. The new models may require fewer administrators -- most proponents insist that their databases are less expensive to implement and manage than old-school relational databases are. And in many cases that's an easy argument to make: Top-tier database administrators are some of the highest-paid people in the IT department, and their numbers -- most relational databases are notorious for the number of admins required to keep them finely tuned -- clearly add significant costs.

But the likelihood of finding a Hadoop or columnar database expert in a traditional relational database shop is slim, which means you'll have to go out and hire these in-demand people or get the required skills from a consulting company.

And, as anyone who has worked to bring a major application project to fruition can attest, the bulk of the complexity is centered on everything but the cost of the software license. Creating new algorithms, analytical models, transactional components and business processes that need to be engineered and implemented is where the real expense is. Until they're well understood and the necessary stakeholder input and approvals have been obtained, the choice of database technology is at best a distraction. At worst, it's a great way to knock a project off its axis and send it spinning out of control.

Think big

This is particularly true in the era of big data, which is driving a considerable percentage of the new application projects in organizations. For many, big data projects involve data types that are new, unfamiliar and often unstructured -- time-series data, Web server logs, text. While some new database technology might eventually need to be deployed, figuring out what the new data sources are and what the new algorithms should look like must be the first order of business, right after you've reached agreement on what the new business processes are all about. To do otherwise is to march your company down the path of cost overruns, scope creep and eventual if not inevitable failure.

About the author:Joshua Greenbaum is an independent industry analyst and founder of Enterprise Applications Consulting in Berkeley, Calif. Email him at josh@eaconsult.comor follow him on Twitter: @josheac.

2 comments

Register

Login

Forgot your password?

Your password has been sent to:

By submitting you agree to receive email from TechTarget and its partners. If you reside outside of the United States, you consent to having your personal data transferred to and processed in the United States. Privacy

I agree. SQL technology displaced a lot of other technologies, sometimes appropriately, and sometimes riding the very same wave of "novelty" that this article attributes to NoSQL. This time around, maybe organizations can purchase based on actual features and need, not on what the latest trend says.