Postgres PL/pgSQL function for UUID v7 and a bonus custom UUID v8 to support microsecond precision as well. Read more here: https://datatracker.ietf.org/doc/draft-peabody-dispatch-new-uuid-format/

A_UUID_v7_for_Postgres.sql

-- Based off IETF draft, https://datatracker.ietf.org/doc/draft-peabody-dispatch-new-uuid-format/

create or replace function uuid_generate_v7()
returns uuid
as $$
begin
  -- use random v4 uuid as starting point (which has the same variant we need)
  -- then overlay timestamp
  -- then set version 7 by flipping the 2 and 1 bit in the version 4 string
  return encode(
    set_bit(
      set_bit(
        overlay(uuid_send(gen_random_uuid())
                placing substring(int8send(floor(extract(epoch from clock_timestamp()) * 1000)::bigint) from 3)
                from 1 for 6
        ),
        52, 1
      ),
      53, 1
    ),
    'hex')::uuid;
end
$$
language plpgsql
volatile;

-- Generate a custom UUID v8 with microsecond precision
create or replace function uuid_generate_v8()
returns uuid
as $$
declare
  timestamp    timestamptz;
  microseconds int;
begin
  timestamp    = clock_timestamp();
  microseconds = (cast(extract(microseconds from timestamp)::int - (floor(extract(milliseconds from timestamp))::int * 1000) as double precision) * 4.096)::int;

  -- use random v4 uuid as starting point (which has the same variant we need)
  -- then overlay timestamp
  -- then set version 8 and add microseconds
  return encode(
    set_byte(
      set_byte(
        overlay(uuid_send(gen_random_uuid())
                placing substring(int8send(floor(extract(epoch from timestamp) * 1000)::bigint) from 3)
                from 1 for 6
        ),
        6, (b'1000' || (microseconds >> 8)::bit(4))::bit(8)::int
      ),
      7, microseconds::bit(8)::int
    ),
    'hex')::uuid;
end
$$
language plpgsql
volatile;

CONTRIBUTORS.txt

PERFORMANCE: Move from pgcrypto to built-in gen_random_uuid():
  Curtis Summers (https://github.com/csummers)

PERFORMANCE: Use set_bit to upgrade v4 to v7, not set_byte:
PERFORMANCE: Reduce local variable use while still being maintainable
  Rolf Timmermans (https://github.com/rolftimmermans)

LICENSE.txt

Copyright 2023 Kyle Hubert <kjmph@users.noreply.github.com> (https://github.com/kjmph)

Permission is hereby granted, free of charge, to any person obtaining a copy of this software and associated documentation files (the “Software”), to deal in the Software without restriction, including without limitation the rights to use, copy, modify, merge, publish, distribute, sublicense, and/or sell copies of the Software, and to permit persons to whom the Software is furnished to do so, subject to the following conditions:

The above copyright notice and this permission notice shall be included in all copies or substantial portions of the Software.

THE SOFTWARE IS PROVIDED “AS IS”, WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.

The given uuidv7 implementations here are not sorted in my tests. Isn't uuidv7 supposed to be sorted?
Simply running following query and checking "generate_series" integer column reveals it.

select uuid_generate_v7(), generate_series from generate_series(1,200) order by uuid_generate_v7 asc

On the other hand the function from this gist works correct.

@ardabeyazoglu If you need that level of granularity you should use UUIDv8, which has microsecond precision. UUIDv7 uses milliseconds only. The functions given here easily generate 200 UUIDs within the same millisecond, which will cause UUIDv7s to be in random order with respect to each other.

@rolftimmermans I see. However, the one provided in gist i sent fulfils that level of granularity. It gives me 500 rows instantly and sorted. But, there is a slight performance drop comparing to this one.

@ardabeyazoglu I guess the function in your link does not implement UUIDv7 correctly (to the extent we can call any implementation of a draft RFC "correct"). There is an implementation of uuid_generate_v8() given in this gist. I suggest using that; it's fast and has microsecond precision.

Edit: Seems like the draft RFC is changing the level of precision allowed in UUIDv7: https://www.ietf.org/archive/id/draft-ietf-uuidrev-rfc4122bis-14.html#name-uuid-version-7

Hello @ardabeyazoglu, it is a bit of a subtle answer. Earlier drafts of UUIDv7 contained sub-second precision bits in the format, that an implementation MAY use. UUIDv8 was for all custom usage that was implementation controlled. Current versions of the draft made UUIDv7 only for millisecond precision, and all sub-millisecond precision was moved to UUIDv8 for custom formats. The implementation attached to this draft for UUIDv7 conforms to the current drafts, while the UUIDv8 in this gist conforms to old UUIDv7 with microsecond precision.

The gist you linked to was an old UUIDv7 implementation with microsecond precision. If you want to compare apples to apples, please compare uuid_generate_v8 in this gist to the other implementation for performance analysis.

Note, uuid_generate_v7 in this gist is sorted in your example query. It is generating that many UUIDs per millisecond that they look unordered in the test query. As Rolf indicated.

Thanks @rolftimmermans for answering these questions, thought I would provide more color if this helpful.

Thanks for detailed clarification @kjmph, I also saw the difference after reading the codes carefully.