4 ms·

The post should probably be titled "Why you should not pick a technology based on hype and without evaluating it first". While MongoDB has (and probably still h

The post should probably be titled "Why you should not pick a technology based on hype and without evaluating it first". While MongoDB has (and probably still has) some flaws and is not the perfect DB system, there are valid use cases where it can be a good choice. Building a social networking site that requires rich queries along a relationship graph is most definitely not one of them.

enraged_camel 10y ago
The HN consensus seems to be that MongoDB is good only for toy projects, and that you should switch to a real database as soon as things start getting more complex.
- rch 10y ago
  Actually, when you have a toy project that needs a RDBMS, go ahead and use SQLite. The consensus is that relatively few applications are a good fit for MongoDB, irrespective of scale.
  - tensor 10y ago
    And for those few where you think MongoDB might be a good fit, you should probably use something like RethinkDB instead.
  - honkhonkpants 10y ago
    Or leveldb for those even more trivial storage needs.
    - deleted 10y ago
      [deleted]
  - 3pt14159 10y ago
    Why? Now I have to learn a crappier version of SQL (no support for real date types, no user management, etc) and heaven help me if my toy project actual gets traction. I'll have to migrate everything over to Postgres or I'll have to keep my DB on a single server because it's just a single file. Compared to just using Postgres or even MySQL I do not understand the benefit. It takes less than an hour to spin up a PG database with user permissions and migrations to make tables and indexes.
    - rch 10y ago
      SQLite provides date and time functions for working with e.g. ISO8601 strings, but I understand where you're coming from. https://www.sqlite.org/lang_datefunc.html https://www.sqlite.org/lang_datefunc.html https://www.sqlite.org/datatype3.html#section_2_2 https://www.sqlite.org/datatype3.html#section_2_2
  - alexchantavy 10y ago
    What's an example of an application that is a good fit for MongoDB?
    - kolme 10y ago
      I actually don't have any experience, but I heard this from wise people: If you have a file store service, where you're storing relatively big files (big images, videos, etc) and some metadata associated to them which need to be queried. It's easier to implement than "traditional" solutions (metadata goes in a RDBMS and actual files go to some directory, NAS, or whatever). Also, apart from being a nicer solution from a programmer's perspective, you'll be able to easily scale horizontally because it supports sharding. Like I said, I didn't tried this myself so take it with a grain of salt. Also, I don't know how that compares to storing blobs in a RDBMS.
      - KMag 10y ago
        > Also, apart from being a nicer solution from a programmer's perspective, you'll be able to easily scale horizontally because it supports sharding. Sharding file storage is pretty easy. On the other hand, I'm not familiar with the MongoDB APIs, but I assume it doesn't support handing a socket file descriptor from the webserver over to MongoDB so Mongo can sendfile(2) the data directly from the kernel's page cache to the TCP socket for locally resident data. With the files stored directly on disk and metadata in an RDBMS, your webserver can sendfile(2) those files that are permanently stored locally or cached to local disk, and act as a proxy for other shards. Extra context switches and coping your data one or two times more than necessary can add up quickly.
    - breischl 10y ago
      If you have a fairly complex object structure that is logically a single unit, and you only need/want to query on a small number keys. Or anytime you might think "It would be better to just serialize this and shove it into a VARCHAR column." eg, the rate structure for a vacation rental. The fancier ones (not AirBnB) can have lots of different seasons, stay durations, various upcharges/discounts, etc. It's difficult to model in SQL, and even if you could it's not usually useful. Dealing with the entire thing as a single document just makes more sense. Another example: if you need to handle data that your app doesn't really own. eg, you're going to read it, maybe wrap it up with some other data, and pass it on. In that case being able to handle and store that data as a mostly-opaque blob is handy. Of course that's an argument for a document DB in general, not Mongo in particular. Dynamo, Rethink, etc might be better choices.
- pbreit 10y ago
  I think the consensus is closer to: use Postgres unless you have a very good reason to use something else. SQLite good for dev and toys.

enraged_camel 10y ago

The HN consensus seems to be that MongoDB is good only for toy projects, and that you should switch to a real database as soon as things start getting more complex.

rch 10y ago
Actually, when you have a toy project that needs a RDBMS, go ahead and use SQLite. The consensus is that relatively few applications are a good fit for MongoDB, irrespective of scale.
- tensor 10y ago
  And for those few where you think MongoDB might be a good fit, you should probably use something like RethinkDB instead.
- honkhonkpants 10y ago
  Or leveldb for those even more trivial storage needs.
  - deleted 10y ago
    [deleted]
- 3pt14159 10y ago
  Why? Now I have to learn a crappier version of SQL (no support for real date types, no user management, etc) and heaven help me if my toy project actual gets traction. I'll have to migrate everything over to Postgres or I'll have to keep my DB on a single server because it's just a single file. Compared to just using Postgres or even MySQL I do not understand the benefit. It takes less than an hour to spin up a PG database with user permissions and migrations to make tables and indexes.
  - rch 10y ago
    SQLite provides date and time functions for working with e.g. ISO8601 strings, but I understand where you're coming from. https://www.sqlite.org/lang_datefunc.html https://www.sqlite.org/lang_datefunc.html https://www.sqlite.org/datatype3.html#section_2_2 https://www.sqlite.org/datatype3.html#section_2_2
- alexchantavy 10y ago
  What's an example of an application that is a good fit for MongoDB?
  - kolme 10y ago
    I actually don't have any experience, but I heard this from wise people: If you have a file store service, where you're storing relatively big files (big images, videos, etc) and some metadata associated to them which need to be queried. It's easier to implement than "traditional" solutions (metadata goes in a RDBMS and actual files go to some directory, NAS, or whatever). Also, apart from being a nicer solution from a programmer's perspective, you'll be able to easily scale horizontally because it supports sharding. Like I said, I didn't tried this myself so take it with a grain of salt. Also, I don't know how that compares to storing blobs in a RDBMS.
    - KMag 10y ago
      > Also, apart from being a nicer solution from a programmer's perspective, you'll be able to easily scale horizontally because it supports sharding. Sharding file storage is pretty easy. On the other hand, I'm not familiar with the MongoDB APIs, but I assume it doesn't support handing a socket file descriptor from the webserver over to MongoDB so Mongo can sendfile(2) the data directly from the kernel's page cache to the TCP socket for locally resident data. With the files stored directly on disk and metadata in an RDBMS, your webserver can sendfile(2) those files that are permanently stored locally or cached to local disk, and act as a proxy for other shards. Extra context switches and coping your data one or two times more than necessary can add up quickly.
  - breischl 10y ago
    If you have a fairly complex object structure that is logically a single unit, and you only need/want to query on a small number keys. Or anytime you might think "It would be better to just serialize this and shove it into a VARCHAR column." eg, the rate structure for a vacation rental. The fancier ones (not AirBnB) can have lots of different seasons, stay durations, various upcharges/discounts, etc. It's difficult to model in SQL, and even if you could it's not usually useful. Dealing with the entire thing as a single document just makes more sense. Another example: if you need to handle data that your app doesn't really own. eg, you're going to read it, maybe wrap it up with some other data, and pass it on. In that case being able to handle and store that data as a mostly-opaque blob is handy. Of course that's an argument for a document DB in general, not Mongo in particular. Dynamo, Rethink, etc might be better choices.
pbreit 10y ago
I think the consensus is closer to: use Postgres unless you have a very good reason to use something else. SQLite good for dev and toys.