Preflight checklist
Ory Network Project
No response
Describe your problem
Currently Kratos uses UUIDv4 (e.g. d294a4e0-41c3-48ef-b369-45e4f58e07dd) for all the IDs, including Identity and Identity Credentials.
Using UUID v4 as a PostgreSQL primary key creates performance issues because its fully random nature causes inserts to occur at arbitrary positions in indexes.
This leads to index fragmentation, frequent page splits, and degraded write and query efficiency as the dataset grows.
Describe your ideal solution
The ideal solution is to use UUID v7 as the primary key, since it preserves global uniqueness while introducing time-based ordering.
This allows new records to be inserted sequentially in indexes, minimizing fragmentation and page splits, and maintaining consistent write and query performance as the database scales.
It's fully backward compatible for either database schemas or applications.
Workarounds or alternatives
For identities, we can use client-generated IDs by supplying a pre-generated UUIDv7 during registration. However, this approach does not apply to registration flows initiated by Kratos itself, such as when users sign in via third-party OIDC providers (Google, Apple, etc.).
UPD: It seems Kratos doesn't support creating Identities with client-generated IDs anymore. API Specs.
Version
26.2.0
Additional Context
Preflight checklist
Ory Network Project
No response
Describe your problem
Currently Kratos uses UUIDv4 (e.g.
d294a4e0-41c3-48ef-b369-45e4f58e07dd) for all the IDs, including Identity and Identity Credentials.Using UUID v4 as a PostgreSQL primary key creates performance issues because its fully random nature causes inserts to occur at arbitrary positions in indexes.
This leads to index fragmentation, frequent page splits, and degraded write and query efficiency as the dataset grows.
Describe your ideal solution
The ideal solution is to use UUID v7 as the primary key, since it preserves global uniqueness while introducing time-based ordering.
This allows new records to be inserted sequentially in indexes, minimizing fragmentation and page splits, and maintaining consistent write and query performance as the database scales.
It's fully backward compatible for either database schemas or applications.
Workarounds or alternatives
For identities, we can use client-generated IDs by supplying a pre-generated UUIDv7 during registration. However, this approach does not apply to registration flows initiated by Kratos itself, such as when users sign in via third-party OIDC providers (Google, Apple, etc.).UPD: It seems Kratos doesn't support creating Identities with client-generated IDs anymore. API Specs.
Version
26.2.0
Additional Context