Forum Discussion
Memorable MemberFabric capacity strategy: one shared capacity or separate capacities for dev, test and prod?
Hi everyone,
I would like to hear how others split Fabric capacity across environments. The two layouts I keep seeing are one larger shared capacity with workspaces separated by environment, and a smaller dedicated capacity per environment.
Option A: one F-SKU shared by dev, test and prod workspaces
Option B: small F-SKU for dev/test, separate F-SKU for prod
Option C: B plus a pausable capacity for dev/test outside working hoursQuestions:
- How do you stop a heavy dev or test job from throttling production in a shared capacity, and is the capacity metrics app enough to catch it early?
- If you separate capacities, how do you handle features that need the same region or capacity for cross-workspace access, such as shortcuts or deployment pipelines?
- Is pausing a non-production capacity worth the operational risk, and what do you do about scheduled refreshes and jobs while it is paused?
Thanks in advance.
Thank you maruthisp, AvdBerg and Shubham_rai955. Here is the summary of the answer from this thread; all three replies point the same way.
Short answer: separate workspaces per environment, with Dev and Test sharing a smaller capacity and Production on its own dedicated capacity.
Layout -> Dev + Test share a smaller capacity; Prod on a separate dedicated capacity Why -> workload isolation: heavy notebooks, pipelines and test runs in Dev/Test must not consume the compute that production users depend on, which causes throttling Sizing -> if development is intense, Dev/Test may need equal or larger capacity for a while; for production-like performance tests, give Test its own capacity or scale it up temporarily during the test Pausing -> a non-production capacity is worth pausing if it can be paused for roughly 40% of the time or more; otherwise a reservation is cheaper and removes the operational risk of paused jobsThis keeps cost down while protecting production, and it can be adjusted as the development load changes.
AI-assisted drafting: AI was used to help structure and phrase this response. I reviewed and validated the technical content before posting.
4 Replies
- maruthisp
Super User
Hi jubinsoni,
For most organisations, what I have see is having separate workspaces for Dev/Test/Prod, but not necessarily a separate capacity for every environment.
A practical approach is:
- Dev + Test → share a smaller Fabric capacity
- Prod → use a separate dedicated capacity
This gives you a good balance between cost and workload isolation. Microsoft also documents this as a valid deployment pattern.
The main reason to keep Production separate is that heavy development jobs, notebook runs, pipelines or testing should not consume the same compute and cause throttling for production users.
If you need production-like performance testing, then you can temporarily give Test its own capacity or scale it up during testing.
Best Regards,
Maruthi
LinkedIn - http://www.linkedin.com/in/maruthi-siva-prasad/
X - Maruthi Siva Prasad - (@MaruthiSP) / X - AvdBerg
Resolver II
Hi jubinsoni
I mostly go for the approach provided by maruthisp, For Dev + Test it would depend on the development intensity. If there is a lot of development going on together with testing the capacity might be equal or larger for a short while.
For a non-production, pausing is a possibility if you pause over roughly 40% of the time, otherwise a reservation would make more sense. The reservation would negate any operational risks you might face.
Shubham_rai955In my experience, I would prefer keeping Dev and Test on a shared capacity and Production on a separate dedicated capacity.
The main reason is workload isolation. Development notebooks, pipeline executions and testing can consume significant CUs, which can impact production workloads if everything runs on the same capacity.
A few things I would consider:
- Dev + Test: Share a smaller capacity, provided the development workload is manageable.
- Production: Keep it separate to avoid unexpected throttling and ensure consistent performance.
- Capacity monitoring: Use the Fabric Capacity Metrics app to identify CU spikes and heavy workloads.
- Pausing: Consider pausing Dev/Test outside working hours if the cost savings justify managing scheduled jobs and refreshes.
I would also avoid creating separate capacities for every environment unless there is a clear need for workload isolation.
For most teams, Dev/Test on one capacity and Production on another is a reasonable balance between cost and performance.
jubinsoniThank you maruthisp, AvdBerg and Shubham_rai955. Here is the summary of the answer from this thread; all three replies point the same way.
Short answer: separate workspaces per environment, with Dev and Test sharing a smaller capacity and Production on its own dedicated capacity.
Layout -> Dev + Test share a smaller capacity; Prod on a separate dedicated capacity Why -> workload isolation: heavy notebooks, pipelines and test runs in Dev/Test must not consume the compute that production users depend on, which causes throttling Sizing -> if development is intense, Dev/Test may need equal or larger capacity for a while; for production-like performance tests, give Test its own capacity or scale it up temporarily during the test Pausing -> a non-production capacity is worth pausing if it can be paused for roughly 40% of the time or more; otherwise a reservation is cheaper and removes the operational risk of paused jobsThis keeps cost down while protecting production, and it can be adjusted as the development load changes.
AI-assisted drafting: AI was used to help structure and phrase this response. I reviewed and validated the technical content before posting.
