<img height="1" width="1" style="display:none" src="https://www.facebook.com/tr?id=752538731515435&amp;ev=PageView&amp;noscript=1">


Ford. vs. Chevy

Coke vs. Pepsi

Edison vs. Tesla

Wisconsin vs. Minnesota

Our world is full of time-honored rivalries that spur endless conversations, Facebook posts, and merchandise sales.

Just a Database?

Your choice of a SQL or NoSQL database for your project probably won't put your Facebook feed in an uproar. Then again, based on some of the blog comments I found while researching this article maybe it will.

So why all the fuss and bother? It's just a database, right?

To people who really care about database technology that's like saying "it's just a game" or "it's just a car".


Either/Or...or Both/And?

A good rivalry requires two opponents that are equally worthy but feature different strengths.

This is certainly the case with SQL vs. NoSQL.

Then again, is it?

As the products evolve it may not make sense to talk about them as an either/or for much longer.

Like teams trading players, like Chevy engines getting swapped into Fords, SQL and NoSQL products are blurring the lines of distinction by each offering features from the other camp.

But let's keep the rivalary going for just a bit longer - at least to get a sense of how the two approaches think about data, data storage, and data retrieval.


The main defining point of SQL databases is in the name itself - SQL stands for Structured Query Language.



Rows and columns.

Cells of discreet data.

SQL database designers are highly focused on creating a well-defined, highly-thought-out structure for data to go into. The database structure is often created early on in the project. Changes to it become harder as the database grows in size.

The goal is "normalized" data - so one piece of data is stored in one place and one place only. Updates are more efficient as they are only made in that one place.

Relationships between tables of data are tightly defined. If you are tracking customers and orders, they would be in separate tables with a relationship created between them. A query can retrieve all orders for a specific customer.

The database can even enforce the data model - so no orders can be entered without customers. Or all phone numbers must have 10 numbers. Or every new project has a Project Manager assigned.

SQL databases are great when your data is well structured and that structure is known in advance. SQL databases typically scale well vertically - so you increase performance by adding more power to the server or server cluster the database is hosted on.

But - what if your data isn't that well structured? What if it's structured in different ways?

NoSQL Databases

Unstructured data.

While that phrase is itself enough to strike fear in the hearts of many SQL database developers, unstructured data does exist in the real world.

Examples include:

  • Documents
  • Presentations
  • Audio
  • Images
  • Videos
  • Content from social media sites
  • Customer reviews
  • Call center conversations

NoSQL databases are nonrelational and document based. One way to think about a NoSQL document is a blog post with tags, categories, photos and video, and user comments. In a SQL database you'd seperate those elements out into their own database tables and use a query to bring them all back together.

In a NoSQL database they would all be stored in a single document. If one blog post (document) needed an additional element (such as a downloadable PDF) you could add one field to that one document. The entire database wouldn't have to be updated.

NoSQL Benefits

Does your project have data requirements that are intially unclear?

Do you need extremely high performance in getting results back from queries?

Does your project have the potential need for rapid scaling (like, you just created the next PokeMon Go)?

If you've answered any of these questions "yes" then a NoSQL database may be for you.


Here at Omni we've recently begun specializing in the MarkLogic product. MarkLogic is a highly scalable and certified secure NoSQL database. It also comprises a search engine and application server with audit trails, flexible deployment, and ACID-compliant transactions.

We're pretty tickled with it so far, and would love a chance to talk further about how it might fill your project requirements.

We'll even provide a can of your favorite cola.

Herb Lichtenberg

About Author Herb Lichtenberg

Herb Lichtenberg is a former Director of Business Development at Omni. He has over 30 years of experience in the technology industry with a focus on understanding business needs, application development and partner channel management.


Omni’s blog is intended for informational purposes only. Any views or opinions expressed on this site belong to the authors, and do not represent those held by people or organizations with which Omni is affiliated, unless explicitly stated.

Although we try to the best of our ability to make sure the content of this blog is original, accurate and up-to-date, we make no claims of complete accuracy or completeness of the information on this site/s to which we link. Omni is not liable for any unintended errors or omissions, or for any losses, injuries, or damages from the display or use of this information. We encourage readers to conduct additional research before making decisions based on the information in this blog.