Replying to all. @jeltz: > Time sortable UUIDs... Then perhaps store the time as a separate field? Makes them indexable and trivially extracted. > you ensur

Replying to all. @jeltz: > Time sortable UUIDs... Then perhaps store the time as a separate field? Makes them indexable and trivially extracted. > you ensure that inserts are quite often done in sequential order, which is good for btrees. I've just explained why that may not be the case under high insertion rates. This from https://www.sqlpassion.at/archive/2014/04/15/an-ever-increasing-clustered-key-value-doesnt-scale/ https://www.sqlpassion.at/archive/2014/04/15/an-ever-increas... "With the best practice of an ever-increasing Clustered Key value you have a single hotspot at the end of your Clustered Key. The smaller your records are, the more contention you are introducing here. How can you solve that problem? Easy: spread your INSERT statements across the whole B-Tree structure of the Clustered Index." @willvarfar: > Its hard to find a natural key for something as simple as a customer... OK, completely agree, and you go further - I can't dispute any of that. Only thing I'd say is perhaps don't use a UUID. A 4 byte int will give you plenty of space and use 1/4 of the memory of a GUID. But I may just be splitting hairs. Point accepted! @heavenlyblue: > A billion rows require a gigabyte per each extra byte in a row. That's nothing. I can do the maths, thanks. But if you need real-time responses out a single DB machine serving many users, some heavy, then you have to cache 98% to 100% inside the RAM. Each gig of table read may be an extra 1-5 seconds, depending on disks & setup. Contention increases as more users pile in. Contention increases horribly if queries are greatly slowed by needing to read off the disk. I was fighting for that space to get, and keep, responsiveness. "buy more machines" is a good response but only after you've optimised to the point of minimal returns. We were a small company, we had to make it work.