1

My client has an existing PostgreSQL database with around 100 tables and most every table has one or more relationships to other tables. He's got around a thousand customers who use an app that hits that database.

Recently he hired a new frontend web developer, and that person is trying to tell him that we should throw out the PostgreSQL database and replace it with a MongoDB solution. That seems odd to me, but I don't have experience with MongoDB.

Is there any clear reasons why he should, or should not, make the change? Obviously I'm arguing against it and the other guy for it, but I would like to remove the "I like this one better" from the argument and really hear from the community on their experience with such things.

Improve this question
7
  • Does that other guy give actual reasons, why he thinks mongo will work better there? Commented Jun 29, 2017 at 19:32
  • The only specific I heard was him showing one line of code to create something vs. a SQL table. I wasn't privvy to the discussion. Commented Jun 29, 2017 at 19:34
  • 4
    Show then thisL: create table mycollection(id bigserial primary key, data jsonb); Commented Jun 29, 2017 at 20:07
  • 2
    The other guy will end up writing five nested loops to join six tables, conclude that he needs a hash/cache to buffer intermediate results, and he will invent his own in-memory application catalogs to choose the right kind of loops, then he will concude that he needs more hardware. Commented Jun 29, 2017 at 20:10
  • 1
    @wildplasser - No, the other guy don't care about data model, he is frontend web developer Commented Jun 29, 2017 at 20:23

2 Answers 2

Reset to default
4

1) Performance

During last years, there were several benchmarks comparing Postgres and Mongo.

Here you can find the most recent performance benchmark (Yahoo): https://www.slideshare.net/profyclub_ru/postgres-vs-mongo-postgres-professional (start with slide #58, where some overview of the past becnhmarks is given).

Notice, that traditionally, MongoDB provided benchmarks, where they didn't turn on write ahead logging or even turned fsync off, so their benchmarks were unfair -- in such states the database system doesn't wait for filesystem, so TPS are high but probability to lose data is also very high.

2) Flexibility – JSON

Postgres has non-structured and semistructured data types since 2003 (hstore, XML, array data types). And now has very strong JSON support with indexing (jsonb data type), you can create partial indexes, functional indexes, index only part of JSON documents, index whole documents in different manners (you can tweek index to reduce it's size and speed).

More interestingly, with Postgres, you can combine relational approach and non-relational JSON data – see this talk again https://www.slideshare.net/profyclub_ru/postgres-vs-mongo-postgres-professional for details. This gives you a lot of flexibility and power (I wouldn't keep money-related or basic accounts-related data in JSON format).

3) Standards and costs of support

SQL experiences new born now -- NoSQL products started to add SQL dialects, there is a lot of people making big data analysis with SQL, you can even run machine learning algorithms inside RDBMS (see MADlib project http://madlib.incubator.apache.org).

When you need to work with data, SQL was, is and will be for long time the best language – there are such many things included to it, so all other languages are lagging too much. I recommend http://modern-sql.com/ to learn modern SQL features and https://use-the-index-luke.com (from the same author) to learn how reach the best performance using SQL.

When Mongo needed to create "BI connector", they also needed to speak SQL, so guess what they chose? https://www.linkedin.com/pulse/mongodb-32-now-powered-postgresql-john-de-goes

SQL will go nowhere, it's extended with SQL/JSON now and this means that for future, Postgres is an excellent choice.

4) Scalability

If you data size is up to several terabytes -- it's easy to live on "single master - multiple replicas" architectuyre either on your own installation or in clouds (Amazon RDS, Heroku, Google Cloud Platform, and since recently, Azure – all them support Postgres). There is an increasing number of solutions which help you to work with microservice architecture, have automatic failover, and/or shard your data. Here is only few of them, which are actively developed and supported, without specific order:

5) Extensibility

There are much more additional projects built to work with Postgres than with Mongo. You can work with literally any data type (including but not limited to time ranges, geospatial data, JSON, XML, arrays), have index support for it, ACID and manipulate with it using standard SQL. You can develop your own functions, data types, operators, index structures and much more!

Improve this answer
Sign up to request clarification or add additional context in comments.

Comments

2

If your data is relational (and it appears that it is), it makes no sense whatsoever to use a non-relational db (like mongodb). You can't underestimate the power and expressiveness of standard SQL queries.

On top of that, postgres has full ACID. And it can handle free-form JSON reasonably well, if that is that guy's primary motivation.

Improve this answer

1 Comment

@Nick: yeah, love that video. I used to be a light version of that guy :)

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.