FOSDEM 2025 was held in Brussels on February 1–2, 2025. The Free and Open Source Software Developers’ European Meeting draws over 8,000 attendees and features devrooms across dozens of technology domains. The databases devroom and the PostgreSQL developer room both featured UUID-related content.
PostgreSQL Devroom — UUID v7 Implementation Review
The PostgreSQL devroom hosted a technical session reviewing the internal implementation of uuidv7() scheduled for PostgreSQL 18. The session covered:
- The timestamp extraction algorithm: read
clock_gettime(CLOCK_REALTIME)in the backend, convert to Unix milliseconds, pack into the high 48 bits - The random bit generation: uses PostgreSQL’s internal CSPRNG (
pg_strong_random), the same source used bygen_random_uuid() - The monotonic counter: PostgreSQL 18’s implementation does not include a per-session monotonic counter by default — rapid successive calls within the same millisecond produce UUIDs with equal timestamps and independent random bits
The session noted that the lack of a monotonic counter is consistent with RFC 9562’s optional treatment of Method 1. For applications that require within-millisecond ordering, application-layer generation with a library that implements a counter (like the uuid npm package) is recommended.
MariaDB and MySQL Status
A cross-database session compared UUID v7 support across the major open source relational databases:
| Database | Native UUID v7 | Status |
|---|---|---|
| PostgreSQL 18 | uuidv7() | ✓ Shipping |
| MariaDB 11.7+ | Planned | In progress — MDEV-26452 |
| MySQL 9.x | Planned | In roadmap |
| SQLite | No | Use application layer |
For MariaDB and MySQL deployments, the recommended pattern remains application-layer generation with BINARY(16) storage:
-- MariaDB / MySQL
CREATE TABLE orders (
id BINARY(16) PRIMARY KEY,
status VARCHAR(50) NOT NULL
);
INSERT INTO orders (id, status)
VALUES (UUID_TO_BIN(?, 1), 'pending');
-- The second argument `1` swaps byte groups for better index locality
Open Source ORM Sessions
Talks on SQLAlchemy and Django ORM covered the ORM-level changes needed to take advantage of PostgreSQL 18’s native uuidv7():
SQLAlchemy 2.x:
from sqlalchemy import Column, text
from sqlalchemy.dialects.postgresql import UUID
class Order(Base):
__tablename__ = "orders"
id = Column(UUID(as_uuid=True), primary_key=True,
server_default=text("uuidv7()"))
server_default=text("uuidv7()") tells SQLAlchemy to let PostgreSQL generate the value, ensuring every insert — including raw SQL — gets a UUID v7.
Extension Ecosystem
Talks also covered the pg_uuidv7 extension as a bridge for PostgreSQL 14–17 users who cannot yet upgrade to PostgreSQL 18. The extension provides uuid_generate_v7() with identical semantics to the upcoming built-in.
Related Open Source Resources
- FOSDEM 2025 talk recordings
- PostgreSQL 18 UUID functions documentation
- MariaDB UUID v7 JIRA ticket
- pg_uuidv7 extension for PostgreSQL 14–17
- MySQL UUID_TO_BIN documentation
- RFC 9562 — UUID v7 specification
Frequently asked questions
Does PostgreSQL 18 uuidv7() include a monotonic counter?
No. PostgreSQL 18's built-in uuidv7() does not implement a per-session monotonic counter by default — rapid successive calls within the same millisecond produce UUIDs with equal timestamps and independent random bits. This is consistent with RFC 9562's optional treatment of Method 1. For strict within-millisecond ordering, use application-layer generation with a library that implements a counter.
Does PostgreSQL 18 support UUID v7 natively?
Yes. PostgreSQL 18 ships a built-in uuidv7() function that generates RFC 9562-compliant UUID v7 values directly in SQL — no extensions or application-level generation required. The values store in the existing uuid column type unchanged.
Do UUIDs hurt database index performance?
UUID v4 does — its randomness causes every insert to land at a different leaf page, leading to page splits and poor cache locality. UUID v7 embeds a millisecond timestamp so consecutive inserts cluster together, behaving like an auto-increment integer for B-tree purposes.
Does MariaDB support UUID v7 natively?
MariaDB 11.7+ added UUID() improvements and is tracking UUID v7 support. As of 2025, the recommended approach for MariaDB is application-layer generation using a library, storing as BINARY(16) with UUID_TO_BIN() / BIN_TO_UUID(). Follow the MariaDB JIRA ticket MDEV-26452 for the native UUID v7 implementation status.
Is UUID v7 supported in MySQL 8.x?
MySQL 8.0 includes UUID() (v1) and UUID_TO_BIN() with a swap flag for time-ordering, but no native uuid_generate_v7(). MySQL 9.x is expected to add UUID v7 support. In the meantime, generate UUID v7 values at the application layer and store as BINARY(16). The MySQL UUID_TO_BIN documentation covers the swap-flag workaround.