Ask HN: Is MongoDB obsolote when Postgres and SQLite provide JSON types?
16 comments
Building complex queries in MongoDB is a huge pain in the ass (aka aggregations). For all the same operations you need to figure out how to do, it's significantly easier to do in Postgres. This is especially if you involve MongoDB subdocuments in your query.
Subdocuments in MongoDB are a footgun where I've seen it go wrong most of the time (as in the consequence is more complicated querying syntax is required) that having that data as a subdocument should have been in a collection instead.
The API for transactions in the Node.js drivers has around two variants of how transactions should work, and require very specific conditions to work correctly (for example, you can only create indices in a transaction if the collection is empty), and it's hard to find documentation on a working transactional sample.
I would never recommend MongoDB to anyone, and if one wanted to, then use Postgres with JSON types.
Subdocuments in MongoDB are a footgun where I've seen it go wrong most of the time (as in the consequence is more complicated querying syntax is required) that having that data as a subdocument should have been in a collection instead.
The API for transactions in the Node.js drivers has around two variants of how transactions should work, and require very specific conditions to work correctly (for example, you can only create indices in a transaction if the collection is empty), and it's hard to find documentation on a working transactional sample.
I would never recommend MongoDB to anyone, and if one wanted to, then use Postgres with JSON types.
Isn't the whole fuss around document based DBs all around good speed and less integrity, and most RDS more about integrity?
Things like storing logs -> document DB.
Ecommerce schema with carts, orders, payments, addresses, products, etc -> RDS
?
Things like storing logs -> document DB.
Ecommerce schema with carts, orders, payments, addresses, products, etc -> RDS
?
I understand that JSON supporting SQL databases struggle to index and search through JSON. I've had a much better time querying JSON objects from Mongo than Postgres.
I guess it depends what you're doing? My girlfriend works as a data engineer and as far as I understand it's used in that field as a first layer to pipe a bunch of different raw data sources into before analyzing and/or moving it over to a more structured database like Postgres.
As a user of both and others (we have legacy couchdb applications for instance), I agree with some others here; Postgres is not handy for querying. Maybe some extension will be made for that in the future, but for now I see them for different use cases.
I don't think so, I tried to mimic mongodb using sqlite, some operators can be difficult to do, for example $in
When you need high write throughput and you don't care about transactions, basically.
To compare them, would you please elaborate on the technical side regarding the write throughput?
Mongodb has a sales team. The stock values the company at a 25 billion dollar market cap. Sales will make it so your company may end up using it whether you think it’s obsolete or not.
Yes. There hasn't been a good reason to choose MongoDB for years now.
There are better NoSQL DBs than Mongo, but most people are better off with a hybrid like Postgres.
There are better NoSQL DBs than Mongo, but most people are better off with a hybrid like Postgres.
Dare to explain further?
Too lazy, but it's luckily one of HN's favorite topics. Read comments on any of these articles. They will be more thorough and technical than I am capable of being.
https://hn.algolia.com/?dateRange=all&page=0&prefix=true&que...
https://hn.algolia.com/?dateRange=all&page=0&prefix=true&que...
[deleted]
My background here is just a user of both, nothing too deep or profound. I guess I've also got a few nights on a project to make a mongodb compliant API for postgres jsonb in python.
Obsolete feels like a strong term. for a problem thats truly document oriented workloads mongodb still seems more efficient, if not in literal performance then in scope and understandability. the mongodb API is the defacto "standard" API for document dbs as far as I can tell, and realistically SQL is a notable barrier for application devs. Also, operationally, mongodb is easier to run, between Atlas and having more clustering capabilities available for "easy". Those two things mean you _can_ move faster than with postgres (with the same relative amount of knowledge)
That said, for the aforementioned side project, a few nights got me the basic pieces of the API in place (next big step is the aggregation pipeline, which id argue is intermediate for mongodb and much less used), so it's not hard to adapt a codebase to pg/jsonb. And imo there aren't that many hardcore document only problems at the small or even medium size. And once you're at medium to large, the mongodb pain of transactions as a second class citizen, lack of data integrity options, schema fluidity, and overall less strict structuring makes Pg much more appealing. Pg/jsonb is powerful, and if you have someone willing to be a db admin postgres is extremely powerful.
So, mongodb maybe not Obsolete (it's popularity would attest otherwise if nothing else), but id take a better option if I were able. But if I needed a FE or mid-tier application dev to magically be an infra person, mongodb starts looking good again.
Obsolete feels like a strong term. for a problem thats truly document oriented workloads mongodb still seems more efficient, if not in literal performance then in scope and understandability. the mongodb API is the defacto "standard" API for document dbs as far as I can tell, and realistically SQL is a notable barrier for application devs. Also, operationally, mongodb is easier to run, between Atlas and having more clustering capabilities available for "easy". Those two things mean you _can_ move faster than with postgres (with the same relative amount of knowledge)
That said, for the aforementioned side project, a few nights got me the basic pieces of the API in place (next big step is the aggregation pipeline, which id argue is intermediate for mongodb and much less used), so it's not hard to adapt a codebase to pg/jsonb. And imo there aren't that many hardcore document only problems at the small or even medium size. And once you're at medium to large, the mongodb pain of transactions as a second class citizen, lack of data integrity options, schema fluidity, and overall less strict structuring makes Pg much more appealing. Pg/jsonb is powerful, and if you have someone willing to be a db admin postgres is extremely powerful.
So, mongodb maybe not Obsolete (it's popularity would attest otherwise if nothing else), but id take a better option if I were able. But if I needed a FE or mid-tier application dev to magically be an infra person, mongodb starts looking good again.
Have used both. Depends how you use them.
If you use jsonb of postgres to just dump things you don't query on, it's fine. If you try to cheat and dump your mongo schema into a jsonb field, you're gonna have a bad time.
JSON queries in postgres are, IMO, extremely nonobvious. It seems like any time we wanted to run some rather simple report that involved json fields, some poor dev had to spend ten or more minutes figuring out the correct syntax to do so. Mongo is an absolute breeze in comparison.
Person opinion? JSON doesn't belong in the db, make a proper schema. If you don't want to do that, or don't like or want to learn SQL, just use Mongo or some equivalent.
If you use jsonb of postgres to just dump things you don't query on, it's fine. If you try to cheat and dump your mongo schema into a jsonb field, you're gonna have a bad time.
JSON queries in postgres are, IMO, extremely nonobvious. It seems like any time we wanted to run some rather simple report that involved json fields, some poor dev had to spend ten or more minutes figuring out the correct syntax to do so. Mongo is an absolute breeze in comparison.
Person opinion? JSON doesn't belong in the db, make a proper schema. If you don't want to do that, or don't like or want to learn SQL, just use Mongo or some equivalent.
Most recent pg releases use the -> operator to access json fields now, in case you didn’t know about this syntax improvement.
Yeah, thanks. It's mostly all the built in functions and converting you have to do to pull the data back out I was referring to. It's not impossible, but the result always looks like something that makes you not feel bad for having looked it up (because who would remember that).
TBH, about half the time, I cheat and cast the whole thing to text and just do a string search on the blob.
TBH, about half the time, I cheat and cast the whole thing to text and just do a string search on the blob.
Just a side note: If you don't need to query your json, you can use a text field instead of jsonb.
True, but the json types should at least verify it's valid json, which may be useful.
good point.
MongoDB is distributed, PostGreSQL and SQlite are not.
However you have tools to use PostGreSQL and SQLite in a distributed way, like Citus or DQlite.
Do you want or need a distributed database ? If not, you can safely ignore MongoDB and similar databases. Non distributed databases are much simpler to administrate and use.
However you have tools to use PostGreSQL and SQLite in a distributed way, like Citus or DQlite.
Do you want or need a distributed database ? If not, you can safely ignore MongoDB and similar databases. Non distributed databases are much simpler to administrate and use.
Good point. MongoDB scales horizontally (add more servers) PostgreSQL scales vertically (get a bigger server) which is the least desirable way to scale, in addition to be being reliant on fewer servers makes it less fault tolerant. MongoDB is also schema-less which is convenient for developers and makes change management easier , but the cost is your app has an undocumented and unrestricted data model that only your core devs can partially explain, and your business analysts absolutely hate anything that isn’t standard SQL. So the story with MongoDB is core app devs still love it, operations is OK with it, and for everyone else you better copy that biz data into something that speaks standard SQL or the analysts will riot.
Still an excellent comparison https://youtu.be/b2F-DItXtZs
> MongoDB is distributed, PostGreSQL and SQlite are not.
YugabyteDB is distributed and Postgres 11.2 compatible. AFAIK it will be 13.x compatible soon.
YugabyteDB is distributed and Postgres 11.2 compatible. AFAIK it will be 13.x compatible soon.
An older comment of mine but not much has changed: https://news.ycombinator.com/item?id=23271085
I may be talking out of my ass here, but the key decider is your ability to maintain the conceptual integrity of your data architecture. Mongo makes it easy to maintain document based data architecture, Postgres does not. But maybe you don't really need a document based data architecture, you just think you do and it's mainly not document based, only a little bit. Or maybe it's just too damn hard to maintain your concepts in a SQL database. Maintaining conceptual data architecture is hard and sometimes too hard.
It has been a long while, but I once used a master MongoDB node to store samples from a twitter stream, then used a couple of read replicas for analytics. Probably better ways to do that now.
Sorry for being off topic, but I used to be very enthusiastic about CouchDB and Big Couch.
Probably best to use the best tool for the job, but for many years I got in the habit of using Postgres for almost everything, and now I use SQLite for most of my personal projects.
Sorry for being off topic, but I used to be very enthusiastic about CouchDB and Big Couch.
Probably best to use the best tool for the job, but for many years I got in the habit of using Postgres for almost everything, and now I use SQLite for most of my personal projects.
Could someone with the knowledge elaborate on the topic, please?