The Database Battle: MongoDB vs MySQL

The either-or debate when it comes to NoSQL and rational databases is far from settled.

When it comes to web start-ups, NoSQL databases are pretty much the base technology and the majority of these companies choose MongoDB, CouchDB, etc. to meet their database requirements. Still, going the hybrid route might serve them better. One can always find space for a decent, old-fashioned relational database, especially when it comes to conducting and stashing financial transactions.

Thrillist, is a media company that is based in New York that fields e-commerce and client recommendation services, use MongoDB when it comes to monitoring and storing info about user interactions but NoSQL takes over when it comes to the day to day mundane info that allows the company to operate.

Thrillist’s Mark O’Neill  believes that there is good reasoning behind that. MongoDB and its ilk are fantastic, they are babies when compared to the more established SQL programs that went before. The ancillary utilities are not as healthy and it is difficult to locate NoSQL talent.

There is a lack of skills development when it comes to NoSQL and, as languages go, SQL is pretty easy to learn – SQL queries are relatively simple to write. When it comes to NoSQL, O’Neill had said that there were much higher barriers to entry.

When Thrillist was established in 2005, a number of NoSQL alternatives were considered but MongoDB won out over these because, at that stage, it was less volatile, had a bigger support community and it had the best tools.

Don’t misunderstand – MongoDB is excellent at handling all the essential social interactions that occur. For each action a user performs, one may also track what the friends of the user were up to and be able to get all that data in one area. Say, for example, a user updates Meetup. It will, in turn clue the friends in to what that user is doing. Non-relational stores are great at accomplishing that and there is no need to keep all that info in one place. That is where Mongo comes in.

When it comes to actual transactions though, Mongo does not really have that function. If data is recorded in multiple locations and one wants to check it all at once, Mongo is unable to collate it. Let’s say you order something from Thrillist’s JackThreads site, the order must be recorder and every process relating to the order needs to be associated with it or it falls apart. One either records everything or nothing. Mongo is not the ideal system for that.