by Vinicius Negrisolo on October 28, 2025

PostgreSQL 18 dropped last month with a bunch of exciting updates. While the performance improvements are always welcome, there's one developer-friendly feature that deserves the spotlight: native support for UUIDv7. This new format might change how model your database.

I avoid using sequential IDs for primary keys because they often end up in URLs and APIs. Exposing sequential IDs opens your application to sequential ID attacks (also known as enumeration attacks), where malicious actors can easily guess valid IDs and find out information you don't not want to turn public, like the number of users or orders you have in the database. Or in case your app misses proper authorization in a few endpoints they can access resources they shouldn't. I am all for making the app more secure so that's why I've been using UUIDv4 for quite some time already.

I know what you're thinking: random long values like UUIDv4 aren't ideal for URLs. And you're right - they're fine for internal URLs and APIs, but if you need better URLs for SEO, you'll want to implement slugs and possibly redirects when URLs change. Still, it's better to take that extra step than to compromise security with sequential integers.

UUIDv4 generates completely random identifiers like e6b5a54f-ff66-4151-88f2-e5e2bed0e84e. They're secure and unpredictable, but they're also very random. This randomness can hurt database performance because new rows get scattered across index pages instead of being added sequentially.

UUIDv7 is different. It generates similar-looking random values, but with a crucial twist: the first portion encodes a timestamp from when the row was created. Let's see this in action:

CREATE TABLE users (
  id uuid DEFAULT uuidv7() PRIMARY KEY,
  email VARCHAR(100) UNIQUE NOT NULL,
  created_at TIMESTAMP WITH TIME ZONE DEFAULT CURRENT_TIMESTAMP NOT NULL
);

INSERT INTO users (email) VALUES ('darth@example.com');
INSERT INTO users (email) VALUES ('luke@example.com');
INSERT INTO users (email) VALUES ('anakin@example.com');
INSERT INTO users (email) VALUES ('princess@example.com');
INSERT INTO users (email) VALUES ('han@example.com');

SELECT * FROM users ORDER BY id DESC;

Here's the response:

PostgreSQL 18 now includes the uuidv7() function out of the box. I ran each insert statement roughly one second apart. Notice how the IDs naturally sort in chronological order?

The structure breaks down like this:

0199e46c-4b68-765f-ad72-d388d2e2ef22

0199e46c     => Timestamp (milliseconds)
4b68         => Timestamp (milliseconds continued)
7            => UUID version (always 7)
65f          => Sub-millisecond precision / Random
a            => Variant + Random
d72          => Random
d388d2e2ef22 => Random

1. Chronological sorting: Sort by ID and get results in time order automatically — no need for a separate created_at column with an index.

2. Better index performance: Unlike UUIDv4's random scatter, UUIDv7's time-based prefix means consecutive inserts land on the same index pages, reducing fragmentation and improving performance.

3. Collision resistance: The random bits ensure that even if multiple rows are created in the same millisecond, they'll still have unique IDs.

4. Security maintained: The IDs are still non-sequential and unpredictable enough to prevent enumeration attacks.

If you're starting a new project or planning a migration, UUIDv7 gives you the best of both worlds: the security of random UUIDs with the performance characteristics of sequential IDs.

If you want to know more here are the release notes for PostgreSQL 18.

Whether you're migrating to PostgreSQL 18, optimizing your database schema, or building modern web and mobile applications, we're here to help. At Hashrocket, we specialize in PostgreSQL and other databases, along with Elixir, Phoenix, Ruby on Rails, React, and React Native. Get in touch and let's talk about how we can help you build better software.