Do metadata‑only table operations cost compute credits in Snowflake?

Explore how compute credits are affected by DDL like CREATE OR REPLACE TABLE ... LIKE. Since this operation copies only schema and metadata, it doesn’t read data, so credits aren’t used. Compare with AS SELECT, which reads data and incurs compute. A concise guide for architects and practitioners.

Multiple Choice

Does the statement CREATE OR REPLACE TABLE MYTABLE LIKE MY_TABLE cost compute credits?

This operation creates a new table by duplicating the existing table’s schema and metadata, without copying any actual data. Because nothing is read from the source table and no data is moved or processed, there is no data scanning or heavy compute involved. It’s a metadata-only change, so it doesn’t trigger the kind of compute work you’d see when querying or loading data. If you instead used a statement that selects data from the source (for example, creating a table as select), that would involve reading the data and would use compute credits. In short, creating a table with LIKE copies the structure only, so it does not cost compute credits.

Snowflake’s metadata magic: when creating a table with LIKE

If you’ve spent any time in Snowflake, you’ve learned that not all operations are created equal. Some actions skim across your data, sipping no more than a gentle breeze of compute. Others drag the whole dataset through the processor, paying the full price in credits. One often-overlooked example of the former is the command that creates a new table by copying the structure and metadata of an existing table—without pulling in any actual data. In Snowflake parlance, that’s CREATE OR REPLACE TABLE ... LIKE existing_table. And yes, it’s a subtle, but important, distinction: this is not a heavy compute operation.

Let’s unpack what this command does, why it matters for cost awareness, and where it fits into a broader data-management mindset.

What does CREATE OR REPLACE TABLE ... LIKE do?

At its core, LIKE is all about structure. When you say CREATE TABLE new_table LIKE old_table, Snowflake builds new_table with the same column definitions, data types, and some metadata attributes (like comments and constraints, depending on the exact syntax and Snowflake version). It does not copy the rows from old_table. It’s a blueprint transfer, not a data transfer.

A quick mental model: think of old_table as a blueprint for a house. You’re constructing a new house that matches the blueprint, but you’re not moving any furniture (the data) from the old house into the new one. The walls, windows, and room sizes line up, but the rooms are empty until you decide to populate them.

From a cost perspective, this means you aren’t reading data blocks, performing scans, or running filtering predicates. There’s no data movement happening under the hood. It’s a metadata-oriented operation. Since compute credits in Snowflake are largely tied to the amount of data processed and the compute resources used, a metadata-only change like this tends to fall outside the typical “data-intensive” compute bucket.

Why this is cost-friendly compared with data-centric commands

To see why this matters, compare it to a more familiar pattern: CREATE TABLE new_table AS SELECT ... FROM old_table. When you use AS SELECT, Snowflake reads data from old_table, processes it according to the SELECT statement, and writes the results into new_table. That’s data movement, and it will incur compute credits proportional to the amount of data read and written, plus the resources used to perform the operation (warehouse size, concurrency, etc.).

CREATE OR REPLACE TABLE ... LIKE is different in three practical ways:

  • Data stays put: No data is scanned from old_table. Only metadata is touched.

  • No rewrites of user data: Since there’s no data copied, you avoid the heavy lifting that comes with data replication or transformation.

  • Quick schema alignment: You get a new table with the same structure, ready to be populated later or used to enforce consistent schema across downstream processes.

In short, LIKE is a lightweight, metadata-only action that, in most cases, won’t consume the heavy compute credits associated with data processing tasks.

The subtle caveat: what about metadata and constraints?

Snowflake’s metadata is robust, and LIKE can pull in a lot of useful structural information. However, there are a few nuances to keep in mind:

  • Columns and data types: You’ll mirror the column definitions and data types from the source table, which helps ensure consistency without moving data.

  • Defaults and constraints: Depending on how your Snowflake account and the exact DDL you run are set up, some metadata attributes may carry over, while others require explicit definitions if you want to replicate them precisely.

  • Comments and tags: If you’re relying on descriptive comments or tags for governance, you may want to reapply them to the new table after creation. They’re metadata, but they matter for maintainability and discoverability.

If you’re optimizing for clarity and governance as part of a data platform, this is a good reminder: you can scaffold new structures quickly, then layer in governance, roles, and access controls without triggering a big data-reads event.

Operational realities: when does it actually cost credits?

While metadata-only operations are generally light on compute, there are practical realities to notice:

  • Warehouse size and concurrency matter. If you’re running multiple operations in parallel, the overall resource consumption can add up. It’s not about the data move, but about the churn in the compute layer when several metadata-intensive tasks collide.

  • Catalog and search indexing. In some setups, metadata changes may reflect in metadata services or catalog updates. Those are usually inexpensive, but it’s good to know they exist and can contribute to background activity.

  • DDL metadata locking. Think about the transactional nature of DDL in Snowflake. Even metadata-only changes may contend with other DDL or DML operations, which can momentarily impact concurrency or lock behavior. It’s rare, but it’s worth a nod in the planning notes.

  • Auditing and lineage. If your governance stack automatically documents changes to your data catalog, there could be a small, indirect cost in terms of metadata logging or lineage propagation. It’s not the same as data processing, but it’s part of the system’s overall activity.

The practical takeaway is simple: for routine schema duplication or scaffolding, LIKE is a fast, cost-conscious move. If the table creation is wrapped in a broader series of operations that includes data movement, you’ll want to account for the data-centric steps separately.

When would you accidentally incur data-related credits anyway?

If you’re not paying attention, you might still accumulate compute credits somewhere else in the workflow. Here are a few common scenarios where data-centric costs creep in:

  • CREATE TABLE new_table AS SELECT * FROM old_table: classic data read and write, with all the associated weight.

  • INSERT INTO new_table SELECT ...: adds data movement and processing, especially if the SELECT involves filtering, joining, or aggregations on large datasets.

  • CREATE OR REPLACE TABLE with a clausal twist: if you introduce a SELECT inside the statement or apply transformations during the creation, you’ve crossed into compute-heavy territory.

  • Materialized views or clustering changes: those often require background maintenance and data processing to refresh or reorganize data.

If your goal is to keep costs lean, precision matters. Use LIKE for schema-only replication, reserve AS SELECT for data-driven creation, and map out a small, predictable cost profile for regular maintenance tasks.

Putting it into practice: a quick mental checklist

Here’s a simple way to keep this in mind when you’re architecting a Snowflake workflow:

  • Do I need a new table with the exact same structure as an existing one?

If yes, LIKE is a clean, low-friction option. It builds the skeleton without moving data.

  • Do I need the data from the source table in the new table?

If yes, use CREATE TABLE new_table AS SELECT ... and be prepared for a data scan and the associated compute use.

  • Do I want to enforce the same schema, defaults, and constraints on a target table before loading data?

You can start with LIKE to get the structure, then layer in constraints and defaults as needed. The staged approach keeps things manageable.

  • Am I under strict cost management or on a tight SLA?

Go with LIKE for rapid scaffolding, and minimize heavy data operations during peak periods or in resource-constrained windows.

A few real-world analogies to keep it human

  • Building a house from a blueprint: LIKE is like you building a new house that matches the blueprint of an existing one. You don’t pull furniture from the first home; you’re just constructing the walls, rooms, and layout. When you’re ready to fill it with furniture (data), you move forward with a separate, data-driven plan.

  • Copying a file’s structure without its content: Imagine you duplicate a folder’s skeleton—folder names, file types, permissions—without copying the actual files inside. That’s LIKE in action for tables.

Context matters: the bigger data platform picture

In a modern data stack, you’re often juggling speed, governance, and cost. A metadata-only operation like CREATE OR REPLACE TABLE ... LIKE gives you a quick way to shape the schema landscape, which can be a strategic move when you’re cleaning up, reorganizing, or preparing a launch pad for downstream pipelines. It’s not about pretending data doesn’t matter; it’s about recognizing when a task is about structure, not substance.

A nod to tooling and best practices

  • Documentation helps: keep a short log of when you used LIKE to mirror a table. It aids future audits and makes it clear why the new table exists in its current form.

  • Naming conventions matter: when you create a new table by like-ing another, consider a naming convention that signals its purpose (e.g., staging copies, schema previews, or functional duplicates). Clear naming saves cognitive load later.

  • Access control alignment: after you create the table, review who has access. Even if you didn’t process data, you’re shaping downstream usage and governance.

  • Test in a dev environment: if possible, mirror the change in a non-production space to sanity-check that the structure aligns with expectations before pulling any data into it.

The bottom line, with a touch of clarity

CREATE OR REPLACE TABLE ... LIKE existing_table is a metadata-only operation. It doesn’t read data, it doesn’t move rows, and, for the most part, it won’t trigger the heavy compute credits that come with data processing. It’s a lightweight way to duplicate the skeleton of a table so you can grow, modify, or repurpose the structure without the expense of a data scan.

If you’re building a data platform that feels both nimble and disciplined, this kind of operation becomes a quiet ally. It’s the difference between laying down a sturdy frame quickly and gnawing through a pile of data when you don’t need to. And in the long run, it’s a small but meaningful way to keep your compute budget in check while you design, experiment, and iterate on your data architectures.

So next time you’re planning a schema refresh or a structural reorganization, remember: sometimes the simplest path—copying the schema only—costs almost nothing in compute. It’s a reminder that in data work, not every step has to be a data-heavy sprint. Some days, a clean slate is exactly what you need to see the bigger picture more clearly. And that clarity, in turn, makes it easier to move toward the insights that actually matter.

More practice questions