Snowflake Naming

The debate over naming Snowflake table types usually boils down to one fundamental architectural question: Should metadata (storage behavior) be embedded in the object identifier, or should schema organization handle it?

Here is a breakdown of the pros, cons, and industry consensus on whether to use _et (or et_) for External Tables, along with how teams handle Snowflake’s variety of table types.

The Case FOR _et / et_ (Explicit Naming)

1. Performance & Compute Awareness

External tables scan object storage (S3/Azure Blob/GCS) directly. They do not benefit from micro-partition pruning or Snowflake’s automatic clustering in the same way standard managed tables do. A developer or analyst writing a join against orders_et knows instantly that it will incur stage I/O and latency, avoiding accidental full-table scans across external storage.

1. Access & Feature Limitations

External tables have constraints:

• Read-only (no direct DML like UPDATE/DELETE).
• No Time Travel or Fail-safe.
• Joins often require parsing JSON/Parquet variants on the fly.
• Tagging them (_et) sets clear expectations for consumers that standard DML will fail.

3. Catalog & Search Clarity

In IDEs (Snowsight, DBeaver, VS Code), objects are listed alphabetically in schema trees. Having an explicit tag prevents confusion when browsing objects.

The Case AGAINST _et / et_ (Schema-First Abstraction)

1. Pipeline Evolution Breaks Downstream Consumers

A common pattern in Snowflake is starting with an External Table for quick ingestion/exploration, and later refactoring it into a standard managed table (or Dynamic Table / Iceberg Table) via Snowpipe or dbt. If the object is named orders_et, switching to a managed table forces every downstream query, BI dashboard, and model to update its SQL.

2. Snowflake Differentiates Native Metadata Already

You can query INFORMATION_SCHEMA.TABLES where TABLE_TYPE = 'EXTERNAL TABLE'. The metadata already exists natively without polluting the business name.

3. Snowflake Has Too Many Table Types

Get Lakshman Alampally’s stories in your inbox

Join Medium for free to get updates from this writer.

Remember me for faster sign in

If you start naming by storage type, you end up with prefix soup:

• Standard table: _tbl
• External table: _et
• Transient table: _tt
• Temporary table: _temp
• Dynamic table: _dt
• Iceberg table: _it
• Event table: _ev
• This creates cognitive overload and rarely stays consistent across large engineering teams.

Best-Practice Recommendations:

Approach A: Schema Separation (Recommended for Enterprise/Medallion)

Instead of encoding storage mechanics in the table name, isolate external objects by schema or database layer:

• Put external tables in an ingestion or raw schema:

raw_stage.s3_orders or bronze.ext_orders

• Expose standard analytical views or curated tables downstream:

silver.orders

• Verdict: Cleanest for BI and consumption layers. Downstream users query a clean name, while data engineers know that anything inside raw_stage or ext_landing is unmanaged external storage.

Approach B: Tag Only What Carries Operational Constraints

If your organization keeps tables and external tables in the same schema:

• Use ext_ or _et strictly for External Tables and Transient Tables, because they carry operational and cost implications (no Time Travel, stage scan costs, read-only).
• Standard managed tables should have no prefix/suffix (plain business entity name: customer, transaction_line).

The Snowflake Table Dilemma: To _et or Not to _et?

In Snowflake, storage architecture directly impacts query cost and performance. Unlike traditional RDBMSs where a table is just a table, Snowflake distinguishes between Standard, External, Transient, Dynamic, and Iceberg tables.

• If you use schema-level isolation: Prefer housing external tables in dedicated schemas (e.g., landing_ext or stg_external) rather than polluting business names with type suffixes.
• If objects share a schema: Standardize on an explicit marker like ext_ (or _et). External tables scan cloud stages directly and lack native micro-partition optimization—letting engineers know what they are querying saves both runtime and cloud spend.