The concatenation is deliberate and it is the safety feature you are currently trying to remove, so it is worth understanding before overriding it.
The default behaviour: the schema a model is built into is the target schema — the one configured for whoever is running — with the model's custom schema appended. So with a target schema of dev_sibel and a custom schema of marts, you get dev_sibel_marts.
That is what makes your development runs safe. Every developer has their own target schema, so every developer's build lands in their own namespace, and the grouping is preserved inside it. Two people can build the same model at the same time without collision, and neither can touch production.
If custom schemas were used literally, everyone building marts would write to the same marts — which is exactly the overwriting problem you started with, just moved.
So the design is:
- Target schema = who and where. Set per environment and per developer, in the connection profile, not in the project.
- Custom schema = logical grouping. Set per model, in the project, committed.
Production is the case that needs the override. In production you want the clean names — marts, not prod_marts — and that is achieved by overriding the macro that generates the schema name. The standard implementation is a conditional: in the production target, use the custom schema alone; everywhere else, use the default concatenated behaviour.
Write it that way round rather than the reverse. If the override defaults to the clean name and only concatenates for known development targets, then a target nobody anticipated writes straight into the production namespace. The safe default is the one that isolates.
Getting the environments separated, which is the more urgent half of your question:
- Every developer has a distinct target schema, typically derived from their name. This is per-person configuration and must never be committed.
- Production uses a separate target, ideally with separate credentials that developers do not have, and ideally in a separate database entirely rather than only a separate schema.
That last point is worth pushing for. Schema separation is a naming convention; database separation with distinct credentials is enforcement. Right now the only thing preventing you from overwriting production is that you have not run the wrong command yet.
A related trap: if two models in different groups have the same name, they can collide once the grouping is stripped in production. Enforce unique model names across the project — most teams do this with a naming convention that includes the layer, which also makes the lineage readable.