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.
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?
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 ?