# Can you use ephemeral materializations in MetricFlow semantic models?

**URL:** <https://discourse.getdbt.com/t/can-you-use-ephemeral-materializations-in-metricflow-semantic-models/15093>\
**Category:** Help\
**Tags:** dbt-core, metricflow\
**Created:** [August 22, 2024, 2:10pm UTC](https://discourse.getdbt.com/t/can-you-use-ephemeral-materializations-in-metricflow-semantic-models/15093 "2024-08-22T14:10:06Z")\
**Posts on this page:** 1\
**Page:** 1

<div class="post-metadata">

**Author:** ![Henry-Pulver](https://avatars.discourse-cdn.com/v4/letter/h/ec9cab/32.png) [@Henry-Pulver](https://discourse.getdbt.com/u/Henry-Pulver)\
**Post date:** [August 22, 2024, 2:10pm UTC](https://discourse.getdbt.com/t/can-you-use-ephemeral-materializations-in-metricflow-semantic-models/15093/1 "2024-08-22T14:10:06Z")

</div>

I’m trying to define MetricFlow semantic models built on top of `materialization: ephemeral` dbt models. Getting this error from `dbt parse` command when using dbt Core CLI:

```auto
node_relation -> relation_name
  none is not an allowed value (type=type_error.none.not_allowed)

```

Changing from ephemeral to view materialization fixes this.

The `semantic_model` references this like so:

```auto
semantic_models:
  - name: fact_lead_stages
    description: 'Lead stages table'
    model: ref('fact_lead_stages')

```

And it’s the `fact_lead_stages` model which is ephemeral.

I also tried prefixing the model and semantic model names with ` __dbt__ cte__` like `ref('__dbt __cte__ fact_lead_stages')` (suggested here: [Materializations | dbt Developer Hub](https://docs.getdbt.com/docs/build/materializations#ephemeral)), this just errored with:

```auto
Semantic_Model 'semantic_model.<proj_name>.fact_lead_stages' (models/fact_lead_stages.yml) depends on a node named ' __dbt__ cte__fact_lead_stages' which was not found

```

Is this not supported/not advisable? And is there a workaround to use MetricFlow metrics without adding views/tables to the DB?

## Context

Don’t want to create more views or tables in this schema as it’s managed by our customer, not us. We want to define metrics over it so that business users can slice & dice with MetricFlow. Realise the performance may be slightly worse than if we used view or table materializations, but this isn’t a concern for us in this context.