Concurrency, Not Users, Drives Cost: How Portals Should Be Sized

When organizations move from internal BI to client-facing analytics portals, one misconception appears almost immediately: the idea that cost scales with the number of users.

This assumption feels intuitive. More users usually mean more licenses, more load, and more infrastructure. In embedded analytics and portal-based delivery, that logic breaks down very quickly.

In reality, concurrency, not total users, is what drives cost.

Understanding this distinction is one of the most important steps in designing a portal that performs well, scales predictably, and does not become prohibitively expensive as adoption grows. This article explains why user count is a misleading metric, what concurrency really means in practice, and how portals should be sized for real-world usage rather than theoretical headcount.

Why User Count Is the Wrong Starting Point

User count is attractive because it is simple:

• We have 100 users
• We expect to grow to 500
• Therefore, cost will scale 5x

This logic works for per-user licensing models. It does not work for capacity-based analytics.

In a portal:

• Many users are registered but inactive
• Some users log in sporadically
• Others only access dashboards during specific events
• Usage is time-based, not continuous

Two portals with the same number of users can have radically different cost profiles.

The Core Concept: What Concurrency Actually Means

Concurrency refers to how many users are actively interacting with analytics at the same time.

Not:

• How many users have access
• How many users exist in the system
• How many users logged in this month

But:

• How many users are making queries simultaneously
• How many reports are rendering at the same moment
• How many interactions overlap in time

Concurrency is the point where theory turns into load.

A Simple Example That Changes Everything

Imagine two scenarios:

Scenario A

• 1,000 registered users
• Most log in once a month
• Usage peaks during business hours
• Rarely more than 15 users active at the same time

Scenario B

• 120 registered users
• Used by an operations team
• Continuous access during the workday
• 40 users often active simultaneously

Scenario B almost always costs more to run than Scenario A.

This is why user count alone is not only misleading — it actively produces bad design decisions.

Why Portals Amplify the Concurrency Effect

Portals change usage patterns in subtle but important ways:

• Access friction is lower
• Users are encouraged to return
• Dashboards are embedded into workflows
• Analytics becomes "always available"

This is a success pattern — but it increases concurrency naturally.

If portals are sized only with user count in mind, they often appear to "hit limits" earlier than expected. In reality, they are simply encountering concurrency that was never planned for.

Peak Usage Matters More Than Average Usage

Many capacity sizing exercises rely on averages:

• Average sessions per user
• Average query time
• Average daily users

While useful for reporting, averages are dangerous for sizing.

Capacity must handle peaks, not averages.

If analytics fail during peak usage:

• Trust erodes
• Users abandon dashboards
• Support incidents increase
• Teams overcompensate by oversizing permanently

Correct sizing anticipates the worst reasonable moment — not the typical one.

The Silent Impact of Overlapping Interactions

Concurrency is not just about how many people are logged in.

It is also about:

• How many visuals load at once
• How many users refresh reports simultaneously
• How many slicers trigger recalculations
• How many pages load in parallel

A portal where users open dashboards at the start of meetings will see spikes that look nothing like normal usage.

Ignoring this behavior is one of the most common reasons portals feel fast in testing and slow in production.

Why More Users Can Sometimes Lower Cost Per User

This sounds counterintuitive, but it is often true.

If analytics are distributed to more users without increasing concurrency:

• Reports are reused
• Load is spread across time
• Cost per user decreases

This is why capacity-based models scale economically for external analytics — when concurrency is controlled.

The goal is not to limit users. The goal is to manage simultaneous usage effectively.

The Design Lever Most Teams Miss: Access Patterns

Concurrency is heavily influenced by how portals are designed.

Examples:

• Dashboards that auto-refresh aggressively increase load
• Landing pages that load many reports at once create spikes
• Unrestricted drill-through enables heavy interaction patterns
• Lack of role separation exposes too many visuals per user

Portals that feel simple on the surface often hide inefficient access patterns underneath.

Design decisions shape concurrency just as much as user behavior.

Why "Just Add More Capacity" Is a Trap

When performance issues arise, the fastest response is often: "Let’s increase capacity."

Sometimes this is necessary. Often, it is not.

Blindly increasing capacity:

• Hides inefficient design
• Locks in higher baseline cost
• Reduces incentive to optimize
• Creates dependency on overprovisioning

Sizing should be intentional, not reactive.

Concurrency that is poorly understood will always consume more capacity than expected.

Concurrency Across Clients: The Multiplier Effect

Client-facing portals introduce an additional complication: coinciding schedules.

Different clients may:

• Have similar reporting cycles
• Log in at the same time zones
• Review dashboards at similar frequencies

What looks like "independent usage" on paper often synchronizes in reality.

Without conscious design, concurrency grows faster than client count.

Why Portals Need a Sizing Mindset, Not a Formula

There is no universal formula for sizing portals. But there is a universal mindset change required:

From: "How many users do we have?"

To: "When and how do users actually use analytics?"

This mindset leads to better questions:

• What triggers peak usage?
• Which reports are most expensive?
• Which interactions happen simultaneously?
• Where can load be spread out or delayed?

These questions lead to sustainable scaling.

Concurrency Is Also a Governance Question

Unexpected concurrency spikes often come from:

• Overexposed reports
• Poor role segmentation
• Lack of usage guidance

Governance is not just about security — it is about controlling access in a way that aligns with performance realities.

A well-governed portal does not show everything to everyone all the time.

Measuring Concurrency Without Overengineering

You do not need complex models to understand concurrency.

Useful signals include:

• Simultaneous report loads
• Time-based access clustering
• Repeated load patterns
• Support tickets tied to specific times

The goal is not precision — it is awareness.

Once teams see concurrency patterns, sizing decisions become clearer.

From Headcount Planning to Behavior Planning

The biggest shift successful portal teams make is moving away from headcount planning.

They plan around:

• Behaviors
• Time windows
• Interaction patterns
• Growth in engagement, not accounts

This leads to:

• Fewer surprises
• More predictable cost
• Better user experience
• Confidence when scaling

Final Perspective

In portal-based analytics, users do not drive cost.

Activity does.

Concurrency reflects real usage. User count reflects potential usage. Only one of these translates into load.

Teams that size portals based on user numbers alone end up either overspending or constantly firefighting performance issues. Teams that design around concurrency build analytics platforms that scale naturally, perform reliably, and remain economically sound.

Concurrency is not a technical nuance.

It is the core truth of embedded analytics economics.

Get it right, and growth becomes a strength instead of a risk.

👉 Book a demo today to see how PowerBI Portal helps you get the most out of Power BI capacities.