Skip to main content
Version: v44

System Limits and Sizing Guidelines

This article describes PrivX system limits and recommended sizing guidelines to help plan and operate deployments efficiently.

  • Hard limits are system constraints that cannot be exceeded.
  • Recommended values reflect typical production environments. Exceeding them may impact performance depending on configuration and usage.

Hard Limits​

The following limits apply to PrivX 42 and later versions unless otherwise noted:

  • Directories: 10,000
  • Roles: 10,000 (increased to 15,000 in PrivX 43)
  • AWS roles: 10,000
  • Local and LDAP users: 200,000
  • OIDC users: 100,000
  • SCIM users: 400,000
  • SCIM directories: 10,000
  • Log collectors: 100
  • Concurrent RPM uploads: 10
  • Extender v2 connections per tunnel: 1,000
  • Connection tag size: 50 bytes
  • Target-domain endpoints: 1,000
  • Account and managed-account batch size: 1,000
  • Session cache: ≤ 2,000,000 entries

Some APIs may allow creating resources beyond these limits, but entries exceeding the limit may not be used.

The following values represent recommended sizing for customer deployment. Higher values are supported and have been tested, but may require tuning and can impact performance depending on the environment.

Hosts​

  • Typical: ~100,000
  • Tested up to: 200,000

Hosts are effectively unlimited. Increasing the number of hosts mainly increases database size. Host queries are paged and typically don't impact performance or memory usage.

If host health checks are enabled, a large number of hosts may increase background network traffic.

Directories​

Directory types other than SCIM

  • Typical: ~10
  • Tested up to: 100

Using many LDAP/AD or Entra ID directories increases polling traffic to back-end systems.
OIDC-based authentication does not have this limitation.

SCIM directories

  • Typical: 1

Most deployments use a single SCIM directory.

Roles​

Regular roles

  • Typical: ~1,000
  • Tested up to: 10,000

Increased number of roles or role rules increases memory usage, and slows role evaluation.

PrivX was originally designed for ~100–500 roles, but performance has been improved in recent versions. From PrivX 43 the maximum limit is 15,000 roles.

AWS roles

  • Typical: ~100
  • Tested up to: 1,000

The number of AWS roles has no significant impact on performance. Roles are fetched and cached during directory refresh.

Users​

Users from sources other than OIDC and SCIM

  • Typical: ~100,000
  • Tested up to: 300,000

Increasing the number of users:

  • Increases memory usage (approximately 10 kB per user in cache).

To optimize performance:

  • Keep directory sizes manageable.
  • Scope role rules to specific directories.

OIDC users

  • Typical: up to 100,000.

OIDC users are cached but short-lived and automatically cleaned up.
No significant performance impact.

SCIM users

  • Typical: ~10,000
  • Tested up to: 60,000

SCIM users are stored in cache, so similar memory considerations apply as for regular users. The main limitation with SCIM users is synchronization:

  • Some SCIM providers do not support batching.
  • Large user counts may increase network traffic.

Access Groups​

  • Typical: ~10
  • Tested up to: ~500

There is no strict system limit. Each access group creates a private key, which may impact HSM-based PrivX deployments.

Log Collectors​

  • Typical: 1–2
  • Tested up to: 10

Using multiple log collectors increases dependency on network connectivity.
Most deployments use local logging.

Role-Store Caches​

Role Membership Count Cache

  • Typical TTL: 60 seconds

Caching the count of role members (both implicit and explicit) on the role details page and in the API response only affects the displayed member count. The actual memberships remain unaffected. Higher values might improve performance in environments with lots of roles when the include_member_count=1 is set in role requests.

Normally, the user interface uses this parameter only when viewing role details. This can cause performance issues if fetching lots of roles with include_member_count=1 while the cache value is low. Enabling Role Membership Count Update Enabled is not recommended on systems with more than a few dozen roles, as it periodically updates membership counts for all roles in the system instead of resolving them only for role details.

Local LRU Cache Size

  • Typical: ~1,000,000 entries

The user role cache is critical for role evaluation performance. Its minimum should be set higher than the combined total of:

  • Active users.
  • Number of role rules.

When the LRU cache is fully used, entries are removed starting from the least-recently used. Increasing the cache size improves PrivX performance, but also increases memory usage. An insufficient cache size can significantly reduce performance in large environments. The Rule Evaluation Cache must always be enabled.

Deleted Roles Cache Size

  • Typical: ~150,000 entries
  • Recommended minimum: 10,000

Used for displaying deleted role names in UI and audit logs.
No impact on performance or memory.

caution

PrivX versions v43 and earlier consume significant memory when mass-deleting roles. If you need to delete lots of roles in such PrivX versions, you should reduce the cache size to work around this issue.

Target-Domain Configuration​

  • Typical endpoints: ~2

No impact on memory usage, but may increase network traffic when scanning large environments.

Lower values increase network traffic.

RPM Uploads​

  • Typical: 1 concurrent upload.

Higher concurrency isn't commonly used.

Extender v2 Connections​

  • Limit: 1,000 connections per tunnel.

Extender v2 automatically creates additional tunnels upon reaching the limit.
Very high connection counts per tunnel may increase latency.

Summary​

  • Stay within hard limits to ensure system stability.
  • Follow recommended sizing for predictable performance.
  • For large deployments, pay special attention to:
    • Role count and rule complexity.
    • User-role cache sizing.
    • Directory structure and filtering.