Blog Post

To SQL or to NoSQL: the database dilemma

Peter Van Hardenberg Heroku Postgres Dave Rubin Oracle Cliff Moon Boundary Barry Morris NUODB Structure 2012
(L to R) Peter van Hardenberg – Co-Founder, Heroku Postgres, Heroku; Dave Rubin – Director of NoSQL Database Development, Oracle; Cliff Moon – CTO, Boundary; Barry Morris – CEO, NUODB
(c) 2012 Pinar Ozger

Everybody likes a good technology debate: Mac vs. PC, Android vs. iOS, Larry Ellison vs. the world. On Thursday panelists at GigaOM Structure turned their attention to the world of databases: SQL or NoSQL?

The question revolves around the decision whether or not to embrace SQL databases — the traditional approach — or NoSQL databases favored by those embracing the cloud. Different companies require different approaches depending on their needs, but at least one panelist wasn’t shy about sharing his views.

“SQL is terrible,” said Cliff Moon, CTO of Boundary. “It’s really bad.” Moon’s company makes application monitoring tools across the network, rather than across servers or storage devices, which means he’s naturally interested in a more flexible database model.

But flexibility doesn’t necessarily make for stability. “Would I want my checking account to run on Mongo?” wondered Dave Rubin, director of NoSQL database development at Oracle. “I can tell you for sure that the answer is no.”

Barry Morris, CEO of NUODB, wants to split the difference. His company is working on products that “maintain full relational database capabilities, but with very large scalable databases.” That allows for compatibility with older SQL-based applications but in a more flexible package.

It’s a key decision that application developers have to make when launching a product, said Peter Van Handerburg, co-founder of Heroku Postgres. “The care and feeding of a database is a full-time job, sometimes many full-time jobs,” he said. “When data gets very big, it starts to crumble.”

Check out the rest of our Structure 2012 coverage here.

Watch live streaming video from gigaomstructure at

9 Responses to “To SQL or to NoSQL: the database dilemma”

  1. Please check out Bangdb ( the new key value store which seems to be very fast in terms of IOPS for both read and write. The Bangdb will be in many flavors for ex; embedded, network, elastic cache/imdg. Being crash proof, with many configuration parameters, it can be tuned to operate in most suitable fashion for a given requirement.

  2. Bradford S.

    One doesn’t have to sacrifice SQL to get scalability. But you do have to change a lot of how it works under the hood.

    Indexing, joins, storage…everything has to be rebuilt from the ground up, and a lot of assumptions have to change.

    At Drawn to Scale, we’ve built a real-time SQL database on top of Hadoop and HBase. Customers are using it now, even in beta — so there’s a definite need for SQL out there still.

  3. Steve Larrison

    There’s 30 seconds of my life I’ll never get back.

    I’m very disappointed by this “article”. Normally articles on Gigaom demonstrate some level of understanding of the technologies that are behind the article. But this was just 3 quotes from people at different companies surrounded by a small pile of fluff.

    Instead of simply saying “SQL is terrible” and leaving it at that, why not offer some context about problems of structured and unstructured data?

    Instead of misidentifying the problem of using Mongo for a bank account as one of stability, how about correctly understanding issues like ACID compliance versus eventual consistency?

    As for NUODB, instead of just quoting the aspirational goal of the CEO of the company, how about a little insight into how their product is attempting to explain the architectural approach and how it will help NUODB meet those aspirations?

    As a practitioner in the field, I understand how hot big data and analytics are. And while it makes sense for Gigaom to write articles that will draw traffic, putting fluff out like this will only make the traffic you have go elsewhere.

    • ReallyOK

      I strongly agree with this comment. I have really valued the content on GigaOm over competing sites because it has always seemed to convey a deeper sense of technical understanding and cut through the fluff.

      I have noticed that much of the reporting coming out of the Structure conference is along the same lines as this article. Flimsy context setting, panelist quote, conflicting panelist quote, erroneous assertion about the technology, closing statement along the lines of, “This sure is a big problem.”

  4. Dave Gill

    These debates seem a little irrelevant really. You pick the tools for the job not the other way round surely? Admittedly if the only tool you have is an Hammer then every problem is a Nail but the tech used should be defined by the problem you are trying to solve.

  5. Pork Belt

    Keep deleting my comments. I’ll keep confirming your content-free recap.

    I mean, you’re the one who started this article off with: “Everybody likes a good technology debate”

    • Tom Krazit

      I deleted your first comment because of the language. It’s good to know that people who refer to themselves as “Pork Belt” have such high standards.