Hacker News new | past | comments | ask | show | jobs | submit
r7n | on: PgDog is funded and coming to a database near you
I've extensively used Dynamo (internally at Amazon and externally) and even founded a DB startup with it at it's core. Boiling down scalability of Postgres vs Dynamo as it's written in blog is a bit terse. Dynamo scales writes horizontally with the keyspace, forever. Postgres simply can't, and no number of layers between the machines and the developer changes that. Sharding, pooling, Citus are all layered on top of an engine where a given row's writes still land on one primary.
bofaGuy | parent | next
Dynamo DB isn’t even good at being a KV store. Almost every time we have to also back it with S3 because of size limitations.
moomoo11 | root | parent | next
did you use single table design?

and yeah you have to spend a lot of upfront time designing your data models

ngc248 | root | parent
If you know your access patterns really well and they are non-relational, then you can design the best possible tables for dyanmoDB. In such a case DynamoDB works and scales amazingly. Ofc, you cannot do multi table relationships etc shoehorning a relational scheme onto DynamoDB does not work.
zamalek | parent | next
Dynamo is a fundamentally different DB to Postgres. If your problem fits into the dynamo approach (I'd argue that more problems do), then you should be using it. No all problems fit, though.
r7n | root | parent
Agreed, my critique was about how the article frames scalability. I've yet to see an OLTP problem that can't live in something like Dynamo. KV can model anything if you put in the work, the question is how much modeling discipline you trade for the scale, and in my experience the up front work is always worth it. Most of the time operational issues are swept under the rug and not consider tech debt.

Take for example AuroraDB: the sheer engineering it took to make SQL do scalable OLTP at all tells you how much that flexibility actually costs to keep.

ah27182 | root | parent
Upfront modeling work is always worth it, but that only holds if you actually know your access patterns upfront. Most teams don’t, especially early on.
jsw | parent | next
Curious how the DB startup with Dynamo at its core went. We use it heavily. The primary tricky thing for us at the moment is aligning pricing with workload value.
r7n | root | parent
We obsessed over optimizations and pushing the apis to the limits of how we could pack it.

So much so, we re-wrote the DynamoSDK to squeeze out more optimizations so we could be the same cost even though we were a layer in front of dynamo. We used key encoding and other various technique as well as managed capacity (on demand vs reserved) to transparently optimize workloads for price. In our experience we saw dramatic gains vs just vanilla SDK usage.

If you're curious, here was the marketing website, but we're now part of Databricks: https://stately.cloud/

loading story #48481479
cherioo | parent
Except that dynamo is still just glorified mysql? https://news.ycombinator.com/item?id=18871661

I don’t think the backend matters. It’s the frontend wrapper that makes or breaks HA.

inigyou | root | parent
If Dynamo is glorified MySQL then Hacker News is also glorified MySQL. The system is the whole system, not just one part of it.