Is this any different than how things work in eg Postgres?
> 2. The whole point of adding secondaries — again, the "webscale!" argument — is to scale read capacities
The main driver behind secondaries is redundancy/durability. If the primary goes down, there's no/very little overall service interruption.
If you need the latest data, read from the primary. If you care more about faster reads than perfect data accuracy, read from a secondary.
> Is this any different than how things work in eg Postgres?
1. The comment of mine you are replying to applies to any DB that uses Eventual Consistency, as can be seen above it.
2. Yes, this is different in PG simply because PG doesn't do Eventual Consistency by default.
>> 2. The whole point of adding secondaries — again, the "webscale!" argument — is to scale read capacities
> The main driver behind secondaries is redundancy/durability.
In general, maybe — or even maybe in your specific use-cases. But Mongo's prescribed use-cases — the ones they marketed, heavily, even going so far as to make up terms like "webscale" — are about 'performance' and 'scale'. I specifically call this out in my comment.
Yes, but the product has been advertised from the beginning on the basis of how easy it is to grow horizontally; the whole "It's webscale!" argument.
----
> Eventual consistency only comes in when you introduce multiple nodes / secondaries. As long as you connect to the primary for reads, you'll never get stale data.
1. Writes can be lost if the primary dies and a secondary is promoted before data from primary has been replicated to it.
2. The whole point of adding secondaries — again, the "webscale!" argument — is to scale read capacities