Why modern applications demand polyglot database strategies

Commentary: Ready to move all your applications to NoSQL databases? It's not that simple. <a href="https://www.techrepublic.com/article/why-modern-applications-demand-polyglot-database-strategies/#ftag=RSS56d97e7">Source TechRepublic.com</a>

Commentary: Ready to move all your applications to NoSQL databases? It’s not that simple.

Big data analysis, unstructured database processing metaphor, large volume of white puzzle jigsaws with alphabets pouring from bottle combine word DATA on red fabric background with copy space

Image: Nuthawut Somsuk, Getty Images/iStockphoto

For someone who cut his teeth on relational databases at Oracle right out of college, Mark Porter sure seems happy to leave them behind. In announcing his new position as CTO at MongoDB, the company behind the eponymous document-based, distributed database, Porter took some shots at the relational world he’s left behind. 

This isn’t to suggest relational data is dead, or even limping. Instead, Porter’s ability to straddle the worlds of NoSQL (MongoDB) and SQL (Oracle) simply suggests that data is a lot more complicated than can fit on a bumper sticker, and we’re nowhere near being able to call it a “solved” problem.

SEE: How to build a successful developer career (free PDF) (TechRepublic)

A new world of data

When Porter started at Oracle (1988), MongoDB didn’t exist. Heck, at that time, MongoDB co-founder Eliot Horowitz was still in elementary school. So Porter (and the rest of the world) had no idea what he/they might be missing in those rows and columns of relational data. It wasn’t until 2009 that MongoDB shipped and upended the database world. 

Eleven years later, Porter had this to say about this brave new world of data:

No matter how amazing databases have been…building apps on them has never been simple. Normalized data, mathematically pure or not, is agonizing for humans to program against; it’s just not how we think….And while SQL might look pretty in an editor, from a programming point of view, it’s close to the hardest way to query information you could think of. Relational databases tout their fixed and predictable data model as a feature, but in reality, inflexible data models are a shackle around any real world developer’s productivity. Just ask any CIO how often they “roll new schema” to their application fleet, and they typically put their head in their hands and mumble ‘Once a quarter..if we’re lucky.'”

And yet…Porter’s original world of relational data is very much with us. Those ERP systems that SAP made $27 billion selling last year? Mostly relational data. Indeed, take all those systems of record that organizations use to help manage employees, or track widgets in their supply chains, etc.? Almost entirely relational data. In fact, developers still use the venerable RDBMS for everything from online ticket sales to advertising systems

As such, as much as Porter is correct that developers love the flexibility of newer approaches to data management like MongoDB, many also will continue to rely on the RDBMS. 

Or something new.

Database proliferation

If anyone thought we’d figured out databases, all they need to do is take a look at DB-Engines, which currently tracks over 350 different databases, of all sorts of shapes and sizes. From relational to document to graph to key-value to multi-model to…you name it. Over the past decade, in particular, we’ve seen database options explode. 

While no developer could hope to become proficient in 350 databases, or even 35, the fact that we have this level of choice speaks to the desire of many people to build better, easier ways to manage ever-changing data. It also speaks to an inefficient drive among some to reinvent the database wheel, rather than partner on a few projects. As analyst Curt Monash has noted, “Developing a good [database] requires 5-7 years and tens of millions of dollars. That’s if things go extremely well.” There are no exceptions to this rule.

Take MongoDB, for example. It’s about as close to an “overnight success” as we have in databases, and it took a decade and hundreds of millions of dollars to reach its current level of popularity (fifth on the DB-Engines ranking). Though people keep creating new databases, it might be more cost-effective to contribute to existing open source database projects to help them gain the capabilities perceived to be missing. 

And yet…forks happen. Often existing projects won’t accommodate new directions. Sometimes their architecture won’t, either. For Redis founder Salvatore Sanfilippo, he told me the Redis example serves as a reminder that it’s “possible to explore new things” in areas like databases even if everything looks “solved.”

This means we’re probably going to get more than 356 databases, even if we don’t actually need “more” databases that we regularly use. Whether we rally around a few existing projects or innovate new ones, the future of data is “more.”

Disclosure: I work at AWS, but this article reflects my views, not those of my employer.

Also see

Source TechRepublic.com