5 ms·

Fair enough! I think that's a reasonable position. IMO, there are two times you should absolutely default to DynamoDB: - Very high scale workloads, due to its

by abd12 6y ago

Fair enough! I think that's a reasonable position. IMO, there are two times you should absolutely default to DynamoDB: - Very high scale workloads, due to its scaling characteristics - Workloads w/ serverless compute (aka Lambda) due to how well it fits with the connection model, provisioning model, etc. You can use DynamoDB for almost all OLTP workloads, but outside of those two categories, I won't fault you for choosing an RDBMS. Agree that DynamoDB isn't _blazing_ fast. It's more that it's extremely consistent. You're going to get ~10 millisecond response times when you have 1GB of data or when you have 10 TB of data, and that's pretty attractive.

bufferoverflow 6y ago
There's a third use: if you want a free ride, AWS free tier for DynamoDB is quite nice, enough to run a decent dynamic website.
- scarface74 6y ago
  Especially combined with the always free tier of lambda....
arpinum 6y ago
> Workloads w/ serverless compute (aka Lambda) due to how well it fits with the connection model, provisioning model, etc. This is only true for AWS. Azure functions share resources and don't have this issue. The speed is actually quite sad. Its 5-10x slower than my other databases at p95, and I can't throw money at the problem on the write side. Reads I can use DAX, but then there goes consistency.
- abd12 6y ago
  Good point! I would usually not recommend using a database from a different cloud provider just because of different hassles around permissions, connections, etc. I've never found the speed an issue, but YMMV. To me, the best thing is that you won't see speed degradation as you scale. With a relational database, your joins will get slower and slower as the size of your database grows. With DynamoDB, it's basically the same at 1GB as it is at 10TB.
scarface74 6y ago
Workloads w/ serverless compute (aka Lambda) due to how well it fits with the connection model, provisioning model, etc. If you can use Aurora Serverless, the Data API makes sense for lambda. https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/data-api.html https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide...
- abd12 6y ago
  True! I'm not a huge fan of Aurora Serverless and the Data API. The scaling for Aurora Serverless is slow enough that it's not really serverless, IMO. And the Data API adds a good bit of latency and has a non-standard request & response format, so it's hard to use with existing libraries. But it's definitely an option for those that want Lambda + RDBMS. The RDS Proxy is _hopefully_ a better option in this regard but still early.
  - mmbleh 6y ago
    Differing opinion - I think RDS Proxy is the wrong approach. Adding an additional fixed cost service to enable lambda seems like an indicator of a bad architecture. In this case the better approach would likely be to just use a Fargate container which would have a similar cost and fewer moving parts. By the time you pay a fixed cost for the proxy on top of what you already pay for the RDS server, it'd be a far simpler architecture with less moving parts to just run a Fargate container (or better yet, AWS would offer a Google Cloud Run competitor) The Data API, while still rough around the edges, at least keeps the solution more "serverless-y". Over time it should get easier to work with as tooling improves. At the very least, it won't be more difficult to work with than DynamoDB was initially with it's different paradigm. For services that truly require consistently low latency, lambda shouldn't be used anyway, so the added latency of the data api shouldn't be a big deal IMO. For those reasons, I view the RDS Proxy as an ugly stopgap that enables poor architecture, whereas the Data API actually enables something new, and potentially better. So I'd much rather AWS double down on it and quickly add some improvements.
    - scarface74 6y ago
sudhirj 6y ago
Not to mention the same also applies for load. You get about 10ms at 10, 1000 or 1000000 requests per second, again irrespective of how much data you have.

by abd12 6y ago

bufferoverflow 6y ago

There's a third use: if you want a free ride, AWS free tier for DynamoDB is quite nice, enough to run a decent dynamic website.

scarface74 6y ago
Especially combined with the always free tier of lambda....

arpinum 6y ago

> Workloads w/ serverless compute (aka Lambda) due to how well it fits with the connection model, provisioning model, etc. This is only true for AWS. Azure functions share resources and don't have this issue. The speed is actually quite sad. Its 5-10x slower than my other databases at p95, and I can't throw money at the problem on the write side. Reads I can use DAX, but then there goes consistency.

abd12 6y ago
Good point! I would usually not recommend using a database from a different cloud provider just because of different hassles around permissions, connections, etc. I've never found the speed an issue, but YMMV. To me, the best thing is that you won't see speed degradation as you scale. With a relational database, your joins will get slower and slower as the size of your database grows. With DynamoDB, it's basically the same at 1GB as it is at 10TB.

scarface74 6y ago

Workloads w/ serverless compute (aka Lambda) due to how well it fits with the connection model, provisioning model, etc. If you can use Aurora Serverless, the Data API makes sense for lambda. https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/data-api.html https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide...

abd12 6y ago
True! I'm not a huge fan of Aurora Serverless and the Data API. The scaling for Aurora Serverless is slow enough that it's not really serverless, IMO. And the Data API adds a good bit of latency and has a non-standard request & response format, so it's hard to use with existing libraries. But it's definitely an option for those that want Lambda + RDBMS. The RDS Proxy is _hopefully_ a better option in this regard but still early.
- mmbleh 6y ago
  Differing opinion - I think RDS Proxy is the wrong approach. Adding an additional fixed cost service to enable lambda seems like an indicator of a bad architecture. In this case the better approach would likely be to just use a Fargate container which would have a similar cost and fewer moving parts. By the time you pay a fixed cost for the proxy on top of what you already pay for the RDS server, it'd be a far simpler architecture with less moving parts to just run a Fargate container (or better yet, AWS would offer a Google Cloud Run competitor) The Data API, while still rough around the edges, at least keeps the solution more "serverless-y". Over time it should get easier to work with as tooling improves. At the very least, it won't be more difficult to work with than DynamoDB was initially with it's different paradigm. For services that truly require consistently low latency, lambda shouldn't be used anyway, so the added latency of the data api shouldn't be a big deal IMO. For those reasons, I view the RDS Proxy as an ugly stopgap that enables poor architecture, whereas the Data API actually enables something new, and potentially better. So I'd much rather AWS double down on it and quickly add some improvements.
  - scarface74 6y ago

sudhirj 6y ago

Not to mention the same also applies for load. You get about 10ms at 10, 1000 or 1000000 requests per second, again irrespective of how much data you have.