When I first played with a NoSQL database I become aware of the impact of UUIDs in a distributed system.
MongoDB defaults to ObjectIDs, but I've always questioned in which cases UUID (RFC4122) would be a better choice.
I found out that ObjectIDs are great. Not only they are smaller than UUIDs saving disk space, but they are overall more efficient:
Once I was told:
contrary to UUIDs, ObjectIds are monotonic ... Monotonic indexes will cause the B-Tree to be filled more efficiently, it allows paging by id and allows a 'default sort' by id to make your cursors stable, and of course, they carry an easy-to-extract timestamp. These are the optimizations you should be aware of, and they can be huge.
Suddenly, I've been thinking that while UUIDs might be a a YAGNI case, Mongo ObjectIDs might be premature optimization.
If I default to UUIDs first, someone might claim that I am wasting performance/disk space. However if I choose ObjectIDs first, I might find out later that I need a less collision risky ids. The former is about performance, the latter about design limitations.
Because of my lack of experience with UUIDs, I am not sure if should worry more about performance or freedom.
Which one should be the default ID strategy in projects where the requirements are not clear yet?
UPDATE
I am concerned about a database vendor feature (ids) leaking into my application layer. Am I being too paranoid by sacrificing efficiency for the sake of independence / abstraction ?
Which one should be the default ID strategy in projects where the requirements are not clear yet?
make clear the requirements first and then make the choice. Otherwise, no matter the trade-offs of each solution, you would be taking decisions under false assumptions. – Laiv Jun 4 '17 at 12:16