Hacker News Reader

Comment by cheeze | Hacker News Reader

AWS-Exclusive from my understanding. Not in AWS but from reading other comments, it sounds like this has been widely used internally for some time.

View on HN

Correct QLDB has been widely used within AWS:

https://twitter.com/timbray/status/1067836869021327361

https://twitter.com/colmmacc/status/1067832198059970561

Do you know if the QLDB write API is more like an event store or more like a relational database? It sounds like the read API provides both models (read the journal, or read the snapshot).

It should work for both cases. It's an append-only ledger that captures any mutations on records previously on the ledger. It uses a recent snapshot primarily for efficiency to avoid having to read the entire ledger to enforce any transactional or schema constraints.

So it's an event store in that each write transaction is an event. But it's a relational DB in that it (at least the internal version did) schemas, multi-record updates, and transactions.

That's an understandable implementation, but a bit disappointing. It means that there's not going to be a simple way to process the journal since that log will consists of differently sized writes to the database. It would have been more interesting if QLDB was a CQRS+EventStore with built-in snapshots.

I was at Amazon during early development and watched several of the PoA talks about it. On the one hand, the concept is surprisingly simple, on the other hand, it's such a useful general purpose concept that it's surprising it wasn't done earlier. I believe it's first public use case was Database Migration Service. It's neat to see it offered as it's own product.

Reply on news.ycombinator.com