Skip to content
Notifications
Clear all

Thoughts on the new SaaS-based PAM offering? Feels like a stripped-down version.

4 Posts
4 Users
0 Reactions
3 Views
(@latency_lucy_2)
Estimable Member
Joined: 3 months ago
Posts: 53
Topic starter   [#630]

I’ve been running some early tests on the new SaaS-based PAM offering and my first impression is that the latency profile is noticeably different from the self-hosted Enterprise version. It feels like a streamlined, opinionated version—which isn’t necessarily bad—but the benchmarks raise questions.

Key observations so far:

* Connection initiation to vaulted assets from North America to their default SaaS region added 8-12ms compared to our on-prem deployment.
* The management console feels snappier, but API response times for bulk credential retrieval are less consistent under load.
* They’ve moved several granular session policies and network zones configurations to a simpler template model.

I’m curious if others have done similar performance comparisons. Are you seeing this trade-off—some operations faster, some slower—as a function of it being a “stripped-down” product, or is it just the nature of the new architecture? Also, which regions are you deploying in, and how is the latency to your endpoints?


ms matters


   
Quote
(@sre_shift_lead)
Active Member
Joined: 1 month ago
Posts: 12
 

8-12ms added latency isn't the headline for me. It's the inconsistency under load. That's the real SaaS tax - you're now sharing noisy neighbors.

They call the policy model "simpler." I call it less capable. You trade fine-grained control for faster onboarding, which only benefits the vendor's sales cycle. Your security team now has to fit your rules into their templates.

Have you tested failover or region evacuation? That's where these streamlined architectures often show their cracks. The console feels snappy until you're trying to rotate 10,000 service account credentials during an incident and the API queues up.


KeepItSimple


   
ReplyQuote
(@pipeline_painter)
Eminent Member
Joined: 2 months ago
Posts: 23
 

Your observation about the latency profile is the critical detail. It's not a uniform slowdown but a selective one. The management console being snappier while API performance degrades under load suggests they've shifted architectural priorities, likely decoupling the control plane from the data plane. The control plane operations are now globally distributed and cached, hence the console feel, but the credential retrieval paths may be funneling through more centralized, cost-optimized backends that can't scale linearly.

This isn't necessarily a stripped-down product, but a differently optimized one for a different cost structure. You trade predictable, linear scaling of your own hardware for potentially better global availability, but with the variance you're seeing. Have you mapped the API endpoints you're hitting to see if they're all served from the same region as the console, or if they're routed elsewhere? That could explain the divergence.


Measure twice, cut once.


   
ReplyQuote
(@startup_ops_lead_jen_2)
Eminent Member
Joined: 4 months ago
Posts: 16
 

The snappier console but laggier API under load is exactly the kind of trade-off I worry about for automation. It might feel faster for a human admin, but it could choke our marketing automation scripts that pull creds on a schedule.

I haven't done formal benchmarks, but in our EU testing, we saw similar variance. The real question for us is whether that inconsistency means our scheduled jobs just take longer, or if they'll actually fail more often and need manual reruns. That's where the "stripped-down" feeling hits ops - it's not about missing features, it's about whether the reliable workflow you built now has hidden failure points.


learning daily


   
ReplyQuote