Have you never worked on a large distributed system before? There are good reasons not to use integer ids:
Generating ids on multiple machines is a hassle and requires careful configuration, which is not necessary when using uuid/cuid2 or something.
Ids have to be generated by the database, which is a huge degradation of overall system performance. If the application can generate the id, then the database insert is not a blocking operation anymore and you can just continue.
The performance difference is highly negligible, as it’s massively outweighed by fetching rows for example. With a proper database design, the difference is anywhere between 1-5%. If that makes the difference for your application, you’ve already made poor design decisions elsewhere that are far more important.
We use prefixed incrementing base63 uuids. It’s highly performant and we can generate it in the application, saving a lot of time in many processes because we don’t have to wait for the database anymore.
I’m sure doing int indexes over strings was once considered the gold standard but that’s not been true for years now. Yes, it’s slightly better for database performance. No, it’s not better overall for a slew of reasons, including system performance.
so we’re calling “not doing pointless unnecessary work” premature optimization now? cool cool
Making me learn how to do things the right way is premature optimization
Have you never worked on a large distributed system before? There are good reasons not to use integer ids:
We use prefixed incrementing base63 uuids. It’s highly performant and we can generate it in the application, saving a lot of time in many processes because we don’t have to wait for the database anymore.
I’m sure doing int indexes over strings was once considered the gold standard but that’s not been true for years now. Yes, it’s slightly better for database performance. No, it’s not better overall for a slew of reasons, including system performance.
ok shut up now