Duplicate key value violates unique constraint "session_pkey"

[quick-tutoriel]

Describe the Bug

Hello, I have just upgraded from version 18.1 to 19.0 and since then in the logs I have this constantly:

2025-08-05 16:15:11.843 UTC [231] ERROR: duplicate key value violates unique constraint "session_pkey"
2025-08-05 16:15:11.843 UTC [231] DETAIL:  Key (session_id)=(989d4346-bb83-556c-811c-9f0bf998ca2d) already exists.
2025-08-05 16:15:11.843 UTC [231] STATEMENT:  INSERT INTO "public". "session" ("session_id", "website_id", "browser", "os", "device", "screen", "language", "country", "region", "city", "created_at") VALUES ($1,$2,$3,$4,$5,$6,$7,$8,$9,$10,$11) RETURNING "public". "session". "session_id", "public". "session". "website_id", "public". "session". "browser", "public". "session". "os", "public". "session". "device", "public". "session". "screen", "public". "session". "language", "public". "session". "country", "public". "session". "region", "public". "session". "city", "public". "session". "distinct_id", "public". "session". “created_at”

Do you have any idea what the problem is? It doesn't seem to affect Umami's operation, but it does pollute the logs.

Thanks in advance for your answers.

Database

PostgreSQL

Relevant log output

Which Umami version are you using? (if relevant)

2.19.0

Which browser are you using? (if relevant)

Chrome

How are you deploying your application? (if relevant)

Docker

[serversathome]

Same issue

[markcarroll]

I am seeing the same thing

[stat1c-void]

I've poked around the codebase a bit, and I believe this is by design for now. This unique constraint would be hit on client's first track() or identify() after a distinct page load (read: script init). Especially annoying for non-SPA websites.

In src/app/api/send/route.ts createSession() is called on every request, if cache token isn't available. Cache token does not persist between page loads.

createSession() runs Prisma's create() and just ignores unique constraint error.

I think it's possible to use Prisma's upsert() there. But native upsert doesn't work for MySQL (docs). So it would mean taking a performance hit with MySQL, and still check for constraint errors.

I've seen this commit in blame: https://github.com/umami-software/umami/commit/3a119acd1096f41f787729e1508eed934fba07ca It seems that retrieving session was considered a performance hit. But I wonder if main problem was ORM deserialization? So possibly non-native upsert wouldn't be that bad.

[stat1c-void]

As a side note, I think a lot of performance issues in that case originates from usage of random-valued primary key. Especially unpleasant in case of MySQL - AFAIK its pkeys are clustered by default (like, pkey B+ tree is the row store itself). That means inserting and querying data all over the place.

But I see that UUIDv5 is used, because it needs to be deterministic based on websiteId, IP, etc. And that stems from not storing sessionId (or cache token) on the client side. Which I suspect because of GDPR? Otherwise, it would possibly be better to use time-based, natively ordered UUIDs like UUIDv7 or ULID.

[quick-tutoriel]

Hello,

Is a fix planned for future versions so that our log files no longer crash due to this error?

Thank you.