Performance
Quick answer
IdentityIQ performance comes down to reading only what changed (delta aggregation), refreshing efficiently, keeping rules light, and a healthy, well-indexed database. At scale, partition work, tune task threads and prune old objects so the platform stays responsive.
Key takeaways
- Prefer delta aggregation to full reads
- Tune identity refresh scope and threads
- Keep rules light, no heavy per-account queries
- A healthy, indexed database is essential
- Prune old task results and certifications
Performance in SailPoint is a dedicated concern because at enterprise scale the difference between a well-tuned and a neglected deployment is the difference between overnight batch jobs that finish and ones that run into the working day. This page summarises the levers; the architecture performance page goes deeper.
Where time goes
The heaviest operations are identity refresh, aggregation and certification generation. Their cost scales with population size, so they are always the first place to look when the system is slow.
The main levers
- Database, ensure proper indexes (including for searched extended attributes), right-size the instance and connection pool.
- Partitioning, split heavy tasks across threads and task servers.
- Delta aggregation, read only what changed on large sources.
- JVM, size the heap for the object volume and monitor garbage collection.
- Custom rules, never query the database per identity in a loop.
A method that works
Always measure before tuning. Baseline where time is spent, change one lever at a time, re-measure, and keep only what helps. Blind tuning usually makes things worse.
Common pitfalls
- Tuning by folklore instead of measurement.
- Full, unpartitioned aggregation and refresh at scale.
- Rules that query per identity, dominating refresh time.
Want to learn this properly?
Our live, instructor-led SailPoint Training covers this hands-on, with real projects and a certification path.
Check your understanding
For speed, prefer?
- A. Indexing and pruning. Indexes and pruning keep the database responsive.
- B. Delta aggregation. Delta reads only what changed, far faster at scale.
- C. A DB query inside a per-account rule. Per-account queries run thousands of times; cache instead.
Show answer
B. Delta aggregation. Delta reads only what changed, far faster at scale.
Delta aggregation. Delta reads only what changed, far faster at scale.
A classic performance killer is?
- A. Delta aggregation. Delta reads only what changed, far faster at scale.
- B. A DB query inside a per-account rule. Per-account queries run thousands of times; cache instead.
- C. Indexing and pruning. Indexes and pruning keep the database responsive.
Show answer
B. A DB query inside a per-account rule. Per-account queries run thousands of times; cache instead.
A DB query inside a per-account rule. Per-account queries run thousands of times; cache instead.
Database health depends on?
- A. A DB query inside a per-account rule. Per-account queries run thousands of times; cache instead.
- B. Delta aggregation. Delta reads only what changed, far faster at scale.
- C. Indexing and pruning. Indexes and pruning keep the database responsive.
Show answer
C. Indexing and pruning. Indexes and pruning keep the database responsive.
Indexing and pruning. Indexes and pruning keep the database responsive.