Forum Discussion
Fabric Workspace Architecture
As the use case has limited 1 Data Engineer, I would recommend it to go with Option 3 as it will have :
- Very easy to manage
- Everything in one place
- Easier monitoring
- Less clicking around and
- Faster development.
But i will also have few drawbacks like, can become messy if naming standards are poor, less security control etc.
Once the project mature and team expand you can gradually shift towards option-2 or Option-1
Memorable MemberHi reddyr2502,
I would lean toward Approach 3 as well, especially for a solo engineer, but I would base the workspace boundaries more on security, ownership and lifecycle requirements than on the individual source systems.
Microsoft's current Fabric deployment guidance explicitly supports a single-workspace medallion design with separate lakehouses for bronze, silver and gold. For a smaller team, that keeps orchestration and day-to-day management much simpler.
I also would not give NetSuite its own workspace purely because it represents 40% of the data. If the workspaces sit on the same Fabric capacity, they still share that capacity, so separating them doesn't inherently provide compute isolation.
If you later need a stronger security or ownership boundary, a useful evolution is bronze + silver in a staging workspace and gold + semantic models/reports in a presentation workspace. Microsoft actually uses that pattern in its Fabric CI/CD guidance.
One other small point: I wouldn't use the 2,000-table count alone as a reason to split. Fabric does have a 1,000-item workspace limit, but that refers to Fabric/Power BI workspace items. A lakehouse itself is an item and can contain many tables.
So for where you are now, I would start with Approach 3 and introduce additional workspaces when an actual security, ownership or deployment boundary appears.
AI-assisted drafting: AI was used to help structure and phrase this response. I reviewed and validated the technical content before posting.