English Vocabulary for Apache Iceberg Table Format

Apache Iceberg has become the standard open table format for lakehouse architectures, replacing older formats like Hive tables for analytical workloads. Data engineers working with Spark, Flink, Trino, or DuckDB need to communicate precisely about Iceberg’s unique concepts — and the vocabulary in technical documentation, data team Slack channels, and conference talks follows consistent patterns worth learning.

Key Vocabulary

Table Format A table format defines how data files, metadata, and schema information are organized on storage. Iceberg is an open table format — it is not a database engine but a specification for how engines read and write data. Engineers say Iceberg “defines,” “specifies,” or “implements” a table format. Example: “We migrated from Hive-style tables to the Iceberg table format to get proper ACID transactions on our data lake.”

Snapshot A snapshot represents the complete state of a table at a specific point in time. Each write operation creates a new snapshot. Engineers “take,” “create,” or “roll back to” snapshots. Snapshots are the foundation of Iceberg’s time travel and isolation features. Example: “After the bad ETL run, we rolled back to the previous snapshot to restore the table to its last known good state.”

Manifest A manifest is a metadata file that lists a subset of the data files in a snapshot along with their statistics (record count, min/max values). Manifests are grouped into a manifest list. Engineers talk about Iceberg “writing,” “pruning,” and “reading” manifests during query planning. Example: “Iceberg uses the min/max statistics in the manifest to skip irrelevant data files without scanning them.”

Time Travel Time travel is the ability to query a table as it existed at a past snapshot or timestamp. Engineers “run a time travel query,” “use time travel,” or “query as of” a specific point. Example: “I ran a time travel query against the sales table as of yesterday morning to compare it with today’s figures.”

Schema Evolution Schema evolution is Iceberg’s ability to add, rename, drop, or reorder columns without rewriting existing data files. Engineers “perform,” “apply,” or “support” schema evolution. A key advantage over older formats is that Iceberg tracks columns by ID, not name. Example: “We applied schema evolution to add a customer_segment column without touching the 10 TB of existing Parquet files.”

Hidden Partitioning Hidden partitioning means Iceberg manages partition values automatically from a source column using a partition spec (e.g., bucket, truncate, year/month/day transforms). Unlike Hive, users do not need to write partition filter predicates manually. Engineers “configure” or “define” a partition spec. Example: “With hidden partitioning on the event_timestamp column, queries automatically benefit from partition pruning without any special syntax.”

Copy-on-Write vs Merge-on-Read These are two strategies for handling row-level updates and deletes. Copy-on-write rewrites entire data files on each update (fast reads, slow writes). Merge-on-read writes small delta files and merges at read time (fast writes, slower reads). Engineers “choose,” “configure,” or “benchmark” these write modes. Example: “For our high-frequency update workload we chose merge-on-read, but for the reporting layer we use copy-on-write for faster queries.”

Catalog Integration An Iceberg catalog tracks table locations and metadata. Supported catalogs include REST, Hive Metastore, AWS Glue, and Nessie. Engineers “configure,” “integrate with,” or “register tables in” a catalog. Example: “We integrated the Iceberg REST catalog so both Spark and Trino can discover and query the same tables consistently.”

Common Phrases and Collocations

“run a time travel query” The standard phrase for querying historical data. Always “run” — not “execute a time travel” or “do time travel.” Example: “Run a time travel query using FOR SYSTEM_TIME AS OF TIMESTAMP '2026-06-01' to see the table state before last week’s migration.”

“snapshot isolation” Refers to Iceberg’s guarantee that each query sees a consistent snapshot of the table, preventing dirty reads. Used in discussions about concurrency and data consistency. Example: “Snapshot isolation means that a long-running analytical query won’t see partial results from a concurrent write.”

“evolve the schema” The preferred phrasing for making schema changes in Iceberg. “Evolve” implies backward-compatible change — use it when adding columns or renaming. Example: “We can safely evolve the schema to add the new field; existing queries that don’t reference it won’t be affected.”

“expire snapshots” Old snapshots accumulate over time. Teams “expire snapshots” as a maintenance operation to free up storage. Example: “Schedule a weekly job to expire snapshots older than 30 days to keep storage costs under control.”

“partition pruning” The optimization where the query engine skips data files that cannot contain matching rows based on partition metadata. Example: “Partition pruning reduced the query scan from 500 GB to 3 GB because only two daily partitions matched the filter.”

Practical Sentences to Practice

1. “The Iceberg table format gave us schema evolution and time travel without any application changes.”
2. “We configured the partition spec to bucket on user_id with 256 buckets to distribute the data evenly.”
3. “After expiring old snapshots and running orphan file cleanup, the table’s storage footprint dropped by 40 percent.”
4. “The REST catalog allows both our Spark jobs and our Trino cluster to share the same table definitions.”
5. “I need to roll back to the snapshot from before the pipeline run — can you give me the snapshot ID?”

Common Mistakes to Avoid

Saying “Iceberg database” instead of “Iceberg table” Iceberg defines a table format, not a database. The catalog holds tables; Iceberg itself has no concept of a database engine. Say “Iceberg table” or “Iceberg-formatted table.”

Confusing “manifest” and “metadata file” In Iceberg, metadata has a hierarchy: metadata file → manifest list → manifests → data files. A manifest is not the same as the top-level metadata file. Be specific when discussing which layer you are referring to.

Using “partition” as a verb carelessly Say “partition the table by date” when configuring the partition spec, but avoid “Iceberg partitioned my query” — the correct phrase is “Iceberg pruned partitions during query planning.”

Summary

Apache Iceberg’s vocabulary — snapshots, time travel, schema evolution, hidden partitioning, manifest files, and catalog integration — is the shared language of modern data lakehouse engineering. Using these terms precisely helps you write accurate design documents, communicate clearly in data team standups, and contribute effectively to open-source projects in the Iceberg ecosystem. The best resource for deepening this vocabulary is the official Apache Iceberg documentation and the recorded talks from Data + AI Summit and Current conference, where engineers describe real-world Iceberg deployments in natural, professional English.

In Practice: Navigating Feedback & Collaboration

Let’s be honest – communicating effectively in a technical environment, especially when discussing complex concepts like Iceberg table formats, can feel incredibly daunting. For non-native English speakers, the nuances of phrasing, precision, and even just sounding confident during code reviews or discussions can be particularly challenging. It’s not simply about knowing the definitions; it’s about understanding how these terms are actually used in a professional setting, and more importantly, how to clearly articulate your ideas and respond constructively to feedback.

Consider this scenario: You’ve submitted a pull request to update an Iceberg table schema to include a new column for tracking customer purchase history. During the code review, Sarah, one of the senior data engineers, leaves a comment on your branch: “This change introduces a significant amount of historical data. Have you considered how it impacts query performance and potential snapshot isolation issues? It might be beneficial to explore hidden partitioning options here – perhaps by date?” This isn’t criticism; it’s constructive feedback, aimed at ensuring the long-term stability and efficiency of your work. A direct translation of “This is bad” wouldn’t have been helpful, nor would it convey the level of consideration Sarah was asking for. Instead, she’s using precise terminology – “snapshot isolation issues,” “hidden partitioning” – to guide you towards a more robust solution. You might respond with something like: “That’s a great point, Sarah. I hadn’t fully explored hidden partitioning related to date ranges. I’ll investigate how that could mitigate the potential performance impact and ensure proper snapshot isolation.” Notice the use of phrases like “that’s a great point,” “I hadn’t fully explored” – these soften your response and acknowledge her expertise. It’s about demonstrating you’ve listened, understood the underlying concern (performance and data consistency), and are willing to adapt your approach.

Another common situation arises in Slack conversations when discussing Iceberg catalog integration. Let’s say a team member asks: “Can we use the Hive Metastore for our Iceberg table metadata?” The correct technical answer is, of course, that Iceberg supports catalog integration with various systems – including Hive Metastore, AWS Glue Data Catalog, and others. However, the phraseology you use matters. Instead of simply saying “Yes,” a more helpful response might be: “Absolutely! Iceberg’s catalog integration capabilities are designed to work seamlessly with existing data governance tools like the Hive Metastore, allowing for centralized metadata management and improved query routing.” This demonstrates an understanding of the broader ecosystem and highlights a key benefit.

Finally, when writing PR descriptions, clarity is paramount. A good example would be: “Update Iceberg table schema to include purchase_date column. Implemented hidden partitioning by purchase_date to optimize query performance for recent transactions. Investigating impact on snapshot isolation and potential catalog integration with Hive Metastore.”

-- Example of querying an Iceberg table with hidden partitioning:
SELECT * FROM iceberg.my_table WHERE purchase_date BETWEEN '2023-10-26' AND '2023-10-28';

This example shows a simple query that leverages the hidden partition based on purchase_date. The key here is to frame your changes in terms of benefits – optimizing performance, ensuring data consistency, and integrating with existing tools. Focusing on these positive outcomes will not only improve communication but also demonstrate your understanding of Iceberg’s capabilities.