discussion

> merge databases You mean combining logically (or even physically) separated databases, collapsing their tuples into one? Why would you do that, and how often does that occur? > first hand support across various databases/systems UUIDs? Of the RDBMS most likely to be used (MySQL, Postgres, SQLite) only Postgres has a UUID type. The others store them as strings (please no) or binary types. MariaDB and Oracle have UUID types, and SQL Server has a GUID (essentially the same thing) type, but those are all less commonly seen. What does have universal support is integers. They scale just fine (PlanetScale uses them [0] internally), and you can use them in a distributed system – if you even need one in the first place – via a variety of methods: interleaved ranges or a central server allocating chunks are two popular methods that come to mind.

UUIDv4 specifically (though ULID [EDIT: this is incorrect, I was thinking of NanoID] has the same problem). Anything non-k-sortable will bloat a B+tree index, causing far more reads than should be required. MySQL (technically InnoDB) and SQL Server have a huge problem with them due to their design as a clustering index – since the tuples are physically located, or clustered, around the PK, the random nature means that doing a simple query like "SELECT id FROM customer WHERE date_created > NOW() - INTERVAL 1 WEEK" means that the hits are going to be on tons of different pages. Even if everything is cached, that's still a lot of extra work. Postgres has its own problems with them as well. In the above query, it's possible that it could be an index-only scan. Great, you don't have to dereference the pointer to find the tuple in the heap! Exc

> incrementing IDs falls over too This is a myth. Planetscale [0] uses integers. They are assuredly at scale. As for auto-incrementing, there are plenty of solutions for distributed systems. [0]: https://github.com/planetscale/discussion/discussions/366

If you can’t model the table with a natural key (or it would be so large as to inhibit performance), then a simple, normal monotonic integer is best. MySQL even lets you use unsigned ints, so if you use a bigint, you can go all the way up to 2^64-1. For those who think this doesn’t work in distributed systems, it absolutely does – PlanetScale uses them internally [0]. If what is likely the largest MySQL (under Vitess) cluster in the world can manage, yours can too. If this is still untenable, then anything k-sortable (like UUIDv7, as the sibling comment mentioned) is a vast improvement over randomness. Don’t cause B+tree page splits, especially in an RDBMS with a clustering index like MySQL. [0]: https://github.com/planetscale/discussion/discussions/366

If you have a sharded DB, each instance can get its own range of ints, which are periodically refreshed. PlanetScale uses int PKs [0], and they seem to have scaled just fine. [0]: https://github.com/planetscale/discussion/discussions/366

It adds a lot of overhead at any scale, it’s just that the overhead is hidden due to the absurd speed of modern hardware. I’ll again point out (I said this elsewhere in a post today on UUIDs) that PlanetScale uses int PKs internally. [0] That is a MASSIVE distributed system, working flawlessly with integers as keys. They absolutely can scale, it just requires more thoughtful data modeling and queries. [0]: https://github.com/planetscale/discussion/discussions/366

> Integers don't scale because you need a central server to keep track of the next integer in the sequence. They most assuredly do scale. [0] Also, Slack is built on MySQL + Vitess [1], the same system behind PlanetScale, which internally uses integer IDs [2]. [0]: https://www.enterprisedb.com/docs/pgd/latest/sequences/#glob... [1]: https://slack.engineering/scaling-datastores-at-slack-with-v... [2]: https://github.com/planetscale/discussion/discussions/366

Please prioritize the standard connection string access method: https://github.com/planetscale/beta/discussions/15 This single feature would open up a lot of usage for me and many others I know.