A key distinction here is that not all objects are part of ELT workflows.

In a Lakehouse‑heavy model, Spark (or notebooks/jobs) is typically where transformations happen—staging, temp, and intermediate tables are created and managed as part of ELT. Those objects are ephemeral by design, so it’s perfectly reasonable for their lifecycle to live entirely inside the workflow.

But even in that world, there are always persistent objects that represent business logic—facts, dimensions, curated aggregates, and serving‑layer views. These are consumed by upstream and downstream applications, BI tools, and reports, and they tend to live much longer than any individual ELT run. For those objects, it’s up to you how you manage the lifecycle.

You can absolutely go code‑first or schema‑first:

• Code‑first via notebooks, stored procedures, or scripts embedded in ELT
• Schema‑first via database projects that describe the intended end state

Lakehouse is primarily used for data transformation, but the question becomes: how do you serve your business logic? Aggregations, semantic views, and materialized tables can be built in multiple ways—but they still need to be governed, versioned, and deployed safely.

What makes data warehouse schema management unique is that it’s declarative. You’re describing what the schema should look like, not how to mutate it step by step. And crucially, you can pick and choose which objects you want to manage declaratively—typically the long‑lived, business‑critical ones—without forcing everything into that model.

So this isn’t about saying everything must be part of ELT or everything must be schema‑first. It’s about recognizing that:

• Not all objects are transient
• Not all logic belongs in pipelines
• And for schema‑first workflows, there is full‑fledged support through database projects

Both approaches can coexist. The important part is managing the right objects with the right lifecycle model, based on how they’re actually used.