6 ms·

Are there other constraints that might make DynamoDB a good fit? For example I made an app at a client. We could use RDS or we could use Dynamo. I went with Dyn

Are there other constraints that might make DynamoDB a good fit? For example I made an app at a client. We could use RDS or we could use Dynamo. I went with Dynamo because it could fit our simple model. What’s more, it doesn’t get shut off nightly when the RDS systems do to save money. This means we can work work on it when people have to time shift due to events in the life like having to pick up the kids.

tomnipotent 6y ago
> it doesn’t get shut off nightly when the RDS systems do to save money If your company needs to shutdown RDS to save a couple of bucks a month, there's a much larger problem at hand than RDS vs Dynamo.
- Aeolun 6y ago
  At scale it’s a little bit more than a few bucks. Across the board, we spend hundreds of thousands on ec2 instances for dev/test, so turning them off at night when nobody uses them saves you quite a lot of money.
martinald 6y ago
The problem with NoSQL is that your simple model inevitably becomes more complex over time and then it doesn't work anymore. Over the past decade I've realised using a RDBMS is the right call basically 100% of the time. Now pgsql has jsonb column types that work great, I cannot see why you would ever use a NoSQL DB, unless you are working at such crazy scale postgres wouldn't work. In 99.999% of cases people are not.
- xupybd 6y ago
  There are specific cases where a non SQL database is better. Chances are if you haven't hit problems you can't solve with an SQL database you should be using an SQL database. Postgres is amazing and free why would you use anything else.
  - maccard 6y ago
    People keep saying there are specific cases where NoSQL is better, but never what any of those cases are.
    - throwaway870923 6y ago
      Time series is one. Consider an application with 1000 time series, 1 hosts, and 1000 RPS. You are trivially looking at 1M writes per second per host. This usually requires something more than "[just] using a RDBMS".
    - kfir 6y ago
      Here you go, this is from a system I helped building 10 years ago that is an eternity in tech - https://qconlondon.com/london-2010/qconlondon.com/dl/qcon-london-2010/slides/GeirMagnusson_ProjectVoldemortAtGiltGroupeWhenFailureIsntAnOption.pdf https://qconlondon.com/london-2010/qconlondon.com/dl/qcon-lo...
      - kfir 6y ago
        a bit more context: High-velocity transactional systems (e.g any e-commerce store with millions of users all trying to shop at the same time), I helped to build such a 10 years ago here is the presentation - https://qconlondon.com/london-2010/qconlondon.com/dl/qcon-london-2010/slides/GeirMagnusson_ProjectVoldemortAtGiltGroupeWhenFailureIsntAnOption.pdf https://qconlondon.com/london-2010/qconlondon.com/dl/qcon-lo...
- Joeri 6y ago
  We just ported a system that kept large amounts of data in postgres jsonb columns over to mongodb. The jsonb column approach worked fine until we scaled it beyond a certain point, and then it was an unending source of performance bottlenecks. The mongodb version is much faster. In retrospect we should have gone with mongo from the start, but postgres was chosen because in 99% of circumstances it is good enough. It was the wrong decision for the right reasons.
  - martinald 6y ago
    Yep, I agree there are cases where mongodb will perform better. However, many use cases also require joins and the other goodness that relations provide. So really the use case for mongo etc is 'very high performance requirements' AND 'does not require relations'. Many projects may be ok with just one of those. But very few require meet both of those constraints. FWIW I've seen many cases which are sort of the opposite: great performance with mongodb, but then because of the lack of relations for a reporting feature (for example) performance completely plummets due to horrible hacks being done to query the data model that doesn't work with the schema, eventually requiring a rewrite to RDBMS. I would guess that this is much more common.
- lodovic 6y ago
  I found that for an EAV type database, NoSql is a much better match as it doesn't require queries with a million joins. But that's a very specific case indeed.
cbdumas 6y ago
I can't speak to your specific use case, but I can tell you that a relatively small RDS instance is probably a lot more performant than you think. There is also "Aurora Serverless" now which I've just started to play with but might suit your needs. As far as what makes Dynamo a good fit, I almost take the other approach and try to ask myself, what makes Postgres a bad fit? Postgres is so flexible and powerful that IMO you need a really good reason to walk away from that as the default.
- virmundi 6y ago
  Aurora wasn’t allowed at the time. The system is a simple stream logging app. Wonderful for our use case. Dynamo for so far. Corp politics made the RDS instance annoying to pursue.

tomnipotent 6y ago

> it doesn’t get shut off nightly when the RDS systems do to save money If your company needs to shutdown RDS to save a couple of bucks a month, there's a much larger problem at hand than RDS vs Dynamo.

Aeolun 6y ago
At scale it’s a little bit more than a few bucks. Across the board, we spend hundreds of thousands on ec2 instances for dev/test, so turning them off at night when nobody uses them saves you quite a lot of money.

martinald 6y ago

The problem with NoSQL is that your simple model inevitably becomes more complex over time and then it doesn't work anymore. Over the past decade I've realised using a RDBMS is the right call basically 100% of the time. Now pgsql has jsonb column types that work great, I cannot see why you would ever use a NoSQL DB, unless you are working at such crazy scale postgres wouldn't work. In 99.999% of cases people are not.

xupybd 6y ago
There are specific cases where a non SQL database is better. Chances are if you haven't hit problems you can't solve with an SQL database you should be using an SQL database. Postgres is amazing and free why would you use anything else.
- maccard 6y ago
  People keep saying there are specific cases where NoSQL is better, but never what any of those cases are.
  - throwaway870923 6y ago
    Time series is one. Consider an application with 1000 time series, 1 hosts, and 1000 RPS. You are trivially looking at 1M writes per second per host. This usually requires something more than "[just] using a RDBMS".
  - kfir 6y ago
    Here you go, this is from a system I helped building 10 years ago that is an eternity in tech - https://qconlondon.com/london-2010/qconlondon.com/dl/qcon-london-2010/slides/GeirMagnusson_ProjectVoldemortAtGiltGroupeWhenFailureIsntAnOption.pdf https://qconlondon.com/london-2010/qconlondon.com/dl/qcon-lo...
    - kfir 6y ago
      a bit more context: High-velocity transactional systems (e.g any e-commerce store with millions of users all trying to shop at the same time), I helped to build such a 10 years ago here is the presentation - https://qconlondon.com/london-2010/qconlondon.com/dl/qcon-london-2010/slides/GeirMagnusson_ProjectVoldemortAtGiltGroupeWhenFailureIsntAnOption.pdf https://qconlondon.com/london-2010/qconlondon.com/dl/qcon-lo...
Joeri 6y ago
We just ported a system that kept large amounts of data in postgres jsonb columns over to mongodb. The jsonb column approach worked fine until we scaled it beyond a certain point, and then it was an unending source of performance bottlenecks. The mongodb version is much faster. In retrospect we should have gone with mongo from the start, but postgres was chosen because in 99% of circumstances it is good enough. It was the wrong decision for the right reasons.
- martinald 6y ago
  Yep, I agree there are cases where mongodb will perform better. However, many use cases also require joins and the other goodness that relations provide. So really the use case for mongo etc is 'very high performance requirements' AND 'does not require relations'. Many projects may be ok with just one of those. But very few require meet both of those constraints. FWIW I've seen many cases which are sort of the opposite: great performance with mongodb, but then because of the lack of relations for a reporting feature (for example) performance completely plummets due to horrible hacks being done to query the data model that doesn't work with the schema, eventually requiring a rewrite to RDBMS. I would guess that this is much more common.
lodovic 6y ago
I found that for an EAV type database, NoSql is a much better match as it doesn't require queries with a million joins. But that's a very specific case indeed.

cbdumas 6y ago

I can't speak to your specific use case, but I can tell you that a relatively small RDS instance is probably a lot more performant than you think. There is also "Aurora Serverless" now which I've just started to play with but might suit your needs. As far as what makes Dynamo a good fit, I almost take the other approach and try to ask myself, what makes Postgres a bad fit? Postgres is so flexible and powerful that IMO you need a really good reason to walk away from that as the default.

virmundi 6y ago
Aurora wasn’t allowed at the time. The system is a simple stream logging app. Wonderful for our use case. Dynamo for so far. Corp politics made the RDS instance annoying to pursue.