>Using a char type to store UUIDs is very wasteful and no wonder your indexes are so huge. That was a hypothetical, its 22GiB using BLOB storage. >Note also t

>Using a char type to store UUIDs is very wasteful and no wonder your indexes are so huge. That was a hypothetical, its 22GiB using BLOB storage. >Note also that if you need to expose your data, you can either expose the auto incrementing primary key (which leaks data, in that other people can work out growth rates of various models, like how England worked out how many German tanks were being built based on a auto incrementing serial number), or you create a another column (as someone else suggested) which is a uuid. Which you would need to index anyway. I state that we use the auto-increment inside of the application, everything exposed by the API is a UUID. While we lose 32 bits of space per row, just one foreign key or index saves enough space to justify it. Best of both worlds. >Memory and disk space is cheap. Not when you need to move from multiple r4.8XL to r4.16XLs (think multi-az, multi region). It would work out to around double the price, we can hire a developer for the cost of hosting that infrastructure. Even when your business has the money, you don't want to be the guy telling them to drop another $24k a month on hosting costs because we didn't think one year ahead. This of course ignores all the issues that come with replication and partitioning, multi-master etc.