Introduction: Are UUIDs Killing the Planet?
Okay, maybe that's a bit dramatic—but it’s a question worth asking: Are our beloved 128-bit UUIDs quietly contributing to environmental degradation? In an era where every byte stored and every cycle spent matters, it's time to ask the hard questions... and crack a few smiles along the way.
Let’s explore the surprisingly tangible resource costs of UUIDs and whether our preference for universality is eating up more energy than we’d like to admit.
What’s in a UUID?
A UUID is a 16-byte (128-bit) identifier designed to be unique across time and space. Here’s what that looks like:
550e8400-e29b-41d4-a716-446655440000Sure, it’s just 36 characters in string form—but that’s a lot more than your humble 4-byte integer (2147483647), and it adds up fast.
Byte by Byte: Storage Overhead
Let’s crunch the numbers:
- UUID (binary): 16 bytes
- UUID (text): 36 characters, typically UTF-8 encoded = 36 bytes
- INT (32-bit): 4 bytes
Result? UUIDs can take up 4x to 9x more space depending on format.
In a database with 1 billion records:
- Using integers: ~4 GB
- Using UUIDs (binary): ~16 GB
- Using UUIDs (text): ~36 GB (!)
And that’s just for the primary key column.
Query Cost: More Than You Bargained For
Textual UUIDs are not just hefty in storage—they're also harder to index and slower to compare. Databases often struggle with:
- Slower B-tree performance on longer keys
- Poorer cache locality
- Increased I/O for range queries
Even binary UUIDs, while better, are still more taxing than simple integers. Multiply that by millions of requests, and yes—you’re drawing more electricity from your data center’s coal-powered wall socket.
Real Impact: Energy Use and CO₂
Let's (roughly) estimate:
- Reading 1 GB of UUIDs from disk per day costs ~5 Wh
- Storing 10x the data over time = 10x the disk usage = more cooling, more hardware
It's not going to single-handedly melt the polar ice caps, but multiplied across billions of devices and cloud services, UUID bloat does have a footprint.
So Should We Stop Using UUIDs?
No—but we should be smarter about it. UUIDs provide critical benefits:
- Global uniqueness without coordination
- Easier sharding in distributed systems
- Less guessable than incremental IDs (security!)
Still, there are smarter ways to UUID:
✅ Use UUIDs in Binary Format
When storing in databases, always use BINARY(16) (MySQL) or uuid (PostgreSQL).
-- PostgreSQL
CREATE TABLE users (
id UUID PRIMARY KEY DEFAULT gen_random_uuid()
);✅ Avoid Textual UUIDs Where Possible
Text UUIDs look pretty, but waste space. If you need human-friendly IDs, consider Base62 or ULIDs for better size/performance trade-offs.
✅ Use Sequential UUIDs
Versions like UUIDv7 (or ULID) preserve uniqueness and enable better indexing.
✅ Audit UUID Necessity
Does every table need a UUID primary key? Could a composite key or integer suffice?
In Defense of Bloat
If the idea of UUID waste keeps you up at night, just remember:
- JavaScript frameworks send megabytes of HTML to display "Hello World"
- Your blockchain app just spent $30 gas fees to mint a pixelated frog
Perspective is important.
Final Thoughts: Be Thoughtful, Not Frugal
UUIDs are a bit bulky—but for most modern systems, the tradeoff is worth it. The key is to use them deliberately, not dogmatically. If you're running a system with billions of records or serving millions of API calls per second, optimizing UUID usage can make a meaningful difference—not just for your wallet, but maybe for the planet too.
But hey, if nothing else, at least now you can guilt-trip your architect into debating whether the environment can handle another UUID column.
Further Reading
- [UUID Format (RFC 4122)](https://www.rfc-editor.org/rfc/rfc4122)
- [UUID vs INT Performance in PostgreSQL](https://www.cybertec-postgresql.com/en/uuid-vs-int-primary-key-performance/)
- [ULID: Universally Lexicographically Sortable Identifier](https://github.com/ulid/spec)