On: OrbitDB: Peer-to-peer databases for the decentrali...

[xchaotic]

eventually consistent database Is an oxymoron

[dang → xchaotic]

Please don't post unsubstantive comments here.

[ArnoVW → xchaotic]

In case you didn't know, it's in used as a technical term in distributed computing circles.

https://en.m.wikipedia.org/wiki/Eventual_consistency

[seangrogg → xchaotic]

Alternatives to strong consistency in databases has been around for quite a while...

[AtlasBarfed → xchaotic]

When you get down to it, between cache coherency across CPUs and memory, disk flush delays and disk caches, every database is eventually consistent.

And if you want to operate over a distributed network, which means you WILL have network partitions, then you are subject to CAP and will need eventual consistency mechanisms.

[jacobparker → AtlasBarfed]

> When you get down to it, between cache coherency across CPUs and memory, disk flush delays and disk caches, every database is eventually consistent.

This is a false. None of the things you listed preclude consistency.

> And if you want to operate over a distributed network, which means you WILL have network partitions, then you are subject to CAP and will need eventual consistency mechanisms.

That's not how CAP works. Plenty of distributed CP databases exist.

[dchyrdvh → xchaotic]

Iirc, Spanner is eventually consistent.

[aprao → dchyrdvh]

Cloud Bigtable is eventually consistent, Spanner is strongly consistent.

[exacube → dchyrdvh]

spanner is strongly consistent

[dastbe → exacube]

spanner does support eventually consistent snapshot reads as well with improved latency benefits (as you're effectively foregoing a transaction).

[vhiremath4 → xchaotic]

Ask me how I know you've never scaled a high throughput Elasticsearch cluster.