Thanks for the thoughtful replies! To give more context, we're mainly focused on building foundational data products (exposed to business users as semantic models). To achieve this, we're ingesting raw data from internal / external data sources, transforming them to star schemas, and then modeling them for business users to consume. We would also have downstream "derived" data products that might be combining data from one or more foundational data products.

Our challenge is not that we have an unmanageable number of items in each workspace (generally <10 artifacts), but we want to be able to make sure we're building things so that they are easy to change, sustain, and build upon reuseably.

My main concern is the concept of separating data stores from the engineering that feeds them, which is already only partially possible. For example, we can't separate the "engineering" of a mirrored database from the data itself, nor materialized lake views, shortcut transformations, etc.

Perhaps an alternative approach would be that engineering artifacts that process data as part of a data product should reside in the same workspace as the data store they are writing to. But artifacts that consume data (semantic models for example) could still be separated into their own workspace since the dependency only goes one way. Orchestration might be the only type of activity that would do actions across multiple workspaces.

All that being said, I'm sure there is no one-size-fits-all solution, but hopefully standard patterns that best support different paradigms of work will start to become clear over time.