DEV Community: Praveen Maurya

UUID Versions Explained: Which One Should You Actually Use?

Praveen Maurya — Thu, 17 Sep 2026 18:19:37 +0000

Whether you're building APIs, databases, or distributed systems, UUIDs are everywhere. They usually look something like this::

f47ac10b-58cc-4372-a567-0e02b2c3d479

Everyone knows what they look like, but almost nobody can confidently answer the question: which UUID version should I use? UUID v1? v4? v7? What happened to v2, v3, v5, and the brand new v6, v7, v8?

The confusion is completely justified. RFC 4122 standardized the widely used UUID versions (v1, v3, v4, and v5), while v2 came from the older DCE specification. RFC 9562 (2024) later added v6, v7, and v8. Each version exists for a reason, and picking the wrong one has real consequences — especially when your UUID is going to be a primary key in a database.

This post breaks down every version, when to use it, when to avoid it, and — most importantly for database folks — which ones play nicely with indexes and which ones will silently wreck your query performance.

First: What Is a UUID, Exactly?

A UUID (Universally Unique Identifier) is a 128-bit identifier. It is usually written as 32 hexadecimal digits grouped into five sections:

xxxxxxxx-xxxx-Axxx-Bxxx-xxxxxxxxxxxx

Two of those digits are special:

A (the first digit of the third group) is the version — it tells you which algorithm produced the UUID. 1 = v1, 4 = v4, 7 = v7, and so on.
B (the first digit of the fourth group) is the variant — almost always 8, 9, a, or b. You rarely need to think about this one.

So you can identify any UUID's version at a glance. Look at that third group:

Version	Example
v1	`f47ac10b-58cc-1e2b-9e96-0800200c9a66`
v2	`79ee8720-8ff9-21f1-80f6-d73a18d6a4c2`
v3	`f47ac10b-58cc-3e2b-9e96-0800200c9a66`
v4	`f47ac10b-58cc-4e2b-8b6d-0e02b2c3d479`
v5	`f47ac10b-58cc-5e2b-8b6d-0e02b2c3d479`
v6	`f47ac10b-58cc-6e2b-9e96-0800200c9a66`
v7	`01890f3a-2a7a-7e2b-9e96-0e02b2c3d479`
v8	`f47ac10b-58cc-8e2b-9e96-0e02b2c3d479`

(Those are illustrative examples so you can see the version digit clearly.)

Version by Version

You can use this tool to generate any uuid version from here https://safedevtools.com/uuid-generator/

UUID v1 — Time-Based + MAC Address

How it works: v1 combines a 60-bit timestamp (100-nanosecond intervals since 1582), a clock sequence, and the generating machine's MAC address.

f47ac10b-58cc-1e2b-9e96-0800200c9a66
        timestamp        MAC address

Pros:

Roughly sortable in generation order — newer UUIDs tend to be bigger than older ones.
Unique without any randomness guessing game (per machine).

Cons:

Leaks information. Anyone who sees the UUID learns the machine's MAC address and an approximate creation time. That's a genuine security concern.
Only roughly sequential; the timestamp doesn't strictly increase between UUIDs from different machines.
Traditionally uses the machine's MAC address, although modern implementations often substitute a randomly generated node identifier to avoid leaking hardware information. Best for: Legacy systems that already use v1, or cases where you genuinely need time ordering and don't care about leaking machine identity. For almost everything else, prefer v7.

Database verdict: Better than v4 for indexes (values trend upward), but the information leak and imperfect ordering make it a poor default.

UUID v2 — DCE Security

How it works: This is v1 plus a POSIX UID/GID of the local user, intended for DCE (Distributed Computing Environment) security contexts.

Pros: Essentially none for general use.

Cons: It is rarely implemented — most libraries don't even ship it, and RFC 4122 itself barely covers it.

Best for: Almost nothing. If you reach for v2, stop and pick v7 instead.

Database verdict: Treat as unavailable. You'll struggle to even find a library that generates it.

UUID v3 — Name-Based, MD5

How it works: v3 derives the UUID deterministically from a namespace plus a name, hashed with MD5. Same namespace + same name = same UUID, every single time.

namespace: DNS  →  6ba7b810-9dad-11d1-80b4-00c04fd430c8
name:      "example.com"
result:    v3 UUID (always the same value)

Pros:

Deterministic — no randomness, no storage needed to look up an existing ID.
Great for generating a stable identifier from something you already have (a URL, an email, a username).

Cons:

MD5 is weak by modern standards.
Not unique per row by itself — if two rows map to the same name, they get the same UUID.

Best for: Situations where you want the same entity to always resolve to the same ID across systems without a lookup table.

Database verdict: Fine as a stable foreign key if your "name" is genuinely unique, but it does not help with ordering or index performance.

UUID v4 — Random

How it works: v4 just generates 122 random bits (the other 6 are fixed version/variant bits). That's it.

f47ac10b-58cc-4e2b-8b6d-0e02b2c3d479

Pros:

Secure — cryptographically strong randomness means nothing about your machine, time, or user is exposed.
Trivially simple to generate; it's the default in nearly every language and library.
Collision probability is effectively zero (122 random bits).

Cons:

Completely random order. This is the big one for databases (see below).
Not sortable, not predictable, not compressible.

Best for: Public-facing identifiers, security tokens, event IDs, and any case where you want an opaque identifier with zero information leakage. It is the classic "default" for a reason.

Database verdict: ⚠️ The worst choice for large table indexes. Random values inserted into a B-tree index cause page splits — every insert lands at a random position, forcing the database to reorder pages. With millions of rows this can cause dramatic index fragmentation, slower writes, and poor cache locality.

UUID v5 — Name-Based, SHA-1

How it works: Identical concept to v3, but uses the stronger SHA-1 hash instead of MD5.

namespace: URL  →  6ba7b811-9dad-11d1-80b4-00c04fd430c8
name:      "https://example.com/posts/42"
result:    v5 UUID (always the same value)

Pros:

Deterministic, like v3, but with a better hash.
Stable across systems.

Cons:

Same determinism caveat: identical inputs → identical UUID.
SHA-1 is also showing its age, though it's fine for this non-security use.

Best for: Exactly the same use cases as v3 — stable IDs derived from names. Prefer v5 over v3 when your library supports both.

Database verdict: Same as v3 — acceptable for stable keys, useless for ordering.

UUID v6 — Time-Ordered (Reordered v1)

How it works: v6 takes the v1 timestamp bits and reorders them so the most significant bits come first. This makes the UUIDs actually sortable in time order, fixing v1's biggest weakness.

Pros:

Truly sortable — lexicographic order matches time order.
Keeps the information content of v1.

Cons:

Like v1, it can reveal timestamp information and may expose the node identifier if a real MAC address is used.
Much newer and less widely supported than v7.

Best for: Systems that want time-ordered IDs but can't move to v7 yet.

Database verdict: Good for indexes — values insert in near-sequential order, minimizing page splits. But v7 is generally the better modern pick.

UUID v7 — Time-Ordered, Unix Timestamp (Recommended)

How it works: v7 puts a 48-bit Unix timestamp (milliseconds) in the high bits and fills the rest with random data.

01890f3a-2a7a-7e2b-9e96-0e02b2c3d479
↑ millisecond timestamp ↑  ↑ random bits

Pros:

Sortable by creation time → plays beautifully with database indexes.
Random tail bits → high entropy, low collision risk.
Does not expose machine identity, though it does reveal the approximate creation time.
Standardized in 2024 (RFC 9562) and now the recommended choice for new systems.

Cons:

Newer; some older libraries and databases don't support it yet (though support is spreading fast).

Best for: Primary keys, database rows, and anything that lives in an indexed column. This is the modern default for new applications.

Database verdict: ✅ Excellent. Sequential inserts mean B-tree indexes stay compact, writes are fast, and range queries by time become trivial.

UUID v8 — Custom / Experimental

How it works: v8 is the "bring your own" version. It reserves the version digit for custom, vendor-defined layouts — you decide what the bits mean.

Pros:

Maximum flexibility for proprietary schemes.

Cons:

Zero portability — only your system understands the format.

Best for: Internal, single-vendor systems with very specific needs. Not something most projects should touch.

Database verdict: Entirely depends on how you design the layout. If you design it to be sortable, it can index well; otherwise, it's a coin flip.

The Database / Indexing Cheat Sheet

If you're choosing a UUID for a primary key or an indexed column, this is the table that matters:

Version	Sortable / Index-friendly	Information leak	Typical use
v1	Roughly	Yes (time + MAC)	Legacy time-based systems
v2	No	Yes	Rarely used (DCE)
v3	No	No (deterministic)	Stable ID from a name (MD5)
v4	No	No	Opaque IDs, tokens, default
v5	No	No (deterministic)	Stable ID from a name (SHA-1)
v6	Yes	Yes (time + MAC)	Sortable legacy replacement
v7	Yes	Timestamp only	New databases / primary keys
v8	Custom	Custom	Vendor-specific schemes

The short rules of thumb

New system with a database? → v7. Sequential inserts, great indexes, no privacy leak.
Opaque, non-database identifier (API key, event ID, public token)? → v4. Random and private.
Same entity must map to the same ID everywhere (e.g., a user's ID derived from their email across services)? → v5 (or v3 if you're stuck on old libraries).
You already have v1 in production? → v6 is the drop-in sortable upgrade.

Why random UUIDs (v4) hurt database performance

A typical B-tree index stores keys in sorted order. When you insert a random value:

The database has to find the middle of the tree, split pages, and shuffle data.
Repeated random inserts cause index fragmentation and bloated pages.
Write throughput degrades, and the index becomes much bigger than it needs to be.
Cached index pages are used inefficiently because consecutive inserts touch random pages.

This is the single most common UUID mistake in production. It doesn't matter at 1,000 rows — it absolutely matters at 10 million.

If you need a UUID that also tells you when it was created, v7 gives you time ordering and database friendliness without the security downsides of v1/v6.

A Note on Alternatives

UUIDs aren't the only option. You'll also hear about:

ULID — a v7-style "sortable, readable ID" with a timestamp prefix.
Snowflake / Twitter Snowflake IDs — 64-bit time+worker IDs, great for high-scale distributed systems.
NanoID — smaller URL-safe strings; friendly but not natively sorted or native to most databases.
Sequential integers / IDENTITY columns — simplest, best index performance, but globally guessable and hard to merge across systems.

The great thing about UUID v7 is that it gives you most of the benefits of ULID/Snowflake (time ordering + compactness + index-friendliness) while staying within the standard, universally supported UUID format.

TL;DR

v4 — random, private, the classic default; bad for database indexes at scale.
v1 / v6 — time-based; sortable-ish, but leak MAC address + time.
v3 / v5 — deterministic from a name; use for stable IDs, not for ordering.
v7 — timestamp + random; the modern choice for primary keys and indexed columns.
v8 — custom; only for vendor-specific schemes.

When in doubt, reach for v7 if it will live in a database, and v4 if it will live in the world.

You can generate uuid from V1 to V8 from here:

https://safedevtools.com/uuid-generator/

Happy identifying. 🆔

Building with Local LLMs: An Engineer's Approach to AI-Assisted Development

Praveen Maurya — Sat, 18 Jul 2026 20:04:50 +0000

I didn't build SafeDevTools by asking AI to "build me a website." I built it by treating a local LLM like a junior engineer who never gets tired of writing boilerplate.

A few weeks ago, I challenged myself with a simple experiment:
Could I build a production-ready product using nothing but a local LLM?

No Claude Code.
No Cursor.
No API credits.
No cloud AI.

Just: VS Code, Ollama (Gemma 4:12B), my MacBook M4 Pro, and a lot of software engineering experience.

The result was SafeDevTools — a collection of privacy-first developer utilities that run entirely in the browser.
👉 https://safedevtools.com

I wrote about the technical "How-To" in my previous article:
How I Built a Premium Developer Tools Website Using Only a Local LLM (Gemma 4:12B + Ollama + VS Code)

This article is about the mental shift. It’s about how I changed the way I think about software development after building this product.

The Biggest Misconception About AI Coding

Every week, social media is flooded with:

"AI built an entire SaaS in 24 hours."
"AI replaces software engineers."

These videos are entertaining, but they miss the point. After spending weeks building a real product with a local model, I realized that the value of AI isn't replacing the engineer.

The value of AI is replacing repetitive engineering work.

That is a massive distinction. One is about replacement; the other is about leverage.

The Evolution of a Software Engineer

Think about your first few years as a developer. Most of your day was spent asking:

"How do I write this loop?"
"Why is my CSS broken?"
"How do I call this API?"

Back then, writing code was the job.

Fast forward a few years. Your role has shifted. You spend your time thinking about:

Architecture & Scalability
Security & Maintainability
Developer Experience (DX)
Deployment Strategy

The irony? Despite becoming responsible for high-level system design, you are still often tasked with writing hundreds of lines of repetitive "grunt work."

The CRUD endpoints. The validation logic. The DTOs. The unit tests. The accessibility attributes.

The code isn't always difficult—it’s just repetitive.

The Realization: Repeating Yourself

SafeDevTools consists of multiple utilities. Every tool follows the same design language:

Responsive layout & Dark mode
Accessibility (A11y) standards
SEO Metadata
JavaScript validation
Consistent styling & Copy buttons

I could have written every page manually. But by the third or fourth tool, I realized something: I wasn't solving engineering problems anymore; I was repeating myself.

That is where the local LLM became my superpower. Not because it "invented" the tools, but because it executed the repetition with perfect consistency.

The Architect vs. The Builder

A key takeaway from this project was learning to separate Intent from Execution.

I found that the most effective workflow is for the human to remain the Architect (Vision, Design, and Standards) while the AI serves as the Builder (Repetitive Tasks, Boilerplate, and Testing).

🏗️ My Responsibilities (The Architect)

Product Vision & UX Decisions
System Architecture & Folder Structure
Coding Standards & Design Systems
Security & Performance Review

🛠️ The Model's Responsibilities (The Builder)

Generating implementation details
Writing boilerplate and repetitive logic
Drafting documentation
Refactoring for readability
Generating unit tests

The mindset shift: The model isn't making product decisions. It is implementing my decisions.

How to Stop Asking AI to "Build Products"

If you want better results, stop using "God-mode" prompts like:
"Build me a dashboard."

Instead, treat the LLM as an implementation engine. Use specific, measurable engineering tasks:

"Generate this Go repository implementation based on these interfaces."
"Build this HTML page following our existing design system."
"Add accessibility improvements without changing the layout."
"Refactor this function while keeping the public API identical."

Pro Tip: These are smaller, discrete tasks. They are exactly where smaller local models perform surprisingly well.

The "Small Context" Secret

Early on, I made the mistake of feeding the model my entire project folder. The results were messy and hallucinatory.

I learned that instead of increasing the prompt size, I needed to reduce the problem scope. Give the model:

One component.
One interface.
One objective.

The smaller the context, the higher the quality of the output. This forced me to be a better architect because I had to define the boundaries more clearly before asking for code.

Your Documentation IS Your Superpower

This was my most unexpected "Aha!" moment. The secret wasn't a complex prompt; it was Standard Operating Procedures (SOPs).

I started documenting everything:

Project structure rules
UI/Naming conventions
Accessibility requirements
JavaScript patterns

Eventually, this evolved into a reusable set of instructions that acted as the "Source of Truth." Once the model understood my project's rules, every new tool became easier to generate.

The documentation became more valuable than any prompt. The AI stopped guessing and started following orders.

Treat Your Local LLM Like a Junior Engineer

This is the ultimate mental model.

Imagine a talented junior developer joins your team today. You wouldn't tell them: "Build our entire platform." They would be overwhelmed and fail.

Instead, you would give them:

Context on how the project works.
The coding standards.
The architectural roadmap.

Then, you review their work.

That is exactly how I use a local LLM. It doesn't replace me; it extends my capacity to build.

Why Local? (The Workflow)

People ask why I don't just use GPT-4 or Claude for this. It’s not about replacing those models; it’s about Workflow.

Privacy: My source code never leaves my machine.
Zero Friction: No API keys, no usage limits, no "Thinking..." delays.
Iteration: I can experiment 100 times without worrying about token costs.
Offline Power: It works anywhere.

The local model is simply another tool in my stack, sitting alongside Docker, Git, and PostgreSQL.

Final Thoughts: AI Didn't Build SafeDevTools.

I need to be clear: AI did not build SafeDevTools.

Human designed the architecture.
Human defined the UX.
Human established the privacy-first philosophy.
Human chose the browser-only execution model.

The implementation simply became dramatically faster because I had an assistant that never complains about writing repetitive code.

The future isn't about "Autonomous Agents" replacing engineers. It’s about experienced developers who know how to combine their Engineering Intuition with AI-Assisted Implementation.

Experience tells you what should be built. AI helps you build it faster.

Stop asking AI to replace you. Start using it to unburden you.

Resources

🌐 SafeDevTools

https://safedevtools.com

📝 The Technical Deep Dive

How I Built SafeDevTools Using a Local LLM

How I Built a Premium Developer Tools Website Using Only a Local LLM (Gemma 4:12B + Ollama + VS Code)

Praveen Maurya — Thu, 25 Jun 2026 19:19:16 +0000

Over the past few weeks, I’ve been experimenting with local language models. Like a lot of developers, I’ve used cloud AI assistants quite a bit, but I kept asking myself one simple question:

Can a local LLM actually help me build a real, production-ready project?

So I decided to find out for myself.

I challenged myself to build an entire developer tools website using only a local AI model running on my own machine. No cloud assistant. No external API. Just my laptop, VS Code, Ollama, and Gemma 4:12B.

The result is SafeDevTools — a collection of browser-based developer utilities with a modern glassmorphic interface, strong SEO foundations, and a privacy-first architecture. You can check it out here: https://safedevtools.com

The site includes tools like:

JSON formatter
JWT parser
Base64 encoder/decoder
Hash generator
CSV to JSON Converter
URL encoder/decoder
Timestamp converter
JSON <-> YAML converter

Honestly, the biggest surprise wasn’t the model itself.

It was how much of a difference a well-written Copilot Skill made.

The Stack

I kept the stack intentionally simple:

VS Code Copilot Agent
Ollama
Gemma 4:12B
HTML
CSS
Vanilla JavaScript

Everything running on Macbook M4 Pro 24GB RAM

That’s it.

No React.

No Angular.

No backend.

No build tools.

No server-side rendering.

And that simplicity mattered more than I expected. It meant the local model could focus on generating clean frontend code instead of getting distracted by framework complexity or project scaffolding.

Running everything on a MacBook M4 Pro with 24GB RAM was also a big advantage. It gave me enough headroom to work comfortably with a local model while keeping the entire workflow fast, private, and fully under my control.

The Biggest Problem

At the beginning, Gemma’s output was a bit all over the place.

Sometimes the layout looked great.

Sometimes the HTML structure changed for no obvious reason.

Some tools used different colors.

Some pages forgot SEO metadata.

Others skipped accessibility or responsive behavior.

The code worked, but it didn’t feel like one project. It felt like a bunch of separate pages written by different people.

That’s fine for a quick prototype, but it doesn’t really work when you’re trying to build something bigger and more consistent.

The Turning Point: Writing a Copilot Skill

Instead of writing longer prompts every time, I created a detailed VS Code Copilot Skill.

That changed everything.

Rather than telling the model what to build each time, I taught it how every tool should be built.

The skill defines things like:

Project architecture
Folder structure
UI design system
Color palette
Glassmorphism styling
SEO requirements
Accessibility standards
Performance expectations
JavaScript architecture
Privacy messaging
Advertisement placeholders
Responsive layouts
Error handling

So every new tool starts from the same standards.

Once that skill was in place, the consistency improved a lot. The pages started to feel like they belonged to the same product instead of being stitched together from random outputs.

That was the real breakthrough.

Instead of constantly correcting the model, I was giving it a reusable engineering blueprint.

Why Local AI Worked Surprisingly Well

Gemma 4:12B isn’t the biggest model out there.

But once the skill encoded the project’s standards, the model didn’t have to invent everything from scratch anymore. It just followed the blueprint.

That made a huge difference.

It reduced weird output, improved consistency, and produced much cleaner code than I was getting from loose, ad-hoc prompts.

If I had to sum up what I learned in one sentence, it would be this:

Smaller models become much more useful when you give them better instructions instead of just bigger prompts.

That really stuck with me.

A Privacy-First Website

One of the main goals for SafeDevTools was making sure every tool runs entirely inside the browser.

Whether you’re:

decoding a JWT
formatting JSON
generating Hash
encoding Base64
converting csv to json
converting timestamps
converting json <-> yaml
encoding or decoding URLs

your input data never leaves your computer.

There are:

no API calls
no uploads
no server-side processing

Everything happens locally using browser APIs and JavaScript.

That was important to me because a lot of developer tools deal with sensitive data. Sometimes you’re pasting tokens, logs, config files, or snippets you really don’t want sent anywhere. With SafeDevTools, that concern just goes away.

It also makes the site feel fast and lightweight, which is always a nice bonus.

Why I Chose Glassmorphism

I didn’t want another plain developer tools website.

A lot of utility sites are useful, but they look a little dated or too functional. I wanted SafeDevTools to feel more like a premium desktop app than a basic web page.

So I leaned into a glassmorphic design style with:

dark slate backgrounds
layered glass surfaces
subtle blur effects
smooth hover animations
modern typography
carefully chosen accent colors

The goal was to make the site feel polished without making it flashy for the sake of it.

And I think that matters more than people admit. Good developer experience isn’t only about whether a tool works. It’s also about whether you actually enjoy using it.

When a tool looks and feels premium, it changes the whole experience.

Simplicity Wins

Every tool is completely self-contained.

Each one lives in its own folder with only three files:

tool-name/

├── index.html
├── style.css
└── script.js

That structure keeps things clean and easy to maintain.

The root project stays minimal too, with just the homepage and the global project files. Nothing feels bloated, and adding a new tool doesn’t turn into a messy refactor every time.

That simplicity ended up being one of the best decisions I made. It makes the project easier to scale, easier to debug, and easier to hand off to the model without confusing it.

What I Learned

The biggest lesson from this project wasn’t really about AI.

It was about software engineering.

AI gives much better results when you give it clear architecture, coding standards, and reusable constraints. That sounds obvious, but I think a lot of people still treat prompts like magic spells instead of treating them like part of the engineering process.

The Copilot Skill became more valuable than any single prompt because it captured the project’s decisions in one place.

Instead of repeating myself over and over, I encoded my preferences once and reused them across every new feature.

That made the whole workflow feel calmer, faster, and much more predictable.

Final Thoughts

Local LLMs are often compared to much larger cloud models, and I get why. But after building this project, I think that comparison misses the point.

A well-instructed local model can be a really solid development partner for structured engineering work.

With the right architecture, reusable skills, and clear project standards, even a 12B parameter model can help build polished, production-ready applications.

For me, this experiment was never about replacing cloud AI.

It was about proving that thoughtful software engineering, combined with local AI, can produce something genuinely useful.

And honestly, seeing SafeDevTools come together — fully offline, privacy-first, and polished enough to feel premium — was more satisfying than I expected.

If you want to see the result, here it is again: https://safedevtools.com