mongoDB is a relatively new database management system, one of the prime examples of the No-SQL database movement (if such a thing exists). In No-SQL databases, that can also be referred to as ‘non-relational databases’, you don’t represent data tables that store rows and their relations. Each No-SQL database has its own particular way of modelling, storing and representing data.

This NoSQL movement is basically promoting the shift of development and logic on database querying and processing out of the database systems (and SQL language) and into the developer and programming world. I think programmers never liked the SQL language, or never had the time or patience to understand its declarative nature (a declarative language is one where you express a computational logic and not so much a program flow). There were many attempts to lower the impedance mismatch between those world over the years: object-oriented databases, ORMs (object-relational mappers) and even LINQ in the .NET world and their equivalents in some other languages and platforms like Java. I think NoSQL is just another attempt on that, but more specific: their objective is targeted specifically to manage huge amounts of data (popularly known as “Big Data“). Summarizing, where in a relational database you would use SQL to pull data out of the database, in the NoSQL world you would use your system’s programming language.

In the case of mongoDB, data is stored in form of “documents” which are basically JSON strings, some sort of object serialization. If you are a JavaScript or web developer, you are in good luck today, because you are very familiar with JSON, and the way it represents information. If not, you will have a slight learning curve, but nothing to steep to be honest.

Another interesting characteristic on mongoDB is schema management: in a relational database, you first model a table, where you specify the types of data you will be able to store (columns) and their data types. In mongoDB there is no such thing, every data item you store is just a serialization and it can be completely different from any other stored in the same collection.

I’ve been working with mongoDB for the last couple of months, in an experimental way, but now I’m starting to work on it for a project full time.
I had the chance to compare it (more philosophically) with other database systems I worked with, and I’ve come to like it to some extent, although still leaves me with some doubts and wishes in several aspects.

The good

Here are some of the things I really like about mongoDB:

– Free and open source: This model works well for small projects, but you will find costs as you grow. You will want a more robust infrastructure, and mongoDB requires more hardware than other database systems in order to be fault tolerant. Also, you will want some kind of support from mongoDB, and you will have to pay for it. Also, open source means you can take a look at the source code, but mongoDB (the company) still owns the product and the project’s destiny. This means you can start small with free, and then keep growing as you need more.

– Scalable almost to infinity: this is not to say that you will need that, but is more scalable than traditional relational database systems. With the SQL Servers and Oracles of the world, if you want to scale, you would buy a bigger server (more RAM, more HDD, more processing power): this is called scaling vertically. You can see there is a limit to how big your server can be, right? With mongoDB, you will get more inexpensive hardware and add them to a cluster that behaves as just one big server to the application layer: this is called scaling horizontally. There is virtually no limit to how many servers you can add to a cluster.

– Simple JSON API: This is what makes it so popular. Everybody and their mothers who know who to program in JS can now use a very simple API to access a database.

– Very good documentation: All the information you can need is available at mongodb.org. If you need some hand holding, they even provide online courses at education.mongodb.com

The bad, and the ugly

Things I really don’t like about it:

– Not so great in the enterprise environment: mongoDB (the company) is clearly putting all their efforts to push this into the Enterprise landscape, with different degrees of success. I’ve seen some really awesome use cases (like implementations of Customer 360 view apps created in incredible record times) but also some very awful implementations.

– JSON: Yeap, I think this is their blessing and curse. The fact that everybody can simply use this makes it very easy for anybody with absolutely no understanding of database modelling or theory, to make things a mess in record time.

– DBA tooling is poor: And this is something that has been improved over time. As mongoDB relies heavily on their community to create management / monitoring / optimization tools, there is not a clear path or toolset that one can use to work or even develop. Sometimes, too many options can be a problem.

All in all, I would still recommend for you to take a look on it, just to get a glimpse on what the non-relational database world looks like. It is always good to broaden ones horizons.