4 ms·

MongoDB is a pretty good database IMO. I've used it at several companies in the past and wouldn't mind using it again. My favorite DB is RethinkDB. It's a sham

MongoDB is a pretty good database IMO. I've used it at several companies in the past and wouldn't mind using it again. My favorite DB is RethinkDB. It's a shame that the company behind it fizzled out and was absorbed by Stripe. I still cannot wrap my mind around why it's not more popular. It's similar to MongoDB but much better. It's the perfect database. It adds constraints which improve the quality of your code. Also RethinkDB scales very well and the control panel that comes with it is mind-bendingly powerful, I'm not kidding; you can click a button to shard or replicate a table over multiple hosts! WTF! I can't say the same about Postgres unfortunately. There is nothing truly remarkable about it. I use Postgres for one of my projects today but purely because of compatibility reasons with an existing system. I don't understand what all the hype is with Postgres.

qatanah 6y ago
back when mongo was around 2.6x, they had a global write lock. Also, you'll encounter more problems with mongodb if in case you need transaction. You should check out more discussion here on db systems. http://www.redbook.io/ http://www.redbook.io/
- threeseed 6y ago
  MongoDB 2.6 was released 7 years ago. Why are you bringing it up ? If you use MongoDB today then (a) there is no global write lock and (b) there are transactions.
- jondubois 6y ago
  IMO I've come to see DB transactions as a hack because they limit scalability. It's possible to use two-phase commits instead. Two-phase commits can scale without limit but you have to be more careful when designing your tables and specifying your indexes. For tables which need atomicity, you can add a 'state' column/field which is either 'pending' or 'settled'. You can have a separate parallel subroutine (or process) in your code to handle settlement. You have to design it in such a way that if the system fails at any point, it will re-process all 'pending' entries in an idempotent way. It's a bit more work, but it scales without limit. You can add a shard key (or use account IDs) so that you can have multiple processes/hosts working in parallel to insert pending transactions and also multiple processes to settle them in parallel. In financial transactions, I would separate it into two parts: A debit entry and a credit entry which are initially inserted into the DB as 'pending'. The settlement routine will match them up together - Making sure to process/settle the debit side of the transaction first and only once the debit is in the settled state, it will process/settle the credit side. If the settlement engine sees any conflict (e.g. user tries to spend more money than they have by submitting many transactions in parallel), it will accept all the transactions as 'pending' but mark the later ones as canceled (they will not settle) so the credit entry will never be created on the other account.
  - qatanah 6y ago
    Exactly it's a bit more of work does make you prone to mistakes. This is what happens when you rewrite transaction on your application. See what happens with to a btc exchange using mongo who got hacked. https://dzone.com/articles/mongodb-bitcoin-how-nosql https://dzone.com/articles/mongodb-bitcoin-how-nosql (article is 2014) I'm a bit outdated with mongo since 2.4-2.6 . It's a bit traumatic and i'm never coming back to it. If in case I'll need a high atomicity and consistency for financial transaction i'll just use postgres with SERIALIZABLE transaction isolation. This solves everything. Checkout the redbook.io it's a bit outdated but you can see from stonebreaker's discussion that nosql + sql will merge, which is what happening or happened right now. Mongo having transaction, and SQL having json datatypes.
Beefin 6y ago
much of the anti-mongo sentiment is around people who used it in 2009-ish. it's useful to point out that when using the early version of any software, there will be bugs. that's a trade-off early adopters always need to contend with. unfortunately, it hasn't sat well over time despite every one of the concerns being addressed since.
- doublesCs 6y ago
  > much of the anti-mongo sentiment is around people who used it in 2009-ish. So? I think this is a very plausible way of measuring how much you should trust something. There had to be a downside to the "move fast and break things" that mongodb subscribes to (i.e., add features now, think about reliability later). As it turns out, they moved fast and broke their reputation.
  - Beefin 6y ago
    i agree, there's reputational impact but again it's the trade off that early adopters make and are fully aware of. When you're the first user of a brand new companies' database, you better bet there will still be kinks they're working through and let's face it you're the guinea pig. i'm sure mongo is thankful for all these guinea pigs because they helped to define the roadmap and iron out the bugs. however, in the end of the day 2009 version of a product is entirely different than 2020 version. there are endless analogies (facebook, google, etc.) the only difference with an open source technology is users can analyze it under a microscope.
  - scarface74 6y ago
    You make technical decisions based on what happened a decade ago? Do you make all decisions based on ten year old information?
    - doublesCs 6y ago
      Depends on what. You seem to think this is about tech. It's not. It's about company culture, trust, and reputation. Code can change reasonably fast, in some cases 10 years is enough to replace an entire codebase. But company culture has or can have an expected life time way longer than 10 years. In this case, my heuristic is justified.
heipei 6y ago
So what's the status of RethinkDB? Is it still being developed? Who's working on it? Is it stable and feature-complete or are there any kinds of features missing that only a dedicated (paid) team would be able to pull off? Genuinely curious!
blondin 6y ago
long time postgres user. the hype about postgres is that there is no hype. it's one of those systems that have been working for decades. they have their flaws but they are well known and as long as you aware of them it does exactly what it is supposed to do.

qatanah 6y ago

back when mongo was around 2.6x, they had a global write lock. Also, you'll encounter more problems with mongodb if in case you need transaction. You should check out more discussion here on db systems. http://www.redbook.io/ http://www.redbook.io/

threeseed 6y ago
MongoDB 2.6 was released 7 years ago. Why are you bringing it up ? If you use MongoDB today then (a) there is no global write lock and (b) there are transactions.
jondubois 6y ago
IMO I've come to see DB transactions as a hack because they limit scalability. It's possible to use two-phase commits instead. Two-phase commits can scale without limit but you have to be more careful when designing your tables and specifying your indexes. For tables which need atomicity, you can add a 'state' column/field which is either 'pending' or 'settled'. You can have a separate parallel subroutine (or process) in your code to handle settlement. You have to design it in such a way that if the system fails at any point, it will re-process all 'pending' entries in an idempotent way. It's a bit more work, but it scales without limit. You can add a shard key (or use account IDs) so that you can have multiple processes/hosts working in parallel to insert pending transactions and also multiple processes to settle them in parallel. In financial transactions, I would separate it into two parts: A debit entry and a credit entry which are initially inserted into the DB as 'pending'. The settlement routine will match them up together - Making sure to process/settle the debit side of the transaction first and only once the debit is in the settled state, it will process/settle the credit side. If the settlement engine sees any conflict (e.g. user tries to spend more money than they have by submitting many transactions in parallel), it will accept all the transactions as 'pending' but mark the later ones as canceled (they will not settle) so the credit entry will never be created on the other account.
- qatanah 6y ago
  Exactly it's a bit more of work does make you prone to mistakes. This is what happens when you rewrite transaction on your application. See what happens with to a btc exchange using mongo who got hacked. https://dzone.com/articles/mongodb-bitcoin-how-nosql https://dzone.com/articles/mongodb-bitcoin-how-nosql (article is 2014) I'm a bit outdated with mongo since 2.4-2.6 . It's a bit traumatic and i'm never coming back to it. If in case I'll need a high atomicity and consistency for financial transaction i'll just use postgres with SERIALIZABLE transaction isolation. This solves everything. Checkout the redbook.io it's a bit outdated but you can see from stonebreaker's discussion that nosql + sql will merge, which is what happening or happened right now. Mongo having transaction, and SQL having json datatypes.

Beefin 6y ago

much of the anti-mongo sentiment is around people who used it in 2009-ish. it's useful to point out that when using the early version of any software, there will be bugs. that's a trade-off early adopters always need to contend with. unfortunately, it hasn't sat well over time despite every one of the concerns being addressed since.

doublesCs 6y ago
> much of the anti-mongo sentiment is around people who used it in 2009-ish. So? I think this is a very plausible way of measuring how much you should trust something. There had to be a downside to the "move fast and break things" that mongodb subscribes to (i.e., add features now, think about reliability later). As it turns out, they moved fast and broke their reputation.
- Beefin 6y ago
  i agree, there's reputational impact but again it's the trade off that early adopters make and are fully aware of. When you're the first user of a brand new companies' database, you better bet there will still be kinks they're working through and let's face it you're the guinea pig. i'm sure mongo is thankful for all these guinea pigs because they helped to define the roadmap and iron out the bugs. however, in the end of the day 2009 version of a product is entirely different than 2020 version. there are endless analogies (facebook, google, etc.) the only difference with an open source technology is users can analyze it under a microscope.
- scarface74 6y ago
  You make technical decisions based on what happened a decade ago? Do you make all decisions based on ten year old information?
  - doublesCs 6y ago
    Depends on what. You seem to think this is about tech. It's not. It's about company culture, trust, and reputation. Code can change reasonably fast, in some cases 10 years is enough to replace an entire codebase. But company culture has or can have an expected life time way longer than 10 years. In this case, my heuristic is justified.

heipei 6y ago

So what's the status of RethinkDB? Is it still being developed? Who's working on it? Is it stable and feature-complete or are there any kinds of features missing that only a dedicated (paid) team would be able to pull off? Genuinely curious!

blondin 6y ago

long time postgres user. the hype about postgres is that there is no hype. it's one of those systems that have been working for decades. they have their flaws but they are well known and as long as you aware of them it does exactly what it is supposed to do.