In
fact, for over 30 years or so, the Database Wars have been settled, the
relational databases have won the fight, and the decision left was which
relational database to use. Everyone “knows” that NoSQL is something
that Google invented to handle the amount of data and users they have,
and that is it somehow related to scaling to Google or Facebook levels.

And
since most of us aren’t working on applications that have millions of
users, we get to keep using the tried and true methods, no need to
bother with something that is only relevant at extreme high scale. The
relational database has served us well, and can continue serving us in
the future. Learning SQL was a very smart investment, after all.

Let
us go back a bit to those Database Wars that I mentioned. In the 70s
there were actually quite a lot of different types of databases
competing with each other, anything from ISAM to DBase to relational
databases. And as you can see, the relational database has won such a
decisive victory that it rules undisputed for over a generation.

But
one thing that we have to remember is that those Database Wars were
fought on a drastically different ground than the one we have today.

1980 vs. 2012

In 1980, a 10 MB hard disk (that is in megabytes,
about 2 songs or 3 pictures) cost around 4,000 $ US. Adjusting for
inflation, that comes at about 11,000 $ US in today’s dollars. Just to
compare, today a 10 MB of disk space would cost you about half a dollar.
And those aren’t the only changes, of course. Computation speed, memory
sizes and networks are all many orders of magnitude faster and cheaper
than they were in the 80s.

Even more interesting is the
differences in the type of applications being built. In the 80s, a
typical application had exactly one user. Multi users’ applications had
to support… 3 users. All of them at the same time! The UI paradigms were
drastically different, as well. At the time, the master – details form
was the top of the hill, the uncontested king of good UI design. But
today… there are usually so many items and active elements on a single
web page today as there were in entire applications then.

Why the
history lesson, you ask? Why, to give you some perspective on the
design choices that led to the victory of the relational databases.
Space was at a premium, the interaction between the user and the
application closely modeled the physical layout of the data in the
database. That made sense, because there really were no other alternatives given the environment that existed at the time.

That
environment is no longer here, and the tradeoffs made when 30 MB would
cost as much as an annual salary are no longer relevant. In particular,
one immensely annoying aspect of relational database is very much a
problem today. Relational databases trade off read speed in favor of
write speed. Because it made perfect sense to make this trade off when
disk space was so costly, and making users wait an extra second was no
big deal.

In separate studies conducted by both Google and
Amazon, they found that even additional 100ms added to the latency of a
page severely impacted their bottom line. And yet relational database
tradeoff read speed (having to do joins and extra loads) for write speed
(having to write small amount of data).

Another problem that
pops up frequently with relational database is their inability to handle
complex data types, such as collections or nested objects. Oh, you can
certainly map that to a relational database, but that requires
additional tables, and each additional table is going to make it that
much more complex to query the data, work with it and display it to the
user.

For many years, I have been working with customers on
optimizing their applications using relational databases, and I’ve seen
the same problems occur over and over again. That led me to the belief
that the NoSQL databases aren’t suitable just for extremely scalable
scenarios. NoSQL databases make sense for a wide range of options, and
this realization led me to RavenDB.

In my company, we are using
RavenDB as the backend database for everything from a blog, our ordering
and purchasing systems, the daily build server and many more.

The
major advantages that we found weren’t the ability to scale (although
that exists), it is the freedom that it gives us in terms of modeling
our data and changing our minds.