I recently saw a piece by Matt Aslett, Principal Analyst at 451 Research on multi-model databases. (Click here to read the full article.)

At NuoDB we have a lot of respect for Matt and his viewpoints.  In fact, he was recently featured as a speaker at our live-streamed launch event.  (Watch him here.)

He mentions us in the blog (thank you, Matt) but I’d like to expand on his comments here.

The NuoDB SQL engine is a personality for the atom layer.  We are actively working on personalities other than the default SQL personality.  That’s a technical point and not very interesting in itself.  The interesting part is why.

The answer is more or less what you write about in your post.  Our view stems from the thinking behind this post (from 2011)

Basically there is no technical or architectural reason that a single system should not be very good at the various things that we currently think of as different segments of the database market.  A well-designed database engine can do an excellent job of SQL, NoSQL, OLTP, analytics and various niche things.  Of course Mike Stonebraker is right that a specialist engine can do a narrow thing very well, but the question is whether specialist engines will ultimately be generally interesting or confined to very narrow niches (possibly very high value niches).

The long-term answer is not a matter of technical debate.  Rather it is a market dynamic.  And, FWIW, what the market wants is vendor consolidation and architectural simplicity.  Pain and cost increase sharply for an IT department when you introduce multiple database systems, and particularly when you have to replicate data between them, or start yet another dreaded ETL project.  Fortune 500 CIOs consistently tell me that they want to consolidate, to gain simplicity, reliability, higher data quality, and huge cost savings.

I don’t agree with the frequent assertion that we will forever more live in a world of “polyglot persistence” or increasing fragmentation of the database space.  For some years my prediction has been that the NoSQL vendors will have to (try to) add SQL and transactions (to really become the “Not only SQL” vendors that some have cast them as), the BI and operational database worlds will converge (witness the SAP HANA stance), and the traditional SQL vendors will all add document (JSON) and KV capabilities.  One would expect Graph to join the party in due course. In other words there will be a technical and market consolidation.  Your database landscape chart may get a little busier in the short term but then it will rapidly reduce back to a small number of vendors, each with an increasingly broad offering.

So – back to the NuoDB point.  We are delivering what we call personalities for our atom layer.  No formal announcements today.  But when we name names and dates, personalities will be really transactional, really scale-out, really low latency document-oriented capabilities.  Every CIO would want to support Oracle workloads, Mongo workloads, Hadoop workloads etc., from the same scale out server.  It’s all part and parcel of Cloud Data Management System Rule 12!

For the record my view is that it’s not about “neither fish nor fowl;” it’s about people beginning to realize that their little piece was never the whole jigsaw puzzle.  And the big question is who has started in the right place to deliver the whole puzzle.

Of course we note this is what we at NuoDB have been doing all along.