5 ms·

Ask HN: Is MongoDB obsolote when Postgres and SQLite provide JSON types?

• smt88 5y ago
  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.
  • ewuhic 5y ago
    Dare to explain further?
    • smt88 5y ago
      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&query=Mongo&sort=byPopularity&type=story https://hn.algolia.com/?dateRange=all&page=0&prefix=true&que...
• deleted 5y ago
  [deleted]
• ungawatkt 5y ago
  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.
• silisili 5y ago
  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.
  • patrickthebold 5y ago
    Just a side note: If you don't need to query your json, you can use a text field instead of jsonb.
    • silisili 5y ago
      True, but the json types should at least verify it's valid json, which may be useful.
      • patrickthebold 5y ago
        good point.
  • plasma 5y ago
    Most recent pg releases use the -> operator to access json fields now, in case you didn’t know about this syntax improvement.
    • silisili 5y ago
      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.
• ranguna 5y ago
  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 ?
  • sylens 5y ago
    I would say most e-commerce sites with lots of concurrent users look more for key-value stores today, like a DynamoDB
    • ranguna 5y ago
      It's a shame you can't do a simple query to look for entries whose creation date is between two dates in dynamoDB.
• speedgoose 5y ago
  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.
  • snorkel 5y ago
    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.
  • rad_gruchalski 5y ago
    > MongoDB is distributed, PostGreSQL and SQlite are not. YugabyteDB is distributed and Postgres 11.2 compatible. AFAIK it will be 13.x compatible soon.
  • canterburry 5y ago
    Still an excellent comparison https://youtu.be/b2F-DItXtZs https://youtu.be/b2F-DItXtZs
• frankjr 5y ago
  An older comment of mine but not much has changed: https://news.ycombinator.com/item?id=23271085 https://news.ycombinator.com/item?id=23271085
• flarg 5y ago
  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.
• mark_l_watson 5y ago
  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.
• crate_barre 5y ago
  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.
• dyeje 5y ago
  When you need high write throughput and you don't care about transactions, basically.
  • shahinghasemi 5y ago
    To compare them, would you please elaborate on the technical side regarding the write throughput?
• danhab99 5y ago
  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.
• tluyben2 5y ago
  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.
• theogravity 5y ago
  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.
• jamil7 5y ago
  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.
• billconan 5y ago
  I don't think so, I tried to mimic mongodb using sqlite, some operators can be difficult to do, for example $in