Choosing a Database: MongoDB Vs PostgreSQL

Ask a programmer whether you should use MongoDB vs PostgreSQL and you’re likely to open a can of worms. The core philosophies are very different, but loyal fans will argue that their favorite can be used for nearly every application. It is true that there’s a lot of functional overlap between the two databases. However, MongoDB and PostgreSQL have some specific differences that give them the edge in different areas.


is a document database, meaning data is stored in cohesive documents that contain all the data about a particular topic. There doesn’t need to be a consistent relationship between the data. Because of this, MongoDB is an excellent choice for Big Data projects and social media applications dealing with large amounts of unstructured data (in short, anything that wouldn’t fit neatly into a table, like a blog post or a video). Use MongoDB for:


is an object-relational DBMS where data is stored in correlative tables. Although it’s a solid general use database, the focus on defining the relationships between data and enforcing standards makes it a popular choice for those who prioritize data integrity. Even MongoDB’s website credits PostgreSQL with being superior at “complex, multi-row transactions”. Use PostgreSQL for:

The Choice is Yours

It’s important to remember that no project exists in a vacuum; there are dozens of factors that may influence technology choice. A good software developer chooses the best tool for each situation, regardless of whether the project is a typical use case.

For example, you might expect that a tax and customs authority like the UK’s HM Revenue and Customs would use PostgreSQL. Tracking taxes seems to call for the rigid data integrity of an RDMS. There are over 65 million taxable subjects in the UK, however. HMRC badly needed the rapid development possible with MongoDB to get its tax planning and payment tools into the hands of the citizens as soon as possible. Using MongoDB, they were able to move from a glacial two releases per year to putting out 50 releases every week. The result was a


A final word of caution: avoid choosing a DBMS based on outside factors like trends. It is neither easy nor cheap to switch later on if you don’t like how your database is performing. Data migration can cost 25-50% of original set-up costs (not including the potential risk of lost data) and take years to finish. Being open to recommendations from your software developer will save you the expense.

Unsure which database is right for your next app?

Let the experts at Concepta help you decide!

Related Articles

A Faster Way Forward Starts Here