Confused by the glut of new databases? Here’s a map for you

36 Comments

The flurry of database action over the past year rendered the usual discussion around structured or unstructured, SQL, NoSQL, and NewSQL databases even more, um, nuanced than before.  Matthew Aslett, research manager at 451 Research took the bull by the horns and updated his previous (one-month-old) database road map to include all sorts of new entries. And here (drumroll please) is the result.

Database landscape map

Click map to enlarge.

For comparison, check out Aslett’s next-most-recent database subway map, published in November 2012.

olderdblandscape

Click map to enlarge.

Note that the updated chart includes such shiny new entries as Akiban, NuoDB, and Parelastic. Kudos to Aslett for sussing this all out. I, for one, plan to print this out as a handy visual aid.

36 Comments

michalinet

I would love to see another line that tracks which of these new generation of databases already have the enterprise features that organizations need to ensure the viability and security of their applications: back-up, disaster recovery, high availability, fine-grain security, ACID transactions.

I know MarkLogic is enterprise ready — has been for years!

Nathan Weyer

I guess the big question is, how many of these actually expressively different as opposed to equivalent to each other with a little syntactical sugar added?

Seems like databases go through the same pattern as languages, people doing the same thing over and over with new go-faster stripes painted on the side

simonbrangwin

It’s good to see Trinity included in the graph databases. Eagerly awaiting Microsoft Research labs to release v1 of this exciting project as my company already has use-cases that only graph databases can solve effeciently (huge, multi-dimensional organisation strucutures). Neo4J is out because we have no familiarity with Java.

Kyle Hailey

The graphics seem gratuitous and confusing. Creating confusing graphics might have been the intention since the title uses the word “confused”.
What is the purpose of the line and proximity in the top graphic? Having lines and using proximity to show a timeline and evolution might have been interesting, like the UNIX timeline graphics
http://files.cyberciti.biz/uploads/tips/2007/06/44218-linuxdistrotimeline-7.2.png
Another option would be showing market size over time
– Kyle Hailey
http://dboptimizer.com
PS if you have the data, maybe you could put a link to a spread sheet and other people could riff on the visualization

Massoud

Great work Matt.

There is so much info that I think you are going to need a DB to store it all :)

If so which one? :)

LordWabbit

You also forgot to include Firebird, or I might have missed it?

Fred Bakker

Sorry, But I miss the PI database and the R:Base database in the picture.

lukaseder

I’m missing a couple of databases in the relational section:

Java databases:
– Derby
– H2
– HSQLDB

Other, larger players:
– CUBRID
– Firebird
– Sybase SQL Anywhere

✔ Eric David Benari, PMP

Also, the chart is missing FoundationDB – plus, why is MongoHQ and MongoLab on there? They are offering a cloud-hosted MongoDB installation which is cool, but that is not a different database than MongoDB.

✔ Eric David Benari, PMP

I don’t believe that 90% of these will be gone or that most will be gobbled up by Oracle, most of the new DBs are purpose built and IMO will have a following for many years. The nature of a data-store is that it gets users quite-married to the product (often is cost-prohibitive to switch later), so if they get traction now they will likely maintain it for at least a few years.

A bunch of the new DBs on the chart have presented at NY’s Database Month festivals (disclosure: I am the organizer) and each has demonstrated areas where they have specific advantages over the alternatives.

Adron

I’d also argue (and I do work for Basho makers of Riak…)

But arguing that the market is going to limit or buy up a lot of these is like saying that we’ll limit the types of design patterns we use in software development. There’s tons of them out there. It just happens that often someone sort of “owns” a database versus nobody owning design patterns.

The companies may change, but the data models and designs are here to stay (not that they weren’t before, just underutilized by limitations of technology & thinking).

scott herson

10gen’s MongoDB will gobble up a big portion of the market in 2013.

Eric Jensen

Berkeley DB also has a SQL API, so really belongs on the edge between k/v and relational.

Also is SQLite really not on here? Am I just missing it? Sure it’s for small data sets, but the install base is easily bigger than half this list combined.

Matt Aslett

Yes I did miss SQLite. Not sure how – could have sworn it was on there. Thanks Eric. I’ll try and figure out how to best reflect BerkeleyDB SQL API as well.

Please add any tweaks and suggestions here: http://bit.ly/U0govc

Dev

Impressive infographics but as Matt said — 90% of these upstarts will be gone in 3 years.

There is a huge Silicon Valley echo chamber effect at play here. People forget that the big guys like Microsoft and Oracle will (or already) have their own NoSQL, Hadoop, etc offerings and that the small players will be eaten alive.

Real companies in mid-America will go with Oracle and SQL Server 9 out of 10 times over some cool, new buzzy NoSQL memcache mambo-jambo.

Barb Darrow

there’s no question that some of these new-age “buzzy” companies will get acquired — maybe by microsoft or oracle or SAP or some other vendor. The question is which and by whom. But is there really no room for an up-and-coming database company to bulid a standalone company?

Serious question. What do you think?

Michael Waclawiczek

For full disclosure, I work for NuoDB and am therefore biased in my views, but I am absolutely convinced that there is room for new database companies particularly if they solve some of the fundamental architectural deficiencies of traditional SQL database systems. We have gone from mainframes to client/server based systems and the 21st century systems will be based on elastically scaleable, distributed system architectures.

Dev

I think it’s more likely that the majority of these new-age “buzzy” companies will simply go out of business or at best get acqui-hired rather than achieve a meaningful exit.

Dev

Adron

Microsoft uses Hadoop. Because OSS out develops and innovates them on a regular basis. Oracle just tries to buy everything and is backing – and limiting their customers – into a corner. Buy at your own risk into that world.

Companies go with RDBMSs from those two because 9 out of 10 times they don’t know any better. Hopefully people can wise up a bit and look at what is out there that can and does work better for their particular situation. Frequently, probably 9 out of 10 times, I see an RDBMS and transactions aren’t used, referential integrity isn’t even applied, nobody is using stored procedures, built in capabilities or otherwise. Large segments of the financial sector continue to use RDBMSs as dumping grounds for data, something they’re actually ill-suited for.

Just saying, 9 out of 10 times is a bad situation to be in. It’s a poor utilization of available options.

-and yes, I work for Basho but I speak from a general perspective of having been on more than one and led more than one large enterprise team. I’ve seen the successes and failures of teams trying to jam everything into an RDBMS as if they are a panacea.

David Roussel

Maybe some will disapear, or go dormant. But it’s like that in three years there will be even more products in this space than there are now. As more developers see deficiencies in existing systems.

As for whether risk averse companies stick to relational: I’m sure they will. But they will introduce no-sql databases in places where it makes sense, perhaps in small parts of thier systems. Or simply where it’s cheaper.

andyhardy

Agreed, most companies wil pick the ‘safe’ options of Oracle or SQL Server when looking at a new project. These companies are usually looking at a cradle-to-death life-time of 10 years or more, they can’t easily decide to choose a database that may not even survive the time that it takes to roll-out, never mind old age support.

Start-ups don’t have these issues: they may not be around to need old-age support and they recognise this.

sachinghai

Matt/451’s chart has been very useful – and the good thing is that it has been updated regularly and has continued to evolve.

One of the noticeable difference in the new version (besides the content) is the background watermark. The reason for that can be attributed to Matt’s statement in his blog “We’ve seen it crop up in other presentations and websites – sometimes even with attribution”

Matt Eagar

90% of these will be gone in 5 years, and we’ll still have too many. This space is way too crowded right now.

Adron

That would be bad.

…all innovation and development of products would die. Somebody has to be left standing so they can steal or buy them at some point.

Anonymous Coward

Sure they will, but that’s the characteristic of a healthy ecosystem: lots of different evolutionary directions being tried out at all time, with only the viable ones surviving.

An ecosystem with just a few species is an unhealthy one. In particular, it is always brought about by external measures directed at pruning species – like for instance agricultural plantations. Consider what the equivalent of a plantation would be in the database space: a few large solution providers, running business operations optimized for maximum yield and low operational costs, not for customer/user convenience, systematically killing off any effort to provide an alternative, and at the same time very careful not to allow mutations to the solutions they provide, or to the sales and distribution mechanisms. Would you really prefer such an ecosystem? The price for having a healthy space of database solutions is the added cost of redundant/wasted development effort and the higher effort for choosing the right solution, but it’s IMO a price well worth paying – you’d spend more trying to shoehorn your application on an inadequate storage model.

Comments are closed.