A data lake is a living archive and not a static snapshot. Files written in January rarely look like those written in December. As products evolve and businesses change, columns are inevitably added, renamed, dropped, and reordered. The critical question is: does your query engine evolve with them?

Unlike traditional databases, data lakes lack a central authority to enforce schema consistency across Parquet files. This structural freedom creates fragmented datasets where column names, order, and availability vary wildly over time. Without automated reconciliation, organizations are left exposed to constant query failures and inaccurate results.

The Real Cost of Schema Drift

Schema evolution is the daily norm and no longer an edge case. When a query engine can’t adapt, a single schema mismatch across partitions can trigger a costly chain reaction:

• Cascading pipeline failures that halt downstream data flows
• Emergency data rewrites spanning terabytes of historical data
• Delayed business-critical reporting that stalls decision-making for hours or days

For organizations building large-scale AI, BI, and lakehouse architectures, rewriting petabytes of Parquet data every time a schema changes is not sustainable. They require platforms that can seamlessly query evolving datasets without interrupting business operations.

Where Adaptability is Non-Negotiable

This need for dynamic schema handling is particularly critical for data-intensive and high-stakes environments, such as:

• Streaming ingestion pipelines where upstream data formats change on the fly
• IoT and telemetry workloads processing diverse and unpredictable device logs
• Financial transaction systems require absolute accuracy amidst shifting compliance and feature updates
• Multi-tenant SaaS analytics where different customers dictate unique data shapes
• AI and ML feature stores that constantly integrate new variables for model training
• Long-retention historical archives spanning years of legacy and modern formats

Ultimately, modern analytics teams cannot afford to be slowed down by rigid data structures. They need a solution that adapts dynamically to schema evolution while preserving peak performance and reliability.

Bridging the Gap Between Warehouse and Lakehouse

Traditionally, bridging the gap between a structured data warehouse and an evolving data lake required a rigid contract. VMware Tanzu Greenplum relies on the Platform Extension Framework (PXF) – a high-performance, parallel data mover. It enables  querying external object storage like AWS S3, Google Cloud Storage, or Azure Data Lake.

Prior to the latest release, PXF expected strict structural alignment. If a Tanzu Greenplum table definition looked for a column that didn’t exist in an older Parquet file, the query engine would immediately fail. To avoid these failures, data teams were forced into costly workarounds:

• Rewriting historical data: Running massive Spark or Hive jobs to inject empty columns into petabytes of legacy files
• Increasing DDLs: Managing multiple external tables for the exact same dataset based on when the data was generated

To eliminate this operational friction, Tanzu Greenplum has fundamentally evolved how its extension framework communicates with modern file formats.

The Solution: FILL_MISSING_COLUMNS

With the new FILL_MISSING_COLUMNS option enabled, PXF switches from strict positional or rigid mapping to a smart, name-based lookup.

• If a column is present in both the table definition and the Parquet file: It reads normally
• If a column is defined in VMware Tanzu Greenplum but missing from the Parquet file: PXF automatically pads that column with NULL for every affected row in that file. No errors, no interrupted pipelines

Why FILL_MISSING_COLUMNS instead of FILL_MISSING_FIELDS?

Tanzu Greenplum’s existing COPY framework uses FILL_MISSING_FIELDS, but it only applies to text/ CSV formats and only handles trailing columns at the end of a row. PXF’s new FILL_MISSING_COLUMNS parameter uses name-based resolution to inject NULLs for missing Parquet columns regardless of where they sit in your table definition.

How it works

Consider a case where the user has a folder full of Parquet files accumulated over time, but older files don’t contain all the columns that newer files do.

2022/ -> id, ts, user_id, action
2023/ -> id, ts, user_id, action, region
2024/ -> id, ts, user_id, action, region, cost

# Without schema evolution: query fails to return
# With schema evolution: query succeeds, older partitions returns NULL for columns that didn't exist yet

SELECT id, ts, user_id, action, region
FROM events
WHERE ts >= ‘2022-01-01’;

Here is a step-by-step breakdown of how PXF 8.0.1 handles schema evolution.

The Foreign Table

CREATE FOREIGN TABLE events(
id  BIGINT,
ts  TIMESTAMP, 
user_id  INTEGER,
action  TEXT,
region  TEXT,
cost  NUMERIC) 
SERVER s3_server 
OPTIONS (
resource  'data/events/', 
format  'parquet',
fill_missing_columns 'true' -- Enable schema flexibility 
);

In the above SQL, we use the modern Tanzu Greenplum Foreign Data Wrapper (FDW) syntax to map a Greenplum table to an external directory. Please see documentation to see the DDL updates for the older External Table API.

• The Target Schema: User defines a table with six columns: id, ts, user_id, action region and cost. Let’s say region and cost were only recently introduced by your upstream data pipelines
• The FDW Connection: SERVER s3_server tells Tanzu Greenplum to hand off the heavy lifting to the PXF Java engine
• The Magic Parameter: Inside the OPTIONS clause, you see fill_missing_columns 'true'

How it acts: This is an explicit instruction to PXF. It says: “If you open a Parquet file in this directory and it doesn’t have a column named ‘region’ or ‘cost’, do not panic. Do not throw an error. Just act as if that column exists in the file but happens to be entirely filled with NULL values.”

Motivating User Query

SELECT id, ts, user_id, action, region
FROM events
WHERE ts >= ‘2022-01-01’;

PXF Scans All Matching Partitions on S3

The resource ‘data/events/’ points to a directory, so PXF will scan all Parquet files found there. Assuming your S3 layout looks like:

s3://your-bucket/data/events/
├── year=2022/   ← Parquet files here (no "region" column)
├── year=2023/   ← Parquet files here ("region" column exists)
└── year=2024/   ← Parquet files here ("region" column exists)

Since ts >= '2022-01-01' spans all three partitions and PXF will read all of them.

The Schema Mismatch Problem

Partition	Has  a region column?	Without fill_missing_columns	With fill_missing_columns
year=2022	❌ No	💥 QUERY FAILS	✅ NULL for region
year=2023	✅ Yes	✅ Returns value	✅ Returns value
year=2024	✅ Yes	✅ Returns value	✅ Returns value

Global Configuration (Cluster-Wide Default)

If you manage many Parquet tables and want to avoid appending parameters to every DDL script, you can enable this behavior globally by default for all Parquet tables across your Greenplum cluster.

Step 1: Update the pxf-site.xml File

Log into your PXF coordinator node to open the global site configuration file. The default location is: ${PXF_BASE}/servers/s3_server/pxf-site.xml. Add the pxf.parquet.read.fill_missing_columns property block and set its value to true:

<configuration>
    <property>
        <name>pxf.parquet.read.fill_missing_columns</name>
        <value>true</value>
        <description>Enables automatic NULL padding for missing Parquet columns across all tables by default</description>
    </property>
</configuration>

Step 2: Sync the Configuration Across the Cluster

To ensure all segment hosts apply this new default behavior uniformly, distribute the updated configuration files by running the sync command from your command line:

pxf cluster sync

The Query Behavior

Once configured via Option 1 or Option 2, your SELECT queries will seamlessly execute across mismatched files, replacing missing data chunks with NULL transparently under the hood. This allows standard SQL functions to handle the missing data gracefully:

SELECT id, ts, user_id, action, region
FROM events
WHERE ts >= ‘2022-01-01’;

When PXF reads a brand-new file, it pulls the actual data (e.g., ‘us-east‘, or ‘us-west’). In contrast, when it hits a 3-year-old file where the region doesn’t exist, it feeds a NULL to the query executor.

Crucial Distinction: Write Operations

It is vital to note that this feature is strictly a “read-path” specialist. FILL_MISSING_COLUMNS is exclusively a read-time feature designed to simplify access to evolving Parquet datasets. It has no impact on write operations and is ignored for writable PXF tables. When creating new Parquet files, PXF continues to generate schemas based on the defined Tanzu Greenplum table structure, ensuring predictable and consistent write behavior. This separation preserves data integrity while enabling flexible schema evolution for analytics workloads

The Strategic Takeaway

By eliminating the need to constantly normalize historical data files, FILL_MISSING_COLUMNS makes Tanzu Greenplum an even more powerful hub for your object storage and data lakehouse architectures. Available for both Tanzu Greenplum 6 and 7 through the PXF 8 architecture, this capability helps organizations accelerate schema evolution, reduce operational overhead, lower infrastructure costs, and maintain reliable analytics as data pipelines evolve. The result is greater enterprise flexibility, combining modern lakehouse agility with the governance and performance of Tanzu Greenplum.