[somethingAlex]

A concrete example would be a users shopping cart, as they build it. You don’t need the niceties of a fully ACID compliant DB, you need write performance, and extremely high availability.

That was at least a chief use case spotlighted in the original Dynamo paper by Amazon that what the precursor to AWS’ DynamoDB paper.

Not to say that couldn’t be done with Postgres but of course they were dealing with insane scale on Amazon Day.

[ledauphin]

it's a common misconception that modern non-relational stores (such as DynamoDB) aren't ACID compliant. DynamoDB offers ACID transactions, even across tables, as of several years ago.

not that you're saying they don't, but some people might interpret your comment that way.

[AdieuToLogic]

> DynamoDB offers ACID transactions, even across tables, as of several years ago.

It depends on how DynamoDB is used[0]:

  Transactional operations provide atomicity, consistency,
  isolation, and durability (ACID) guarantees only within
  the region where the write is made originally.

  Transactions are not supported across regions in global
  tables.

Granted, this likely handles most use-cases and the restriction enforced makes complete sense.

0 - https://docs.aws.amazon.com/amazondynamodb/latest/developerg...

[xwowsersx]

That's right. FoundationDB and ArangoDB, among others, are also ACID-compliant, I believe.

[AdieuToLogic]

> A concrete example would be a users shopping cart, as they build it. You don’t need the niceties of a fully ACID compliant DB, you need write performance, and extremely high availability.

Using a key-value store for shopping carts can work for awhile, especially for the use-case you describe, but fails when system functionality grows beyond retrieving only by a cart ID.

And when using a persistent store which does not provide ACID capabilities, the system will ultimately have to enforce at least atomicity and consistency via server logic.

[makeitdouble]

> when system functionality grows beyond retrieving only by a cart ID.

Either you manage your system so it never ever uses any other key than a cart ID (services have been running for decades keeping the same unique ID, that's not some unreasonable thing).

Or you migrate your data to match the completely wild new requirement, and taking costly steps to deal with a funfamental business change would be seen as reasonable in most orgs.