Need advice about which tool to choose?Ask the StackShare community!
MongoDB vs PostgreSQL: What are the differences?
Introduction
MongoDB and PostgreSQL are both popular database management systems, but they have several key differences that set them apart. In this article, we will explore six major differences between MongoDB and PostgreSQL.
Data Model: MongoDB is a document-oriented database, while PostgreSQL is a relational database. MongoDB stores data in flexible, JSON-like documents, allowing for dynamic and schema-less data structures. On the other hand, PostgreSQL uses tables, rows, and columns to store structured data with predefined schemas. This means that MongoDB can easily handle unstructured data, while PostgreSQL enforces the structure of the data.
Scalability: MongoDB is designed to scale horizontally, making it suitable for handling large amounts of data and high traffic loads. It achieves scalability by sharding, which involves distributing data across multiple servers. PostgreSQL, on the other hand, is primarily designed to scale vertically by adding more resources to a single server. While PostgreSQL can handle substantial workloads, it may face limitations when it comes to scaling horizontally.
Query Language: MongoDB uses a flexible and expressive query language called MongoDB Query Language (MQL). MQL uses a JSON-like syntax and supports powerful querying capabilities like complex nested queries and indexing. PostgreSQL uses structured query language (SQL), a declarative language with a well-defined syntax. SQL is widely adopted and understood, making it easier for developers who are familiar with relational databases.
Transactions: PostgreSQL supports ACID-compliant transactions, which guarantee the consistency and reliability of data. This means that multiple operations within a transaction are treated as a single unit, ensuring that either all changes are committed or none are. MongoDB, on the other hand, historically did not support transactions across multiple documents in a single operation until the release of MongoDB 4.0. While it now supports multi-document transactions, its transactional capabilities are still not as robust as PostgreSQL.
Schema Enforcement: As a schema-less database, MongoDB does not enforce a specific structure on the data it stores. This flexibility allows for a more agile development process, as schema changes can be easily adapted. PostgreSQL, being a relational database, enforces strong schemas, ensuring that the data follows a predefined structure. This can be beneficial for data integrity and consistency, especially in applications where maintaining a strict schema is crucial.
Performance: Due to its flexible and scalable architecture, MongoDB can provide high-performance capabilities when handling large-scale data and high levels of concurrency. Its ability to distribute data across multiple servers can lead to improved read and write performance. PostgreSQL, with its well-established reputation, provides excellent performance for complex queries involving structured data. It excels in handling complex join operations and offers advanced indexing options, making it a preferred choice for analytical workloads.
In summary, MongoDB and PostgreSQL differ in their data models, scalability approaches, query languages, transactional capabilities, schema enforcement, and performance characteristics. Understanding these differences is essential when choosing a database management system that best suits your application's requirements.
Hello everyone. We have a project that it's like a candidate tracking system. It has candidates, projects, assessments, etc. A consultant senior developer started it by using MongoDB. The thing is that he designed the database like it's a relational DB.
Personally, I didn't imagine that it was a good thing to do. Because you won't have the power of SQL functionalities like join
, on delete
, and more. You have to be very careful, I think things may go unmaintainable very fast. I asked him about this and he said "I don't see a problem doing it like this."
What are your thoughts on this? Did you see examples like this? Should I avoid it or go for it? Any advice is appreciated.
Here is what it looks like in Moon Modeler: https://imgur.com/a/RNwNBNY
It happened to me that you actually construct a relational schema with MongoDB. It is not good. You do not use the modeling benefits of MongoDB, and you do not have the benefits of SQL. So I recommend taking it into MySQL. Since you think in a relational way, it is best you move to MySQL
Specifically, do you need non-normalized data? If not, MySQL is best. Otherwise, MongoDB is best. If you think non-relational, you do not need joins, and the problems with cascade disappear.
What is the best way to think? If you work in terms of whole tree of related object, then you think non-relational and non-normalized.
It makes no sense if you use MongoDB primarily as a relational database. As you scale MongoDB will be more expensive than SQL and as you said without having the advantages of "join" etc.
We use MongoDB in our company. It is useful for us, as we work with different types of devices and we love the functionality of being able to add fields whenever we have a new device type etc. Mongo also allows enables easy scaling and fault tolerance. However, you will have to learn how to manage it.
If you are already comfortable with SQL and don't need NoSQL, stick to SQL. At scale, it is cheaper than Mongo.
I have been using Firebase with almost all my web projects as well as SwiftUI projects. I use it for the database as well as the user authentication via Google.
Is it good enough?? I have learned MySQL but I'm not that comfortable…
So for user authentication and database should I keep using firebase or switch to MySQL or MongoDB?? Or any other combination?
Hi!
I’m not an expert, but I can tell you some things:
- Firebase is a great option for a very simple to implement, fast and reliable authentication method. Nonetheless, the free authentications are limited, so if you will potentially have millions of monthly authentications, it’s probably best to take the time to build it into your app directly.
- MySQL is great for simple tables where the data structures are not too complex, but it lacks some speed when you are trying to retrieve time data series. Also, I believe it’s a bit more difficult to distribute.
- MongoDB is great when your information is a bit more complex and you need very peculiar data structures, nested data, dynamic structures, etc. For me at least, it’s a bit more complex to master than MySQL, but the freedom it gives you is incredible. It also performs super fast, especially with time data series, and if I’m not wrong, it’s more scalable.
In general, almost all technologies have their good things, it’s just a matter of what you want to do and then choosing the right ones.
Look if you are comfortable with firebase you can go with it, after all, It's all about development and running your program bug-free and fast, but firebase is costly fo long run and if you are comfortable with that cost then I suggest you go with it.
Doing User authentication (oauth) and session management by ourself is kind a challenging, so if possible use firebase itself since it provides these features out of the box.
I'm starting to work on a Jira-like bug tracker web app. This is a hobby project that is mostly a way for me to learn about different technologies and development processes(CI/CD, etc..) so I could be more ready when I start applying for programming jobs.
I'm debating between MySQL, which I'm less familiar with, and MongoDB which I have used in the past.
My two points of consideration are the following:
1) Which one is more likely to be relevant for web dev jobs? While I want to learn new technologies, I prefer learning ones that will make me more hireable in the future.
2) Which one is more flexible when it comes to changing the shape of the stored data? I expect to need to make some changes as the project goes on.
Thanks, everyone!
MySQL is still more popular than MongoDB if you look at Google Trends. I've also added MariaDB, which is pretty much a copy from MySQL and its features, and PostgreSQL, which is also a popular relational database.
This is a very good article for comparing MySQL to MongoDB and which one you should use: MongoDB vs MySQL: A Comparative Study on Databases.
If you just want to learn and you have the time, I would opt for using both MySQL and MongoDB. For example using MySQL for most of the site content and MongoDB for saving log messages. As you get more and more logs you start to see the benefits from MongoDB's faster document fetching.
There's really not an awful lot of difference between the two, they have wildly different storage mechanisms but they each have their fairly similar benefits. If you want to learn something that might be a requisite skill for a job, I would also look at alternatives such as time based and column based systems like InfluxDB and the unbelievably fast and flexible ClickHouse. While they may seem like an unlikely fit for a personal bug tracker app, there's no reason not to use them. Since I got into InfluxDB people have been requesting it a lot and I'll be using ClickHouse for all large databases, probably forever. Expand your horizons beyond your competition's.
I’m doing a school project where I have to design a database for a password manager app like 1Password, bitwarden… I’m not sure which database paradigms I should use. Users would have the ability to create vaults and each vault will have many items and can be sorted into favorite, category, tag list… Please help.
What I have learned through several years of experience, is that by default you should consider SQL database (like PostgreSQL, MySQL, ...) and if does not suit you then you should explore other noSQL options.
SQL is very solid and it can do almost anything and can support almost any kind of systems.
So, for your case I would recommend that you go with SQL. You should start by listing your use cases and infer from them your entities and relations, and work on them in a Top-to-bottom manner, meaning that you should have some entities that are the core dependencies for the other entities. Or, in other words, they can exist without other entities existing, but the opposite is not true, these are your core entities that you should work on first, then gradually build the other entities.
One way to figure out the core entities is to follow how the users will behave in your system, what will the user create first, and what is dependant on other entities.
For example, in your case, on way to do it is to start with the "vault", as everything else cannot exist without it (and it's the first thing a user would create), then do passwords as they depend on the vaults (I would say passwords are "under" the vault), then once you do them, you can start working on tags then categories, and so on...
I have a project (in production) that a part of it is generating HTML from JSON object normally we use Microsoft SQL Server only as our main database. but when it comes to this part some team members suggest working with a NoSQL database as we are going to handle JSON data for both retrieval and querying. others replied that will add complexity and we will lose SQL Servers' Unit Of Work which will break the Atomic behavior, and they suggest to continue working with SQL Server since it supports working with JSON. If you have practical experience using JSON with SQL Server, kindly share your feedback.
I agree with the advice you have been given to stick with SQL Server. If you are on the latest SQL Server version you can query inside the JSON field. You should set up a test database with a JSON field and try some queries. Once you understand it and can demonstrate it, show it to the other developers that are suggesting MongoDB. Once they see it working with their own eyes they may drop their position of Mongo over SQL. I would only seriously consider MongoDB if there was no other SQL requirements. I wouldn't do both. I'd be all SQL or all Mongo.
I think the key thing to look for is what kind of queries you're expecting to do on that JSON and how stable that data is going to be. (And if you actually need to store the data as JSON; it's generally pretty inexpensive to generate a JSON object)
MongoDB gets rid of the relational aspect of data in favor of data being very fluid in structure.
So if your JSON is going to vary a lot/is unpredictable/will change over time and you need to run queries efficiently like 'records where the field x exists and its value is higher than 3', that's a great use case for MongoDB.
It's hard to solve this in a standard relational model: Indexing on a single column that has wildly different values is pretty much impossible to do efficiently; and pulling out the data in its own columns is hard because it's hard to predict how many columns you'd have or what their datatypes would be. If this sounds like your predicament, 100% go for MongoDB.
If this is always going to be more or less the same JSON and the fields are going to be predictably the same, then the fact that it's JSON doesn't particularly matter much. Your indexes are going to approach it similar to a long string.
If the queried fields are very predictable, you should probably consider storing the fields as separate columns to have better querying capabilities. Ie if you have {"x":1, "y":2}, {"x":5, "y":6}, {"x":9, "y":0} - just make a table with an x and y column and generate the JSON. The CPU hit is worth it compared to the querying capabilities.
Hello All, I'm building an app that will enable users to create documents using ckeditor or TinyMCE editor. The data is then stored in a database and retrieved to display to the user, these docs can contain image data also. The number of pages generated for a single document can go up to 1000. Therefore by design, each page is stored in a separate JSON. I'm wondering which database is the right one to choose between ArangoDB and PostgreSQL. Your thoughts, advice please. Thanks, Kashyap
Which Graph DB features are you planning to use?
Hey everyone, My users love Microsoft Excel, and so do I. I've been making tools for them in the form of workbooks for years, these tools usually have databases included in the spreadsheets or communicate to free APIs around the web, but now I want to distribute these tools in the form of Excel Add-ins for several reasons.
I want these Add-ins to communicate to a personal server to authorize users, read from my databases, and write to them while they're using their Excel environment. I have never built a website, so what would be a good solution for this, considering I'm new to all of these technologies? I know about the existence of Microsoft Azure, Microsoft SharePoint, and Google Sheets, but I don't know how to feel about those.
Just definitely don't use firebase. All of MongoDB, MySQL, MariaDB and PostGreSQL have a lot of community support and history.
Snowflake is a NoSQL database in the cloud, which also accepts SQL calls. Users can obtain an ODBC driver for SnowFlake, which would allow your Excel apps to write/read from the backend, locally.
I am building a fintech startup with a friend, we decided to use Go for its performance and friendly syntax. We want to know if we should use a web framework or just use the pure net/http lib and also for the databases we put PostgreSQL and MySQL on the table, we want to know which one is better, from the community support to the best open-source implementation?
Postgres is a better option to consider compared to MySQL. With respect to performance, postgres has an edge over MySQL. Don't use net/http for production. Read this https://medium.com/@nate510/don-t-use-go-s-default-http-client-4804cb19f779 I prefer gorilla/mux as it is simple and provides all the basic features. Other lib seems to be an overhead if you just need basic routing.
MySQL and Postgre both are great and awesome and great support, community, support. Whatever will be good. Postgree have some little advantages.
I recommend Elixir, even though I work in a fintech with Go, Elixir is a FP language so in my opinion the immutability is a important topic when working with money.
Hey, we want to build a referral campaign mechanism that will probably contain millions of records within the next few years. We want fast read access based on IDs or some indexes, and isolation is crucial as some listeners will try to update the same document at the same time. What's your suggestion between Couchbase and MongoDB? Thanks!
I am biased (work for Scylla) but it sounds like a KV/wide column would be better in this use case. Document/schema free/lite DBs data stores are easier to get up and running on but are not as scalable (generally) as NoSQL flavors that require a more rigid data model like ScyllaDB. If your data volumes are going to be 10s of TB and transactions per sec 10s of 1000s (or more), look at Scylla. We have something called lightweight transactions (LWT) that can get you consistency.
I have found MongoDB highly consistent and highly available. It suits your needs. We usually trade off partion tolerance fot this. Having said that, I am little biased in recommendation as I haven't had much experience with couchbase on production.
I'm planning to build a freelance marketplace website, using tools like Next.js, Firebase Authentication, Node.js, but I need to know which type of database is suitable with performance and powerful features. I'm trying to figure out what the best stack is for this project. If anyone has advice please, I’d love to hear more details. Thanks.
Postgres and MySQL are very similar, but Mongo has differences in terms of storage type and the CAP theorem. For your requirement, I prefer Postgres (or MySQL) over MongoDB. Mongo gives you no schema which is not always good. on the other hand, it is more common in NodeJS community, so you may find more articles about Node-Mongo stuff. I suggest to stay with RDBMS if possible.
This is a little about experience. Postgresql is fine. You can use either the related table structure or the json table structure.
We have a ready-made engine for the online exchange and marketplace. To customize it, you only need to know sql. Connecting any database is not a problem. https://falconspace.site/list/solutions
Fauna is a serverless database where you store data as JSON. Also, you have build in a HTTP GraphQL interface with a full authentication & authorization layer. That means you can skip your Backend and call it directly from the Frontend. With the power, that you can write data transformation function within Fauna with her own language called FQL, we're getting a blazing fast application.
Also, Fauna takes care about scaling and backups (All data are sharded on three different locations on the globe). That means we can fully focus on writing business logic and don't have to worry anymore about infrastructure.
As an advanced user, I prefer Postgres over MySQL. MySQL was the first database I learned from my institute. I always have to undergo that infamous date and time dilemma many Java devs know. Both are adequate for a small project. When I worked on a project with a date and time-intensive data, I spent a lot of time dealing with the conversion and transition, leaving me frustrated. I tried Postgres to see how well it can perform. To my surprise, all became a breeze, and the transactions were faster too. I've been using Postgres ever since, and no more dilemma.
I’m newbie I was developing a pouchdb and couchdb app cause if the sync. Lots of learning very little code available. I dropped the project cause it consumed my life. Yeats later I’m back into it. I researched other db and came across rethinkdb and mongo for the subscription features. With socketio I should be able to create and similar sync feature. Attempted to use mongo. I attempted to use rethink. Rethink for the win. Super clear l. I had it running in minutes on my local machine and I believe it’s supposed to scale easy. Mongo wasn’t as easy and there free online db is so slow what’s the point. Very easy to find mongo code examples and use rethink code in its place. I wish I went this route years ago. All that corporate google Amazon crap get bent. The reason they have so much power in the world is cause you guys are giving it to them.
We started using PostgreSQL because there's no need to upgrade to an enterprise plan to access certain essential features. Postgres is essentially plug-and-play; you download it, install it, and there you go!
Another benefit of using Postgres is that you get to use SQL (Structured Query Language)—which isn't for everyone, but I enjoy how flexible and versatile it is.
Postgres also has point-in-time recovery, which you can export wherever you want—This means you can restore data from any given point in time. With this in mind, if you delete something accidentally, you can go back in time and grab said data without restoring the whole database.
Not to mention Postgres is remarkably fast with several thorough benchmarks comparing it to MongoDB, where Postgres mostly came out on top.
As a startup, managing my own database, backups and even the schemas/migrations are all overhead. Next to that, I needed both Backend and Frontend ways to write to the database. With firebase this is possible, this saved us some time: Some API calls were not needed because I could directly fetch data in the FE.
Offline support & realtime data updates is also supported out of the box. No need to write your own websockets.
Once the startup grows, moving to a different relational database might make sense. But in a pre-product-market-fit startup, Firebase is a good, and cheaper fit!
The pricing model of firebase firestore is a bit risky. But it saves a lot of time to get quickly to market.
We will be getting data in the form of CSVs. Because the data in a CSV is highly structured, it will be easy to create schemas and it works well in a SQL database as opposed to noSQL. For a SQL database, both mySQL and Postgres are very viable options. Both of them are highly performant, definitely enough for our application, even if we needed to scale drastically. Postgres does include some extra features over mySQL such as table inheritance and function overloading. However, the extra features are not advantageous to us given our database use case. Because both databases seemed to suit our use case perfectly, we chose to use mySQL simply because it is more familiar tech within our team.
One of our biggest technical pillars is to "let the pros manage it", thus we settled on using Heroku PostgreSQL
to manage our SQL cluster. We can take advantage of the free tier and the requests will be fast since it is integrated into Heroku. PostgreSQL
also support Full text search which can come into handy with manually searching through the tables.
All the benefits of relational joins and constraints, with JSON field types in Postgres to allow for flexibility like mongo. Objection ORM makes query building seamless and abstracts away a lot of complexity of SQL queries.
MongoDB tends to get slow with scale and requires a lot of code to maintain consistency across collections as foreign keys and other constraints are harder to implement. PostgreSQL also has a vibrant community with battle tested stability and horizontal scalability when needed.
I was looking into PostgreSQL for a database option solely for the reason that it was popular, had good community support, and was used by many companies planning to develop social media platforms similar to Calosmic.
However, I was very unfamiliar with relational databases and had only gotten acquainted with the basics of column-family database models with technologies like SqlLite3.
Furthermore, I had already been using MongoDB, a document-based database, in a previous project so I was looking for options similar to the aforementioned technology.
Last but not least, I wasn't all too into having to manage my database; I wanted to have a place to store my data, and be able to effectively query, and mutate the data without the hassle of learning SQL or maintaining an entire database. I found out about FaunaDB a couple of weeks ago and was very excited about the native GraphQL support, a combination of both document-based and relational database models, and the low-maintenance structure of the database. I am currently experimenting with using FaunaDB in my stack :)
- One disadvantage I noticed while using FaunaDB and GraphQL is the lack of certain features that one expects when using the latter. Even though FaunaDB has native support for GraphQL it seems as if it's missing numerous features that are commonplace in the language such as unions and interfaces.
MongoDB's document-oriented paradigm is nicely suited to the results of our ML model. We felt that this compatibility offered some time savings on figuring out and implementing an extensive data formatting and processing system. MongoDB's flexible schemas schemas (due to it being non-relational) were also attractive as a source of additional agility for our development process. The MongoDB ecosystem also has great GUI tools to simplify testing.
Pros of MongoDB
- Document-oriented storage828
- No sql593
- Ease of use553
- Fast464
- High performance410
- Free255
- Open source218
- Flexible180
- Replication & high availability145
- Easy to maintain112
- Querying42
- Easy scalability39
- Auto-sharding38
- High availability37
- Map/reduce31
- Document database27
- Easy setup25
- Full index support25
- Reliable16
- Fast in-place updates15
- Agile programming, flexible, fast14
- No database migrations12
- Easy integration with Node.Js8
- Enterprise8
- Enterprise Support6
- Great NoSQL DB5
- Support for many languages through different drivers4
- Schemaless3
- Aggregation Framework3
- Drivers support is good3
- Fast2
- Managed service2
- Easy to Scale2
- Awesome2
- Consistent2
- Good GUI1
- Acid Compliant1
Pros of PostgreSQL
- Relational database764
- High availability510
- Enterprise class database439
- Sql383
- Sql + nosql304
- Great community173
- Easy to setup147
- Heroku131
- Secure by default130
- Postgis113
- Supports Key-Value50
- Great JSON support48
- Cross platform34
- Extensible33
- Replication28
- Triggers26
- Multiversion concurrency control23
- Rollback23
- Open source21
- Heroku Add-on18
- Stable, Simple and Good Performance17
- Powerful15
- Lets be serious, what other SQL DB would you go for?13
- Good documentation11
- Scalable9
- Free8
- Reliable8
- Intelligent optimizer8
- Transactional DDL7
- Modern7
- One stop solution for all things sql no matter the os6
- Relational database with MVCC5
- Faster Development5
- Full-Text Search4
- Developer friendly4
- Excellent source code3
- Free version3
- Great DB for Transactional system or Application3
- Relational datanbase3
- search3
- Open-source3
- Text2
- Full-text2
- Can handle up to petabytes worth of size1
- Composability1
- Multiple procedural languages supported1
- Native0
Sign up to add or upvote prosMake informed product decisions
Cons of MongoDB
- Very slowly for connected models that require joins6
- Not acid compliant3
- Proprietary query language2
Cons of PostgreSQL
- Table/index bloatings10