@OliOlsz Short answer: yes and no. The huge count on pr_sys_locks_pk (83k/30d) is expected “lock race” noise in Pega two threads try to insert the same lock, one wins, the other gets 23505 and Pega handles it. The mid-to-high counts on pr_sys_ruleset_index_pk, pr_sys_appcache_dep_pk, pr_sys_app_hierarchy_flat_pk, and pr_asmclass_pk usually come from concurrent rule indexing/cache rebuilds across multiple nodes; make sure only one node runs those singletons (Job Schedulers/Queue Processors) and that node IDs are unique. pr_data_stream_nodes_pk duplicates point to stream/SRS/Kafka registration races; verify each stream node has a unique ID and clean up stale rows before restart. If these errors align with deployments, cache clears, or node restarts, they’re mostly harmless. What is not “normal” are the pg_class_relname_nsp_index and pg_type_typname_nsp_index hits (even if rare): that means something (a DDL/script) tried to create a catalog object with an already-used name review deployment tooling to avoid parallel/duplicate DDL. Action plan: restrict singleton schedulers to one node, fix duplicate node IDs, stop parallel reindex/rebuild jobs, and confirm app logs show these 23505s are caught (no user failures). If you still see 23505 on true business tables, check sequences vs max(id) and run setval as needed; otherwise consider filtering 23505 at the log collector so the expected lock/index noise doesn’t drown real issues. Thanks