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 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:

DatabaseNative UUID v7Status
PostgreSQL 18uuidv7()✓ Shipping
MariaDB 11.7+PlannedIn progress — MDEV-26452
MySQL 9.xPlannedIn roadmap
SQLiteNoUse 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.

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.