Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Distributed Transactions at Scale in Amazon DynamoDB (2023)

muratbuffalo.blogspot.com

Post reply on HN
Print view View original

21–30 of 62 posts

Re: Distributed Transactions at Scale in Amazon DynamoDB (2023)

#21

Post by belter »

qaq wrote: post #14

AWS needs to buy a proper newSQL databse Dynamo is just horribly outdated product.

> AWS needs to buy a proper newSQL databse Dynamo is just horribly outdated product.

I am sorry but engaging in good faith, can you quality a little bit? Are you aware DynamoDB works as tier one product within AWS? Meaning it's one of the core pillars of the implementation of many other products?

Did you look at these references?: https://aws.amazon.com/dynamodb/customers/

Have you seen the real world use?: https://aws.amazon.com/blogs/aws/prime-day-2023-powered-by-a...

Re: Distributed Transactions at Scale in Amazon DynamoDB (2023)

#22

Post by oweiler »

njitbew wrote: post #8
tbarbugli wrote: post #2

Using DynamoDB in 2025 is such a weird proposition. Horrible dev experience, no decent clients/libs, complex pricing, weird scaling in/out mechanism, slow, it only works well for well defined use-cases.

> Horrible dev experience, no decent clients/libs, complex pricing, weird scaling in/out mechanism, slow, it only works well for well defined use-cases. Most of these arguments probably don't outweigh the benefits. If you're in need of a managed, highly-consistent, highly-scalable, distributed database, and you're already an AWS customer, what would you use instead?

Aurora Serverless Postgres e.g.

Re: Distributed Transactions at Scale in Amazon DynamoDB (2023)

#23

Post by belter »

tbarbugli wrote: post #2

Using DynamoDB in 2025 is such a weird proposition. Horrible dev experience, no decent clients/libs, complex pricing, weird scaling in/out mechanism, slow, it only works well for well defined use-cases.

> It only works well for well defined use-cases.

This strongly hints at a misunderstanding of the purpose of a NoSQL system.

Re: Distributed Transactions at Scale in Amazon DynamoDB (2023)

#24

Post by belter »

oweiler wrote: post #22
njitbew wrote: post #8

Earlier quoted context omitted.

> Horrible dev experience, no decent clients/libs, complex pricing, weird scaling in/out mechanism, slow, it only works well for well defined use-cases. Most of these arguments probably don't outweigh the benefits. If you're in need of a managed, highly-consistent, highly-scalable, distributed database, and you're already an AWS customer, what would you use instead?

Aurora Serverless Postgres e.g.

Completely different use cases....

Re: Distributed Transactions at Scale in Amazon DynamoDB (2023)

#25

Post by sgarland »

redwood wrote: post #15
qaq wrote: post #14

AWS needs to buy a proper newSQL databse Dynamo is just horribly outdated product.

What's your take on Aurora DSQL? My take is anything single cloud provider proprietary and tabular in 2025 is going to over time feel too limited. Having a json column doesn't cut it. But I'm a believer in document databases

Relational databases (sans JSON columns) are limited in the same way that seatbelts limit your ability to be transfenestrated during a crash.

Having a rigid and well-designed schema is a mechanism to keep you or your team from doing stupid things.

Re: Distributed Transactions at Scale in Amazon DynamoDB (2023)

#26

Post by [deleted] »

guiriduro wrote: post #9
tbarbugli wrote: post #2

Using DynamoDB in 2025 is such a weird proposition. Horrible dev experience, no decent clients/libs, complex pricing, weird scaling in/out mechanism, slow, it only works well for well defined use-cases.

Way too many teams choose Dynamodb too soon. Scalability, 0 management, coolness whatever. They don't realise until its too late that their application data needs are changing with feature requests and that with Ddb it implies doing 3D-chess each time to ensure the denormalised data is re-arranged the right way, rather than just using PostgreSQL with JSONB and adding an index, until/if it gets to FAANG scale, a bridg…

[deleted]

Re: Distributed Transactions at Scale in Amazon DynamoDB (2023)

#27

Post by moomoo11 »

tbarbugli wrote: post #2

Using DynamoDB in 2025 is such a weird proposition. Horrible dev experience, no decent clients/libs, complex pricing, weird scaling in/out mechanism, slow, it only works well for well defined use-cases.

I’ve used dynamodb before but most people have no idea what they’re talking about re: it and start blaming the tool.

Like when we implemented it me and my colleague spent a couple days understanding single table design and how to handle the access patterns we wanted to support.

Trying to explain this to paper smart but lazy colleagues who then skipped understanding and went straight to implement something wrong and blamed the tool really opened my eyes.

For us dynamo made sense. We were tracking global quantities and things like that. Didn’t need to be real time but did need to be present across regions fast.

Re: Distributed Transactions at Scale in Amazon DynamoDB (2023)

#28

Post by Lapapapaja »

mrkeen wrote: post #5
tbarbugli wrote: post #2

Using DynamoDB in 2025 is such a weird proposition. Horrible dev experience, no decent clients/libs, complex pricing, weird scaling in/out mechanism, slow, it only works well for well defined use-cases.

Very often I find myself wanting to store item(s) using a key. My items are not relations, and I don't see the point in transforming them to and from relational form. And if I did, each row would have like 5 columns set to NULL, in addition to a catch-all string 'data' column where I put the actual stuff I really need. Which is how you slow down an SQL database. So RDBMS is no good for me, and I'm no good for RDBMS.…

> I still lean into events & eventual consistency to manage state across the various nodes.

You can get really far with a RDMS before event sourcing etc is needed, the benefit being both your dev and user experience are going to be much simpler and easier.

If you already know your problem domain and scaling concerns up front sure. But starting with a scalable pattern like this is a premature optimization otherwise and will just slow you down.

Re: Distributed Transactions at Scale in Amazon DynamoDB (2023)

#29

Post by tempworkac »

sgarland wrote: post #25
redwood wrote: post #15

Earlier quoted context omitted.

What's your take on Aurora DSQL? My take is anything single cloud provider proprietary and tabular in 2025 is going to over time feel too limited. Having a json column doesn't cut it. But I'm a believer in document databases

Relational databases (sans JSON columns) are limited in the same way that seatbelts limit your ability to be transfenestrated during a crash. Having a rigid and well-designed schema is a mechanism to keep you or your team from doing stupid things.

nosql does not imply no schema

Re: Distributed Transactions at Scale in Amazon DynamoDB (2023)

#30

Post by smashedtoatoms »

I came here for the bad takes, and I have not been disappointed. Dynamo slays when you know your access patterns and need consistent performance and no operations requirements. Turns out, that's the case most of the time. Think about it as application state instead of a db. It's not key-value like Redis. GSIs with compound keys allow access to data across multiple dimensions on virtually unlimited data with consistent performance. Its weakness is querying data across dimensions you didn't plan on. If you need that regularly, it sucks. If you need that once in awhile, write a migration.
Post reply on HN