Hacker News Reader

Comment by mightyham | Hacker News Reader

Latency can also be traded for availability. EBS storage provides replication and can trivially be removed/attached to new instances if the database server for some reason needs to be taken down. Any database with built-in replication/consensus (Kafka, Spanner, Dynamo, Cockroach, etc.) is making this same tradeoff and is effectively hitting the network on every storage request.

View on HN

> Any database with built-in replication/consensus (Kafka, Spanner, Dynamo, Cockroach, etc.) is making this same tradeoff and is effectively hitting the network on every storage request.

I don't think this is true. I am not sure about those you described, but say you have PG replicas, you can run query on replica node without hitting some network attached storage. This is obviously true for reads but not for writes.

Yeah, you are correct. I was thinking about writes but not reads. Even the databases I mentioned typically have optimizations such that when there is a stable leader, reads don't require any network.

"Unnecessary" is the keyword you missed. Refer to sentences 1, 2 and 3 in my response.

The argument of cost is fundamental and no amount of Kafka, etc. can override it.

Gotcha, seems like we agree then.

Considering that the topic is an article is comparing raw NVMe vs EBS performance for postgres storage and GP saying that cloud is unnecessarily inefficient, I misinterpreted your comment as implying that networked storage is always an unnecessary cost. In many cases the cost of replication and availability is lower than the cost of data loss and downtime.

Even during replication, any unnecessary network payload beyond the absolute minimum required is still a cost that boils my blood :-).

Reply on news.ycombinator.com