Understanding eventstore.unique_constraints (V3-DKcYh)
Hello,
In a self-hosted setup with a single Instance (v3.3.0) where we manage 1 organization with ~39k users, we’ve noticed leftover records in the
Examples:
These orphaned records are linked to human users that no longer exist, but they’re blocking new user creation with the
After tracing, I found they all share one thing in common: they were created during a period when the ZITADEL database was under Cloud SQL High CPU Usage load (90%–95%).
Since addressing the DB performance issue, we haven’t seen the problem reoccur.
Manually deleting these stale entries from
Questions:
1. Is it common practice having to monitor
2. What could cause this situation? Is there any built-in cleanup process for invalid or stale constraints?
Thank you!
In a self-hosted setup with a single Instance (v3.3.0) where we manage 1 organization with ~39k users, we’ve noticed leftover records in the
eventstore.unique_constraints table that don’t correspond to any existing user in the instanceExamples:
These orphaned records are linked to human users that no longer exist, but they’re blocking new user creation with the
V3-DKcYh error.After tracing, I found they all share one thing in common: they were created during a period when the ZITADEL database was under Cloud SQL High CPU Usage load (90%–95%).
Since addressing the DB performance issue, we haven’t seen the problem reoccur.
Manually deleting these stale entries from
eventstore.unique_constraints resolves the conflict.Questions:
1. Is it common practice having to monitor
eventstore.unique_constraints when troubleshooting unexpected V3-DKcYh errors?2. What could cause this situation? Is there any built-in cleanup process for invalid or stale constraints?
Thank you!
