--- title: PostgreSQL 18: 23x Faster Inserts With UUID V7 | daily.dev description: A production migration from UUID v1/v4 to UUID v7 primary keys on PostgreSQL 18.4 delivered up to 23x faster multi-row insert performance on a heavily-queried,... canonical: https://daily.dev/posts/postgresql-18-23x-faster-inserts-with-uuid-v7-nc2q5uwx2 twitter:card: summary_large_image twitter:site: @dailydotdev og:type: website og:site_name: daily.dev og:title: PostgreSQL 18: 23x Faster Inserts With UUID V7 | daily.dev og:description: A production migration from UUID v1/v4 to UUID v7 primary keys on PostgreSQL 18.4 delivered up to 23x faster multi-row insert performance on a heavily-queried,... og:url: https://daily.dev/posts/postgresql-18-23x-faster-inserts-with-uuid-v7-nc2q5uwx2 og:image: https://api.daily.dev/og/posts/nC2Q5UWx2.png og:image:alt: PostgreSQL 18: 23x Faster Inserts With UUID V7 og:image:width: 1200 og:image:height: 630 og:locale: en --- > ## Documentation Index > Fetch the complete documentation index at: https://daily.dev/llms.txt > Use this file to discover all available pages before exploring further. # PostgreSQL 18: 23x Faster Inserts With UUID V7 **[Planet PostgreSQL](https://daily.dev/sources/planet-postgresql)** · 9 min read · 19 upvotes · 1 comments ## Summary A production migration from UUID v1/v4 to UUID v7 primary keys on PostgreSQL 18.4 delivered up to 23x faster multi-row insert performance on a heavily-queried, billion-row table. The speedup comes from v7's monotonically increasing timestamp-based values keeping recently inserted b-tree index pages hot in the buffer cache, reducing page splits, WAL, and IO. The write-up details the real-world challenge of changing a column default via `ALTER TABLE`, which requires an access-exclusive lock blocking all reads and writes, and walks through progressively more sophisticated mitigation: short lock/statement timeouts with manual retries, a PL/pgSQL loop with jittered backoff for the busiest table, and a fallback plan to actively cancel lock-holding queries. It closes by noting UUID v7's downside: the embedded timestamp leaks record creation time, unlike v4. ## Full article daily.dev links to this article rather than hosting it. Read it at the original source: ## Questions this post answers ### How much faster are inserts after switching from UUID v4 to UUID v7 primary keys in PostgreSQL 18? Insert performance improved dramatically after switching to UUID v7 primary keys in PostgreSQL 18.4, with the largest observed gain being a 23x reduction in average insert execution time, from 0.7ms down to 0.03ms, on a table receiving 12,000 insert calls per minute with billions of rows. Other tables saw 6x, 8x, 9x, and 20x speedups, driven by v7's monotonically increasing values keeping b-tree index pages hot in the buffer cache. _daily.dev surfaces real-world performance benchmarks like this for engineers weighing a UUID v7 migration._ ### Why does switching a column default to uuidv7() in PostgreSQL require downtime or careful handling? Running ALTER TABLE ALTER COLUMN to change a default to uuidv7() requires an access exclusive lock, which blocks every read and write on the table, including plain SELECT statements, even though the statement itself executes quickly. On heavily queried tables there is rarely a natural window for this lock, so short lock_timeout and statement_timeout settings combined with retries, or a PL/pgSQL loop with jittered backoff of 50-250ms across up to 50 attempts, can grab the lock without taking the database down. _engineers planning zero-downtime schema changes can track these lock-handling patterns on daily.dev._ ### What is the downside of using UUID v7 instead of UUID v4 for primary keys? UUID v7 encodes a timestamp in its first bits, which can be easily decoded, effectively exposing the creation time of a record. This is a potential privacy or information-leakage concern that UUID v4 does not have, since v4 values are fully random and reveal nothing about when a row was created, so teams should weigh this trade-off before adopting v7 as their default. _daily.dev helps developers weigh trade-offs like this before committing to a UUID versioning strategy._ ## Community discussion Top comments from developers on daily.dev. **@agustinbarrientos** · 0 upvotes > Would you keep UUID v4 on externally exposed identifiers and use v7 only behind that boundary, or would you accept the creation-time leak in practice? ## Similar posts on daily.dev - [Exploring PostgreSQL 18's new UUIDv7 support](https://daily.dev/posts/exploring-postgresql-18-s-new-uuidv7-support-uspoubwqo) · Hacker News · 0 upvotes · 0 comments - [The Time Traveler's Primary Key](https://daily.dev/posts/the-time-traveler-s-primary-key-x5yvsdpzm) · Planet PostgreSQL · 0 upvotes · 0 comments - [PostgreSQL 18's UUIDv7: Faster and Secure Time-Ordered IDs](https://daily.dev/posts/postgresql-18-s-uuidv7-faster-and-secure-time-ordered-ids-smvesvjbw) · Hashrocket · 42 upvotes · 0 comments --- Tags: [#database](https://daily.dev/tags/database), [#postgresql](https://daily.dev/tags/postgresql), [#rails](https://daily.dev/tags/rails) [View this post on daily.dev](https://daily.dev/posts/postgresql-18-23x-faster-inserts-with-uuid-v7-nc2q5uwx2) ```json {"@context":"https://schema.org","@graph":[{"@type":"Organization","@id":"https://daily.dev/#organization","name":"daily.dev","url":"https://daily.dev","logo":{"@type":"ImageObject","url":"https://daily.dev/apple-touch-icon.png","width":180,"height":180},"sameAs":["https://twitter.com/dailydotdev","https://github.com/dailydotdev","https://www.linkedin.com/company/daily-dev-ltd"]},{"@type":"WebSite","@id":"https://daily.dev/#website","url":"https://daily.dev","name":"daily.dev","publisher":{"@id":"https://daily.dev/#organization"},"potentialAction":{"@type":"SearchAction","target":{"@type":"EntryPoint","urlTemplate":"https://daily.dev/search?q={search_term_string}"},"query-input":"required name=search_term_string"}}]} {"@context":"https://schema.org","@type":"TechArticle","headline":"PostgreSQL 18: 23x Faster Inserts With UUID V7","url":"https://daily.dev/posts/postgresql-18-23x-faster-inserts-with-uuid-v7-nc2q5uwx2","mainEntityOfPage":{"@type":"WebPage","@id":"https://daily.dev/posts/postgresql-18-23x-faster-inserts-with-uuid-v7-nc2q5uwx2"},"datePublished":"2026-08-26T17:01:13.377Z","dateModified":"2026-09-14T09:03:08.727Z","description":"A production migration from UUID v1/v4 to UUID v7 primary keys on PostgreSQL 18.4 delivered up to 23x faster multi-row insert performance on a heavily-queried,...","image":"https://media.daily.dev/image/upload/s--VDukGCjf--/f_auto/v1722860399/public/Placeholder%2002","thumbnailUrl":"https://media.daily.dev/image/upload/s--VDukGCjf--/f_auto/v1722860399/public/Placeholder%2002","isAccessibleForFree":true,"articleSection":"Planet PostgreSQL","inLanguage":"en","publisher":{"@type":"Organization","name":"daily.dev","url":"https://daily.dev","logo":{"@type":"ImageObject","url":"https://daily.dev/apple-touch-icon.png","width":180,"height":180}},"author":{"@type":"Organization","name":"Planet PostgreSQL","logo":"https://media.daily.dev/image/upload/logos/placeholder.jpg","url":"https://daily.dev/sources/planet-postgresql"},"commentCount":1,"discussionUrl":"https://daily.dev/posts/postgresql-18-23x-faster-inserts-with-uuid-v7-nc2q5uwx2","interactionStatistic":[{"@type":"InteractionCounter","interactionType":{"@type":"LikeAction"},"userInteractionCount":19},{"@type":"InteractionCounter","interactionType":{"@type":"CommentAction"},"userInteractionCount":1}],"keywords":"database,postgresql,rails","timeRequired":"PT9M"} {"@context":"https://schema.org","@type":"BreadcrumbList","itemListElement":[{"@type":"ListItem","position":1,"name":"Home","item":"https://daily.dev"},{"@type":"ListItem","position":2,"name":"Planet PostgreSQL","item":"https://daily.dev/sources/planet-postgresql"},{"@type":"ListItem","position":3,"name":"PostgreSQL 18: 23x Faster Inserts With UUID V7"}]} {"@context":"https://schema.org","@type":"WebPage","@id":"https://daily.dev/posts/postgresql-18-23x-faster-inserts-with-uuid-v7-nc2q5uwx2","comment":[{"@type":"Comment","text":"Would you keep UUID v4 on externally exposed identifiers and use v7 only behind that boundary, or would you accept the creation-time leak in practice?","datePublished":"2026-09-03T18:06:09.574Z","url":"https://daily.dev/posts/nC2Q5UWx2#c-9iG5EmcGa","author":{"@type":"Person","name":"Agustin Barrientos","url":"https://daily.dev/agustinbarrientos","image":"https://media.daily.dev/image/upload/s--5ayxQnqn--/f_auto/v1788281802/avatars/avatar_wQYYVe5Tbj0NJ7C7qPoa8?_a=BAMAMicg0"}}]} {"@context":"https://schema.org","@type":"FAQPage","@id":"https://daily.dev/posts/postgresql-18-23x-faster-inserts-with-uuid-v7-nc2q5uwx2#faq","mainEntity":[{"@type":"Question","name":"How much faster are inserts after switching from UUID v4 to UUID v7 primary keys in PostgreSQL 18?","acceptedAnswer":{"@type":"Answer","text":"Insert performance improved dramatically after switching to UUID v7 primary keys in PostgreSQL 18.4, with the largest observed gain being a 23x reduction in average insert execution time, from 0.7ms down to 0.03ms, on a table receiving 12,000 insert calls per minute with billions of rows. Other tables saw 6x, 8x, 9x, and 20x speedups, driven by v7's monotonically increasing values keeping b-tree index pages hot in the buffer cache. daily.dev surfaces real-world performance benchmarks like this for engineers weighing a UUID v7 migration."}},{"@type":"Question","name":"Why does switching a column default to uuidv7() in PostgreSQL require downtime or careful handling?","acceptedAnswer":{"@type":"Answer","text":"Running ALTER TABLE ALTER COLUMN to change a default to uuidv7() requires an access exclusive lock, which blocks every read and write on the table, including plain SELECT statements, even though the statement itself executes quickly. On heavily queried tables there is rarely a natural window for this lock, so short lock_timeout and statement_timeout settings combined with retries, or a PL/pgSQL loop with jittered backoff of 50-250ms across up to 50 attempts, can grab the lock without taking the database down. engineers planning zero-downtime schema changes can track these lock-handling patterns on daily.dev."}},{"@type":"Question","name":"What is the downside of using UUID v7 instead of UUID v4 for primary keys?","acceptedAnswer":{"@type":"Answer","text":"UUID v7 encodes a timestamp in its first bits, which can be easily decoded, effectively exposing the creation time of a record. This is a potential privacy or information-leakage concern that UUID v4 does not have, since v4 values are fully random and reveal nothing about when a row was created, so teams should weigh this trade-off before adopting v7 as their default. daily.dev helps developers weigh trade-offs like this before committing to a UUID versioning strategy."}}]} ```