PostgreSQL 18

UUID v7 in PostgreSQL

PostgreSQL 18 can create a version 7 UUID in SQL. Earlier versions do not have uuidv7(). The generator under the notes uses the same browser layout as the rest of this site.

Generate UUIDs

Version

Use a whole number from 1 to 20.

Generation uses crypto.getRandomValues in this browser. Results are not uploaded. A new batch replaces the list.

Results 0

Choose a version and a count, then generate.

    uuidv7() takes an optional interval shift. The shifted timestamp still has to fit the 48-bit millisecond field, roughly from 1970 through year 10889. An infinite interval is rejected.

    Inside one backend, PostgreSQL 18 uses part of rand_a as a sub-millisecond fraction so values it creates keep moving forward even when the clock does not. uuid_extract_timestamp() does not return that fraction. It returns the millisecond field as timestamptz.

    SQL

    -- PostgreSQL 18 or newer. uuidv7() is not in PostgreSQL 17.
    SELECT uuidv7();
    SELECT uuid_extract_version(uuidv7());
    SELECT uuid_extract_timestamp(uuidv7());
    
    CREATE TABLE events (
      id uuid PRIMARY KEY DEFAULT uuidv7(),
      note text NOT NULL
    );

    Questions

    Which versions have uuidv7()?

    PostgreSQL 18 added uuidv7(). PostgreSQL 17 and earlier do not have this function. gen_random_uuid() is version 4 and has been available in core since PostgreSQL 13.

    What does uuid_extract_timestamp return for v7?

    It reads the 48-bit millisecond field and returns timestamptz. It returns null when the value is not the RFC variant or is not a version with a supported timestamp. It does not reconstruct the sub-millisecond fraction that PostgreSQL stores in rand_a.

    Will a v7 primary key always make inserts faster?

    A time-ordered key often lands toward one side of a B-tree, unlike a fully random v4 key. The effect depends on the table, the index, and the workload. It is not a promise of faster queries.