{{ searchResult.published_at | date:'d MMMM yyyy' }}

Loading ...
Loading ...

Enter a search term such as “mobile analytics” or browse our content using the filters above.


That’s not only a poor Scrabble score but we also couldn’t find any results matching “”.
Check your spelling or try broadening your search.


Sorry about this, there is a problem with our search at the moment.
Please try again later.

The web is literally built on databases. The majority of your favorite websites are probably driven by one or more relational databases.

But there's a "movement" afoot. Its goal: provide a superior alternative to popular RDBMSs like MySQL and Microsoft SQL Server.

Dubbed "The NoSQL Movement" by Dave Kellogg, the CEO of Mark Logic Corporation, a growing number of developers are turning away from traditional RDBMSs and turning to alternatives with names like Hadoop and Cassandra.

In a post on the subject the other day, Kellogg details what's driving the movement. Big factors: performance, scalability and costs. For super-popular consumer-facing web services like Facebook and Twitter, using RDBMSs is not only costly, it becomes technologically challenging.

The growing prominence and popularity of 'NoSQL' alternatives, which can sometimes provide for greater performance, especially with large volumes of data, is a good thing. RDBMSs certainly have their limits, and it's nice to see innovation delivering new solutions. But as Kellogg notes, there's also a lot of hype around NoSQL. That's not necessarily a good thing.

Inevitably, more and more businesses will see popular services like Facebook and Twitter moving over to NoSQL alternatives and they'll wonder what it's all about. Some will even go so far as to adopt NoSQL solutions without doing a cost-benefit analysis. Case in point: I recently read an RFP for a development project that required the use of Cassandra for some data storage. In my opinion, there was absolutely no need for it, outside of the fact that the client thought Cassandra was cool and assumed that its service would become really, really popular some day.

In my opinion, businesses should be careful when considering NoSQL solutions. Not only will the vast majority of web-based applications never reach the scale at which these become attractive, the relative immaturity of most NoSQL solutions means that there's a much smaller pool of competent developers who have expertise with them. Obviously, if you're running a service like Facebook or Twitter, that's not an issue, and the cost savings from moving to these solutions makes them worthwhile. But for smaller companies and entrepreneurs, the maturity of RDBMSs like MySQL means that it's far easier (and less costly) to find experienced developers to build and maintain applications that run on them.

Will there come a day when RDBMSs share the spotlight with alternative solutions? It's quite likely. But the RDBMS (and SQL) aren't going anywhere anytime soon.

Photo credit: pvera via Flickr.

Patricio Robles

Published 26 February, 2010 by Patricio Robles

Patricio Robles is a tech reporter at Econsultancy. Follow him on Twitter.

2451 more posts from this author

Comments (7)

Save or Cancel

Andrew Ingram

You make a good argument, but you're overlooking another fairly significant feature that many of the 'NoSQL' solutions provide, and that is schema-less storage.

Long before they have issues with scale, many websites will reach a level of complexity where they're trying to bend SQL into support increasingly generic data structures. The problem with this is that this process also requires the addition of new tables with increasing use of computationally-expensive joins.

There are two particular scenarios where I feel a 'document database' is more suitable than SQL, 'product' catalogues and logging. The reason is that these two functions generally reach the point of adding expensive tables or ugly columns fairly quickly as a site grows. With logging especially, you often want to store data before you have really thought out how you plan to use it, so you don't want to invest time in working out the best relational database structure for the task. And product catalogues? You will often be filtering, faceting and sorting on such a range of fields that it's just easier to use a structured document database rather than worry how to do it with a relational database.

about 7 years ago


Dave Armstrong

I think the performance issue can't be understated. when you reach the volume that facebook, twitter and others have you just can't effectively do that with MySQL. Social networking sites are perfect candidates for NoSQL solutions because of the asynchrnous replication and, as andrew has pointed out, the document structure just fits better.

almost 7 years ago




Looking up for the information for a paper on teeth diseases I came across dentistsurgery.com site. The information presented there is indispensable: 5 main teeth diseases described in each detail with pictures and advice how to prevent them! My paper was the best one in my group!     

almost 7 years ago

Sascha Ehrentraut

Sascha Ehrentraut, Activation Director at MEC Global


almost 7 years ago

Alec Kinnear

Alec Kinnear, Creative Director at Foliovision

Thanks for bringing this issue up Patricio. MySQL is great as long as you are still on a single dedicated server or even a small cluster. Unless your site goes beyond that, there's no need to reinvent the wheel. But boys with toys...

almost 7 years ago

Patricio Robles

Patricio Robles, Tech Reporter at Econsultancy


You make a good point about schema-less storage, but I also think we shouldn't forget that a lot of the issues that come up with relational databases are the result of poor planning and design.

In my personal experience, there are a lot of developers who know how to build database-driven apps, but they're not experts on database design and that creates a lot of problems that could otherwise be avoided.


Couldn't agree more.

almost 7 years ago


Ian T

We use both. NoSQL is great for looking through a lot of reasonably static information very, very quickly (which is why all search engines have been doing this for donkeys years) and anything with scale needs to do this. They're not so hot for transactional databases where data flows both ways (customer databases etc etc) and is frequently updated. Horses for courses. 

almost 7 years ago

Save or Cancel

Enjoying this article?

Get more just like this, delivered to your inbox.

Keep up to date with the latest analysis, inspiration and learning from the Econsultancy blog with our free Daily Pulse newsletter. Each weekday, you ll receive a hand-picked digest of the latest and greatest articles, as well as snippets of new market data, best practice guides and trends research.