Making 768 servers look like 1 • Hacker News Board

Re: Making 768 servers look like 1

#11

Post by vkazanov » Thu, Jul 16, 2026, 7:38 AM UTC

drdexebtjl wrote: post #5

What about sequences? The example shows an auto-incrementing user ID. How’s that possible without contention between all shards? Is the proxy responsible for sequences? What about foreign keys? Do they all have to live on the same shard? How do you do distributed transactions? On cross-shard reads: how do you do sorting? And cross-shard joins? I’d love to be proven wrong, but I suspect the 768 servers look like 1 onl…

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.

Re: Making 768 servers look like 1

#12

Post by ahk-dev » Thu, Jul 16, 2026, 9:15 AM UTC

vkazanov wrote: post #11

drdexebtjl wrote: post #5

What about sequences? The example shows an auto-incrementing user ID. How’s that possible without contention between all shards? Is the proxy responsible for sequences? What about foreign keys? Do they all have to live on the same shard? How do you do distributed transactions? On cross-shard reads: how do you do sorting? And cross-shard joins? I’d love to be proven wrong, but I suspect the 768 servers look like 1 onl…

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 mo…

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.

Re: Making 768 servers look like 1

#13

Post by groundzeros2015 » Thu, Jul 16, 2026, 10:17 AM UTC

I disagree with the opening premise:

> A single database server cannot handle such demand, so we must spread the queries and data out across many servers with database sharding

Did you max out the capacity of the best server you can buy?

Such a database can serve millions of customers (the numbers given).

You always want to scale up the other parts first, request handlers, caching, etc. The day you can no longer inspect the essential state of your system is the day your company better be included in NASDAQ and ready to pay a few hundred engineers 300k salaries.

Re: Making 768 servers look like 1

#14

Post by anonzzzies » Thu, Jul 16, 2026, 10:28 AM UTC

groundzeros2015 wrote: post #13

I disagree with the opening premise: > A single database server cannot handle such demand, so we must spread the queries and data out across many servers with database sharding Did you max out the capacity of the best server you can buy? Such a database can serve millions of customers (the numbers given). You always want to scale up the other parts first, request handlers, caching, etc. The day you can no longer insp…

Well, they are selling this thing so they don't want you to buy a big server (with a read replica) as that's much cheaper.

Re: Making 768 servers look like 1

#15

Post by p1necone » Thu, Jul 16, 2026, 10:29 AM UTC

groundzeros2015 wrote: post #13

I disagree with the opening premise: > A single database server cannot handle such demand, so we must spread the queries and data out across many servers with database sharding Did you max out the capacity of the best server you can buy? Such a database can serve millions of customers (the numbers given). You always want to scale up the other parts first, request handlers, caching, etc. The day you can no longer insp…

Most non FAANG orgs could probably serve all their customers from postgres on a laptop.

Re: Making 768 servers look like 1

#16

Post by jackb4040 » Thu, Jul 16, 2026, 10:35 AM UTC

groundzeros2015 wrote: post #13

I disagree with the opening premise: > A single database server cannot handle such demand, so we must spread the queries and data out across many servers with database sharding Did you max out the capacity of the best server you can buy? Such a database can serve millions of customers (the numbers given). You always want to scale up the other parts first, request handlers, caching, etc. The day you can no longer insp…

I found the article very helpful from a technical perspective, and didn't focus on the number too much, as it could easily be swapped and the decision-making process for when to shard is kinda out of scope.

But I hadn't considered this, so thanks for pushing back. Good to keep in mind their incentives.

I will say, since their product is a proxy whose interface is a single SQL connection, you should in theory be able to do dev queries through that black box, much the same as application queries? What is so scary here that it would require a hundred engineers?

Re: Making 768 servers look like 1

#17

Post by jackb4040 » Thu, Jul 16, 2026, 10:39 AM UTC

drdexebtjl wrote: post #5

What about sequences? The example shows an auto-incrementing user ID. How’s that possible without contention between all shards? Is the proxy responsible for sequences? What about foreign keys? Do they all have to live on the same shard? How do you do distributed transactions? On cross-shard reads: how do you do sorting? And cross-shard joins? I’d love to be proven wrong, but I suspect the 768 servers look like 1 onl…

I had this question too, even their "Database Scaling" course doesn't get to it.

https://vitess.io/docs/faq/sharding/advanced/

Looks like it's not drop-in, you need to heavily modify your data and indexes structurally to make sharding performant. Cross-shard joins are possible but need to be designed for explicitly (to be fair, indexes also need to be designed explicitly in regular SQL). IDK if a drop-in solution is possible or if this is an information-theoretical limitation.

Re: Making 768 servers look like 1

#18

Post by Hugsbox » Thu, Jul 16, 2026, 10:50 AM UTC

Took me an embarrassing amount of time to realize this is an ad.

Re: Making 768 servers look like 1

#19

Post by foxhill » Thu, Jul 16, 2026, 10:54 AM UTC

i do wonder how something like this can be generally implemented. i presume this must only support a subset of SQL/plpgsql, as some things would be.. utterly insane to manage manually. e.g., if i have a table with a btree-gist overlap constraint, or some inclusion-exclusion check-constraint (or literally any constraint that requires multiple rows to be fully determined - there are quite a lot of them), how on earth does this work?

there's a reason why postgres writing is (mostly) serialised (asterisk) to a single writer (asterisk asterisk). something something ACID, but in short by having multiple writers improves availability, but weakens integrity.

Re: Making 768 servers look like 1

#20

Post by groundzeros2015 » Thu, Jul 16, 2026, 10:54 AM UTC

jackb4040 wrote: post #16

groundzeros2015 wrote: post #13

I disagree with the opening premise: > A single database server cannot handle such demand, so we must spread the queries and data out across many servers with database sharding Did you max out the capacity of the best server you can buy? Such a database can serve millions of customers (the numbers given). You always want to scale up the other parts first, request handlers, caching, etc. The day you can no longer insp…

I found the article very helpful from a technical perspective, and didn't focus on the number too much, as it could easily be swapped and the decision-making process for when to shard is kinda out of scope. But I hadn't considered this, so thanks for pushing back. Good to keep in mind their incentives. I will say, since their product is a proxy whose interface is a single SQL connection, you should in theory be able…

> you should in theory be able to do dev queries through that black box

Because it’s a leaky abstraction which is trying to make guarantees over network connections which are extremely difficult to make within the same kernel.

A few questions I would start with:

- is the system even ACID compliant?

In my reading of this article, no.

- is my sql feature set limited? Will it enforce all constraints? Or are their cross-shard limitations?

For example the article doesn’t discuss transactions or how they would roll back, or how they guarantee a consistent view of data.

- how does it respond to load?

This is a complex system and complexity breeds bugs. But now you don’t have the tools or procedures to investigate those bugs because you can’t poke the system at desk with tools. You can’t run experiments; you can’t even see all the data.