Hacker News Reader

Comment by wbl | Hacker News Reader

Databases can handle multiple concurrent writes just fine and have since the 1970's.

Not a charitable interpretation of the parent comment. Even though databases allow concurrent transactions, commiting these transactions with complete sequential consistency is still an inherently serial process, at least insofar as it cannot be generally split across machines.

There are distributed databases that support serializable transactions across clusters of machines.

https://www.cockroachlabs.com/blog/serializable-lockless-dis...

To the same table? To the same row?

Say you're an ecomm, how do you update inventory on an item "concurrently"? If you're going to say "locks" or "atomic commit", that's exactly what I mean by "you have to serialize your writes".

How much contention are you expecting?

This is a business prediction/problem and exactly what defines your bottleneck.

Just thinking out loud here but the particular case of inventory of an item should be possible to decrement/increment using a PN-Counter CRDT as long as you are fine with eventual consistency. Of course there's a risk of overcommitment which has to be considered but such risks usually exists in commerce any way due to or factors.

Yes, eventual consistency, which is exactly the alternative I mention in my original post.

If you can tolerate eventual consistencies (most problem can), than the database is no longer the slower piece.

I think parent is talking about things like MVCC[1] in contrast with simple read-write locks.

[1] https://en.wikipedia.org/wiki/Multiversion_concurrency_contr...

I think that parent was trying to state that maintaining sequential consistency is a bottleneck for traditional databases.

And that is true if you assume significant contention. Which is not a safe assumption.

If there is no contention, then what is the problem you cannot easily architect around in 2019?

Latency.

Reply on news.ycombinator.com