Of course 768 servers NEVER behave as 1. This is physically impossible.

Global services using relational dbs typically severely restrict queries that run against the cluster. So no joins, no intervals, no grouping, etc.

Transactional queries are usually limited to something like "get a single record, preferably from cache". For many typical web services this can go VERY FAR. Only a handful of global services needs more than a few dozen database servers and a caching cluster. In fact, i have seen major businesses running off a pair of very big postgres instances.

Analytical stuff is extracted into dedicated storages optimized for throughput, like Snowflake or Redshift or BigQuery.

▲

samlambert 19 hours ago | parent | next [-]

> Transactional queries are usually limited to something like "get a single record, preferably from cache".

simply wrong

	▲	vkazanov 12 hours ago \| parent \| next [-]
		Well, operational dbs in practical circumstances are used for queries that take predictable time to complete. "Get a row" "Get ten rows" Etc, etc. All constant, all predictable, all not requiring unpredictable time to run. Also caches nicely. What is "simply wrong" here?
	▲	chaps 18 hours ago \| parent \| prev [-]
		Care to explain? Not getting a good vibe from you, Mr. CEO.

▲

ahk-dev a day ago | parent | prev [-]

This seems like the important distinction: making the infrastructure look like one database to the application is different from making it behave like one unrestricted relational database.

At what point does hiding the sharding become counterproductive? I imagine teams still need a fairly deep understanding of shard keys, query routing, and failure modes to avoid accidentally expensive cross-shard operations.

▲

vkazanov a day ago | parent [-]

Yes!

Distributed systems introduce severe restrictions on what can be reasonably done at scale. Having a single connection string is one thing, being able to do a massive JOIN is another (and should only be ever done in analytical databases).

The question is not "when sharding becomes counter-productive" but "when it starts making sense".

With sharding something somewhere has to know how to route queries to subsets of data. So it is a complexity price paid for being able to scale. If one can avoid paying this cost then he should.

And USUALLY cross-shard queries are not just expensive but simply impossible in operational clusters. Like, if you do COUNT on a table, you only count within a single db shard table.

	▲	drdexebtjl 17 hours ago \| parent [-]
		Parent commenter was not asking about when sharding becomes counterproductive, it was asking about when hiding sharding from the application becomes counterproductive. The point is that it’s a leaky abstraction. It should not be at the database proxy level. Instead, the application should be responsible to route queries to the correct shard. That way it can’t make cross-shard queries or cross-shard transactions accidentally, it must do so explicitly.