Learn the real differences between UUIDs, hashes, and timestamps as identifiers, and when to use each one.
UUIDs, hashes, and timestamps all get used as identifiers, but each solves a genuinely different problem, and picking the wrong one for a given job is a common design mistake.
| Need | Best Fit | Why |
|---|---|---|
| A unique ID for a new database record | UUID | No coordination needed between systems generating IDs. |
| Detecting if a file’s contents changed | Hash | Same content always produces the same hash; any change produces a different one. |
| Recording when an event happened | Timestamp | Naturally represents and sorts by time, though it isn’t unique alone. |
Real systems often combine more than one: an event log might pair a timestamp (when it happened) with a UUID (a unique reference for that specific event), while a caching system might use a hash of a file’s contents as its cache key, so identical content always maps to the same cache entry.
The UUID Generator, Hash Generator, and Timestamp Converter help generate and work with all three identifier types directly.
UUID Generator
A UUID is generated randomly and carries no relationship to any content. A hash is derived deterministically from specific input content, so the same content always produces the same hash.
Not reliably on its own, since multiple events can share the same timestamp, especially when many events happen in quick succession.
A UUID is generally the best fit, since it lets any system generate a new, effectively unique ID independently, without needing to check with a central source first.
A hash, since identical content always produces the identical hash, making it easy to compare two pieces of content without comparing them directly, byte for byte.
Yes, and it’s common to do so, for example pairing a timestamp (for ordering) with a UUID (for a unique reference) in an event log.
Find the right tool, or keep reading Brekzy's other guides.