Increase the 1,000 Item Limit per Fabric Workspace

[cengizhanarslan]

In enterprise environments using Dev / Prod workspaces the current 1,000 item limit per workspace becomes restrictive.

A single domain workspace for ETL activities can easily contain: Lakehouse, Pipelines, Notebooks, Dataflows

Over time, the 1,000 item limit per workspace becomes restrictive and forces teams to:

• Split domains across multiple ETL workspaces

• Introduce unnecessary workspace fragmentation

• Increase permission and governance complexity

• Add operational overhead

The limit works well for small-to-medium environments, but it becomes a constraint at enterprise scale.

Suggestion:

• Increase the limit
  or

• Make it configurable based on capacity (F64/F128) or tenant settings

This would reduce workspace fragmentation and better support enterprise-scale Fabric adoption.

[bariscihan]

I completely agree with this point.

In large-scale enterprise environments, especially where Dev / Prod workspace separation is applied, the 1,000 item limit quickly becomes a real constraint.

In the organization I currently work with (without naming it), we are operating at enterprise scale and have experienced significant challenges because of this limitation. Due to project scope and architectural requirements, we naturally exceed 1,000 items within a single domain workspace.

A typical ETL domain includes:

• Multiple Lakehouses
• Dozens of Pipelines
• A high number of Notebooks
• Dataflows and supporting artifacts

As the platform matures and more subject areas are onboarded, crossing the 1,000 item threshold is not an exception — it becomes inevitable.

Because of this limit, we are forced to:

• Split logically unified domains across multiple ETL workspaces
• Introduce unnecessary workspace fragmentation
• Increase permission and governance complexity
• Add additional operational and monitoring overhead

From an enterprise architecture perspective, this creates avoidable complexity.

The current limit works well for small-to-medium implementations, but at enterprise scale it becomes a structural constraint rather than a safeguard.

I strongly support the suggestion to:

• Increase the limit,
  or
• Make it configurable based on capacity tier (e.g., F64 / F128) or tenant-level settings

This would significantly reduce workspace fragmentation and better support enterprise-grade Fabric adoption.

[lbendlin]

We are hitting that limit in another rather obscure place. 1000 connections per gateway. Not helping if we use a large high availability gateway with lots of cluster members.