DEV Community: Terfa Binda

7 Performance Considerations When Using UUIDs in Node.js: A Developer's Journey

Terfa Binda — Wed, 26 Feb 2025 09:01:45 +0000

It was a typical Monday morning, and I had just started my latest project—a real-time collaboration platform where users could work together on documents without stepping on each other’s toes. As I sat down to design the database schema, I knew I wanted something that would scale effortlessly as our user base grew. That’s when I turned to UUIDs (Universally Unique Identifiers). They seemed perfect for the job—guaranteed uniqueness, no collisions, and easy integration with modern databases.

But little did I know, this decision would lead me down a rabbit hole of performance considerations. After weeks of debugging, optimizing, and learning from my mistakes, I realized there are more than just a few things to keep in mind when working with UUIDs in Node.js. Here’s my story—and the seven lessons I learned along the way.

1. Generating UUIDs Can Be Expensive (Especially if You Do It Too Often)
At first, generating UUIDs felt like second nature. Every time I created a new document or session, I simply called uuid.v4() and moved on. Easy peasy, right? Wrong.

As the application scaled, I noticed a slight but noticeable lag during peak usage. After some profiling, I discovered that generating UUIDs repeatedly can be computationally expensive. While it might not seem like much for small projects, calling uuid.v4() thousands of times per second adds up quickly.

To mitigate this, I decided to batch-generate UUIDs whenever possible. For example, instead of generating IDs one-by-one, I pre-generated a pool of UUIDs at startup and drew from that pool as needed. This simple change shaved milliseconds off every request, which made a world of difference in a high-concurrency environment.

2. Storing UUIDs Requires More Space Than Integers
I’ll admit it—I underestimated the storage requirements of UUIDs. At first glance, they’re just strings, so how bad could it be? But after deploying the app to production, I noticed our database size growing faster than expected.

Here’s the math: A UUID is typically 36 characters long (including dashes), while an integer primary key takes up significantly less space. In fact, a 64-bit integer consumes only 8 bytes, whereas a UUID stored as a string eats up around 16-36 bytes, depending on encoding.

The solution? Store UUIDs in binary format if your database supports it. By switching to binary storage, I reduced the footprint by nearly half, making our database queries faster and more efficient.

3. Indexing UUIDs Can Slow Down Your Queries (if Done Incorrectly)
When designing the database schema, I proudly declared UUIDs as the primary keys for all tables. It felt futuristic and foolproof. But soon enough, I hit another roadblock: query performance began to degrade as the dataset expanded.

Why? Because indexing UUIDs isn’t as straightforward as integers. Unlike sequential IDs, UUIDs are random and unpredictable, which means indexes need to handle them differently. This randomness can cause index fragmentation, especially in large datasets, leading to slower lookups.
To address this, I restructured my database to use composite indexes where necessary and experimented with clustering techniques.

Additionally, I ensured proper maintenance of indexes through regular optimizations. These tweaks brought query times back under control, proving once again that even the most elegant solutions require fine-tuning.

4. Randomness Isn’t Always Your Friend
One day, while stress-testing the app, I stumbled upon an issue I hadn’t anticipated: UUID collisions weren’t impossible, though rare. While the chances of collision are astronomically low (1 in 2¹²², to be precise), the mere possibility sent shivers down my spine.

This realization forced me to rethink how I handled conflicts. Instead of assuming uniqueness, I added checks to ensure duplicate IDs were caught early. Though unlikely, being prepared saved me countless headaches later on.

5. Parsing UUIDs Can Be Surprisingly Costly
Once the app went live, I noticed occasional spikes in CPU usage during certain operations. Digging deeper, I found the culprit: parsing UUIDs into usable formats. Whether converting them to strings, comparing them, or validating their structure, these seemingly trivial tasks added up over millions of requests.

My fix? Cache parsed UUIDs wherever possible and minimize unnecessary conversions. Wherever feasible, I worked directly with binary representations rather than strings, reducing overhead significantly. It wasn’t glamorous, but it worked—and reminded me that attention to detail pays dividends in performance-critical applications.

6. Use Version 4 UUIDs for Most Cases, But Know the Alternatives
For most of my project, version 4 UUIDs (randomly generated) sufficed. However, I soon discovered that other versions exist, each with its own trade-offs:

Version 1: Based on timestamps and MAC addresses, but prone to privacy concerns.
Version 5: Derived from hashing namespaces, useful for deterministic IDs but less common in practice.

While sticking with version 4 kept things simple, knowing the alternatives helped me make informed decisions when faced with specific use cases. For instance, I used version 5 UUIDs for caching mechanisms where determinism mattered more than randomness.

7. Benchmark Before Making Assumptions
Finally, the biggest lesson I learned was this: never assume anything about performance without benchmarking. Early on, I read articles claiming UUIDs were “slow” compared to integers. But what does “slow” really mean? Without concrete numbers, I couldn’t justify replacing UUIDs altogether.

So, I rolled up my sleeves and ran benchmarks using tools like Benchmark.js. What I discovered surprised me: while UUID generation and parsing introduced minor overhead, the benefits of guaranteed uniqueness far outweighed the costs for my use case. Armed with data, I confidently stuck with UUIDs but optimized their usage wherever possible.

Conclusion: Lessons Learned
Looking back, using UUIDs in Node.js taught me valuable lessons about performance, scalability, and trade-offs. Yes, they come with challenges—higher storage costs, potential indexing issues, and computational expenses—but with careful planning, those challenges can be overcome.

If you’re considering UUIDs for your next project, remember these seven points:

Batch-generate UUIDs to reduce computational load.
Store them in binary format to save space.
Optimize indexing strategies to avoid fragmentation.
Handle edge cases like collisions, however unlikely.
Minimize parsing and conversion operations.
Explore alternative UUID versions for specialized needs.
Always benchmark before jumping to conclusions.

In the end, my real-time collaboration platform thrived thanks to UUIDs, and I gained a newfound appreciation for the nuances of working with them. If you take anything away from my journey, let it be this: don’t fear UUIDs, but respect their quirks. With the right approach, they can become a powerful ally in your Node.js projects.

And who knows? Maybe someday, you’ll write your own story about mastering UUIDs—or tell me how I got it wrong. Either way, hope you have a lovely day at the office!

Generating UUIDs with JavaScript Generators

Terfa Binda — Tue, 25 Feb 2025 12:45:24 +0000

I first heard about the term UUID in 2010 while coding with Microsoft Visual Basic, but UUIDs have been around a lot longer than that. Some developers refer to it as GUIDs. They both represent the same concept.

Globally Unique Identifier
GUID stands for Globally Unique Identifier these days developers prefer to call it UUID which means Universally Unique Identifier. These abbreviations refer to the same thing, but UUID is the term we shall be using going forward.

A UUID is a 128-bit label that is used to identify any resource or entity with a very high probability of uniqueness. A UUID is generated by following a standard or complex algorithm that combines different sources of randomness such as timestamps, MAC addresses, namespaces, names, or random numbers.

There are different flavors and formats of UUIDs. Each one depends on a specific algorithm and the representation used. The most common format is a string of 32 hexadecimal digits, separated by hyphens into five groups, such as 550e8400-e20b-a796–446655440000. The first group indicates the version of the UUID, and the last group denotes the flavor of the UUID.

Currently, there are five known versions of UUIDs and four variants defined by the RFC 4122 standard.

You may need to create a UUID in JavaScript if you want to have a unique and consistent way of identifying resources, such as files, objects, or components, across different systems or platforms. For example, if you are developing a web application that needs to store or sync data with a server or a database, you can use UUIDs as keys or identifiers for your data. This way, you can avoid conflicts or collisions with other data that may have the same name or ID. UUIDs play an indispensable role when generating random passwords, secure tokens, or unique identifiers are required.

UUIDs may be generated using different methods and algorithms or a specific library such as uuid. You can also use a specialized command line tool to generate one. Or you can write a concise JavaScript Generator function that generates a random UUID following the xxxxxxxx-xxxx-4xxx-yxxx-xxxxxxxxxxxx pattern. This is also the main objective of this writeup

What are JavaScript Generators?

Let’s now beam our searchlights on Generators. These are a special type of function object in JavaScript that are capable of returning multiple (and in some cases continuous) values on demand.

In contrast, normal functions return single values or nothing. When invoked a normal function predictably executes the same code from beginning to the point where it encounters a return statement, and either returns a specified value or nothing. For example:

function doSomething(a, b){

  let sum = a + b;
  return sum;

}

Generator functions are a little different. They are declared with a different syntax as follows:

function* doSomething(a, b){
  return 'Hello Generator function!'
}

function *doSomething(a, b){
  return 'Hello Generator function!'
}

The distinguishing element is the asterisk * operator that is appended to the end of the function keyword or prepended to the name of the function. Generator functions return generator objects not primitive values as normal functions do. Let’s see this in the code example below:

function* generatorFunction() {
    return 'Hello Generator!'
}

const generatorFn = generatorFunction();
console.log(generatorFn)

//output:
generatorFunction {<suspended>}
  __proto__: Generator
  [[GeneratorLocation]]: VM272:1
  [[GeneratorStatus]]: "suspended"
  [[GeneratorFunction]]: ƒ* generatorFunction()
  [[GeneratorReceiver]]: Window
  [[Scopes]]: Scopes[3]

The generator objects returned by Generator functions are sometimes called iterators. Iterator objects come with a next() method, a mechanism that moves the iterator cursor through a sequence of values. Therefore, the outputting code will be:

// Call the next method on the Generator object
console.log(generatorFn.next());

This will render the following output:

//output:
{value: "Hello Generator!", done: true}

What have we learned from the foregoing? We can see that the message returned by invoking next() is “Hello Generator!”, and the status of done is true. This indicates that the iterator has completed its run. From this moment the generator function’s status will change from suspended to closed. Invoking generatorFn again will give you an updated information about the current state of the generator which will be revealed as follows:

//output:
generatorFunction {<closed>}

Generator functions work better when used in combination with the yield operator. The yield operator gives generator functions the ability to pause code execution and return the current value when the next() is invoked on it. Let’s assume we create a generator function as follows:

// Create a generator function with multiple yields
    function* generatorFunction() {
        yield 'California'
        yield 'Colorado'
        yield 'Georgia'
        return 'Indiana'
    }

    const generatorFn = generatorFunction()

Therefore invoking the next() method on the generatorFn will cause the function to pause at each step while returning a value. The value of done will remain false until the final value is returned: For example:

console.log(generator.next());
console.log(generator.next());
console.log(generator.next());
console.log(generator.next());


//output:
{value: "Mercury", done: false}
{value: "Venus", done: false}
{value: "Mars", done: false}
{value: "Jupiter", done: true}

In fact it is not even necessary to use a return statement in a generator. Generators are self-aware of the last iteration and will return {value:undefined, done:true}. Every subsequent call to next() will have the same effect after a generator’s iterations are completed.

The yield operator gives Generators its powers, especially in situations where working with infinite data streams and collections is desired. We can demonstrate this use case by creating an infinite loop within a generator function, that is made to keep incrementing a number as follows:

// Define a generator function that increments by one
function* increment() {
    let i = 0
    while (true) {
      yield i++
    }
  }

  // Initiate the generator
const counter = increment();

//print in console
console.log(counter.next());
console.log(counter.next());
console.log(counter.next());
console.log(counter.next());
console.log(counter.next());

//output
{ value: 0, done: false }
{ value: 1, done: false }
{ value: 2, done: false }
{ value: 3, done: false }
{ value: 4, done: false }

The function returns a chain of values in an infinite loop while the done property remains false, thus ensuring that the increment function never halts. Even though the while(true) code block appears to be caught in an unending loop, execution is paused after each yield and resumed only when the iterator’s next method is invoked in the console.log code. The stateful value of the local i variable remains unchanged between each call and is maintained.

You are completely safe when an infinite loop with generators because it gives you the power to pause and resume execution at any time. This is the innovativeness that generators bring to JavaScript; the awesome ability to pause and resume code execution in between calls. However, you must exercise caution when using the generator in combination with the spread or for..of on an infinite data stream, which can create an uncontrollable infinite loop that could eventually cause the environment to crash.

Generating GUIDs With JavaScript Generators
We can now combine the innovative use of a generator function in JavaScript with a nifty function that can give us an endless front-end based UUID generator as follows:

function *guidGenerator() {
    while (true) {
        const uuidv4 = () => {
            // Generate a random number from 0 to 15
            function randomDigit () {
              return Math.floor (Math.random () * 16);
            }
            // Generate a random hex digit
            function randomHex () {
              return randomDigit ().toString (16);
            }
            // Generate a random segment of 4 hex digits
            function randomSegment () {
              return randomHex () + randomHex () + randomHex () + randomHex ();
            }
          // Generate a UUID following the 'xxxxxxxx-xxxx-4xxx-yxxx-xxxxxxxxxxxx' pattern
            return randomSegment () + '-' + randomSegment () + '-4' 
+ randomSegment ().substring (1, 3) + '-' + randomHex () 
+ randomSegment ().substring (1, 3) + '-' + randomSegment () 
+ randomSegment ();
        }
        yield uuidv4();
    }
}

const getGuid = guidGenerator();

console.log(getGuid.next());
console.log(getGuid.next());
console.log(getGuid.next());

This nifty generator function will yield the following output:

{ value: '4cec-6d60-490-c46-9d06f2c1', done: false }
{ value: '5c69-795f-421-a0e-82ef2cd0', done: false }
{ value: '497a-2065-4e3-bb4-d94f0dd0', done: false }

To extract the string value out of the output object you should write the following lines:

const getGuid = guidGenerator();
console.log(getGuid.next().value);
console.log(getGuid.next().value);
console.log(getGuid.next().value);

//output
bac4-3650-4af-10a-5836de95
9f71-f4f2-489-11f-965f03ef
c18f-d3cd-4a0-2c4-1458bdf4

Since UUIDs are meant to be unique, you should expect a different output on your machine.

In conclusion, generating UUIDs in JavaScript using generator functions is a straightforward process that can be accomplished by following the steps outlined in this article, you can easily create unique identifiers for your applications, ensuring data integrity and avoiding conflicts. Whether you're working on a small project or a large-scale system, UUIDs provide a reliable way to manage unique data entries.

If you found this guide on UUID generation helpful and want to explore more advanced JavaScript techniques, check out my book, Concise JavaScript: For Beginners and Advanced Learners, available on Amazon. It’s packed with practical insights to enhance your coding skills!

Thanks for reading and have happy coding session!