NoSQL Benchmarks NoSQL use cases NoSQL Videos NoSQL Hybrid Solutions NoSQL Presentations Big Data Hadoop MapReduce Pig Hive Flume Oozie Sqoop HDFS ZooKeeper Cascading Cascalog BigTable Cassandra HBase Hypertable Couchbase CouchDB MongoDB OrientDB RavenDB Jackrabbit Terrastore Amazon DynamoDB Redis Riak Project Voldemort Tokyo Cabinet Kyoto Cabinet memcached Amazon SimpleDB Datomic MemcacheDB M/DB GT.M Amazon Dynamo Dynomite Mnesia Yahoo! PNUTS/Sherpa Neo4j InfoGrid Sones GraphDB InfiniteGraph AllegroGraph MarkLogic Clustrix CouchDB Case Studies MongoDB Case Studies NoSQL at Adobe NoSQL at Facebook NoSQL at Twitter



The evolution of databases - Teradata’s take

In a post with an inspired titled, “We are the Borg! You will be assimilated. Resistance is futile.“, Dan Graham of Teradata exposes how the database evolution and market looks from their perspective:

In the Star Trek movies, “the Borg” refers to an alien race that conquers all planets, absorbing the people, technology, and resources into the Borg collective. Even Captain Picard becomes a Borg and chants “We are the Borg. You will be assimilated. Resistance is futile.”

It strikes me that the relational database has behaved similarly since its birth. Over the last thirty years, Teradata and other RDBMS vendors have innovated and modernized, constantly revitalizing what it means to be an RDBMS. But some innovations come from start-up companies that are later assimilated into the RDBMS. And some innovations are reactions to competition. Regardless, many innovations eventually end up in the code base of multiple RDBMS vendor products —with proper respect to patents of course

That’s true. But let’s look at the spectrum of options. On one side, you have old products engulfing new features now and then, depending on the market needs and trends. What you get some mammoths that are trying to do everything. Try is the keyword here. It’s one thing to list a feature on a checklist, another to have it working on the lab, another to have it working for a wide range of use case, yet another to work well, and last, but not least, to have it scale and adapt with the needs of your users. What’re your options if you need to scale a part of your system only? What if you the checklisted feature is not solving your problem?

At the other end of the spectrum, you have younger, specialized solutions that most of the time focus on solving specific problems. Indeed, you have to deal with the added complexity of managing heterogeneous systems. And yes, you have to deal with making them work together to solve your problem. But if something doesn’t fit your needs or you need to adapt fast or you need to scale a part of your application, then you can really do it.

What would you choose?

Original title and link: The evolution of databases - Teradata’s take (NoSQL database©myNoSQL)