Does anyone have a better name handy to call “NoSQL” ?


Today marks my one month anniversary at MongoDB – time just flew by , and I am having a great time . If there is one frustration with my new gig – it is the term “NoSQL”. This term provides nothing but grief . Does anyone have a better name handy ?

To begin with , SQL is not going anywhere . There are some use cases – like the complex transactions in an ERP system – where SQL is an excellent fit . So the idea of NoSQL is more of “not JUST SQL”. The term is like the grand daddy of all nuances.

If we think of all possible things that need a database in it , I think about 20% or so might always need SQL . And another 20% will always need one of the solutions loosely classified as NoSQL . The true issue is – what about the rest of the 60% ?

In general – depending on the skills of a project team, these 60% can be done in either SQL or NoSQL with different trade offs . When I joined MongoDB, I rationalized in my mind that vast majority of that middle 60% would lean towards NoSQL . You can take your own percentage of course depending on your world view :)

Now within this NoSQL space , there is plenty of variety too . MongoDB for example is what is called a document database – given the JSON/BSON nature of holding the data. You wouldn’t believe how many times I have been asked whether MongoDB is a solution for storing documents like word and PDF files ! Of course MongoDB can store all kinds of files – pictures too – and it is great for content management applications . But that is just one of say 10 categories of use cases this database can do .

And once I explain the JSON document story – the invariable follow up question is “oh what is the big deal there – doesn’t your competitor do it too?” . Yes there are other solutions out there that can use JSON – there are ones built on XML too . However, the nuance that gets missed is that everyone handles it differently . Some just store it as a BLOB associated with a key , unlike how MongoDB handles it .

So clearly – the “document database” term is not exactly helpful either . A combination of just plain misunderstanding , and some marketing misadventures have made sure that neither NoSQL nor document databases clarify exactly how these various databases differ .

The JSON discussion with anyone who has written a SQL query once in their life usually results in the gotcha moment “oh – so you can’t do Joins in your cool new technology . You do know we can’t live without it right?”. It’s a simple yes or no question in the mind of the person – and they know the right answer . I am now researching history now to find what Henry Ford must have answered to people who asked him ” so what kind of horse whip goes with this car thingy that you are selling?” :)

Then I have attempted to explain MongoDB using the Gartner 3V model – which a lot of people already relate to due to the big data hype . So I say things along the lines of “Variety” is the key V that differentiates MongoDB . That doesn’t always cut it – I am tempted to use another V – for “Versalitily”, to point out the differentiating features . But here as a matter of principle – and out of respect for Doug Laney and Gartner – I won’t hijack the original 3V model . Just like I don’t like the original 4Ps of marketing mix being changed . Those models are all fine – we just need to resist the urge to change them for our random interests .

By the way – Is Hadoop considered NoSQL ? Yes ? No? Yes?

I don’t know really. It’s a personal taste thing I guess . There are plenty of initiatives in and around Hadoop to make it more SQL friendly . I can’t really say where one could draw a line .

There are plenty of people who have asked me if MongoDB is another NoSQL system like Hadoop . It always makes me stop in my tracks . How exactly should I answer that ?

To begin with – I don’t know whether Hadoop should be in NoSQL category . Then there is the fact that MongoDB has complimentary features to Hadoop – and is not competitive to Hadoop (despite having some similarities like MapReduce and an aggregation framework). So I can say yes or no and make it sound credible – or I can smile, or I can roll my eyes , or do a combination of all of these things . I also tend to remember the joke about a lawyer asking an accused “Do you still beat your wife every night?” . Yes ? No? Yes?

It’s no big deal really – but if anyone has any bright ideas on a new name to replace NoSQL , please share . You will have my eternal gratitude and I will buy you a pitcher of beer when we meet . Please , please . Pretty please ?

About these ads

14 thoughts on “Does anyone have a better name handy to call “NoSQL” ?

      • Our data storage needs are very “polyglot” – there are very few if any products that meet our requirements today. I need a SQL-like store, a JSON/BLOB store, a document store with full text search, and a hyperscalable store for time series and event data. And it needs to support high availability, elastic scaling, multiple DC’s, a high performance Java driver, be very affordable, and needs to run on premise and in the cloud. Not too much to ask, is it? ;-)

      • Polyglot is how everything will turn out to be in due course – you are ahead of the pack though :)

        Just curious – what part of SQL is driving your requirement ? ACID ?

  1. A few ideas:
    NJSQL – Not Just SQL
    MTSQL – More Than SQL
    UnSQL – Unstructured Query Language
    AKSSRCP – All Kinds of Stuff Storage Retrieval Communication Protocol

  2. ansql – add ons on sql,
    Vlsci – very large scale collaboration for integration,
    dfsql – diet free sql,
    vasasql – vast anxiety state for an alternate sql

  3. Let’s start from the premise SQL = structured query language.

    SQL is really addressing the interaction between the coder/application and the DBMS. It is not a term to describe the kind/type of DB. In the case of Mongo we mostly interact with the database using API like statements or functions so my SQL equivalent term would lean toward something like statement or function based interactions, I think the Mongo documentation calls it ad hoc query language.

    As a term to describe MongoDB or at least the Mongo engine I would focus on replacing the letter R in R-DBMS (R for relational). Word/PDF connotation aside, the term document or document-based DBMS is accurate. Maybe JSON/BSON DBMS is a good alternate.

    What is Mongo?

    A JSON/BSON DBMS accessible via ad hoc/function based interactions or queries.

    Probably doesn’t merit a free beer but that’s my 2 cents :)

  4. Vijay, my comment regarding desiring some SQL-like capabilities refers to the ability to deal with (and enforce) a schema on a dataset, the ability to provide high performance querying on any number of indices, and on server-side processing of where clauses. Server-side joins and relational capabilities fall only in the “nice to have” category but not “must have” for us.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s