The State of Apache Parquet in 2026: The Quiet Format Enters Its Loudest Decade

By Alex Merced, Head of Developer Relations at Dremio

Apache Parquet is thirteen years old, holds more of the world’s analytical data than any format ever created, and for most of its life has been the least dramatic project in the data stack. It sat at the bottom, it worked, and the interesting arguments happened in the layers above it.

That era is over. As someone who reads the Parquet dev mailing list every week for my newsletter, I can report that 2026 is the busiest, most consequential stretch of Parquet development in a decade. The past year alone brought a native variant type for semi-structured data, first-class geospatial types, a new format release, an active redesign effort for the file footer, proposed types for embeddings and unstructured blobs, a new floating point encoding, and the single longest discussion thread I have seen on that list: eighty-plus messages debating nothing less than the future of Parquet versioning itself.

Why is the quiet format suddenly loud? Two forces converged. The lakehouse era made Parquet the shared substrate under every table format, so every ambition of Iceberg and Delta eventually becomes a demand on Parquet. And the AI era arrived with workloads, embeddings, semi-structured context, wide feature tables, unstructured payloads, that the format’s 2013 assumptions never anticipated. Parquet is being renovated while fully occupied, which is the hardest kind of engineering and the most interesting kind to watch.

This article is my 2026 state of the project: a proper refresher on how Parquet works, what shipped this year, what the dev list is fighting about, how the ecosystem of implementations has reorganized, and what it all means for the people building on top. As always, the goal is that the logic clicks, so the next Parquet headline you see explains itself.

Thirteen Years in Four Chapters

A compressed history sets the stakes for the present, because Parquet’s current renovation only reads correctly against what came before.

Chapter one, 2013 to 2015, was the founding. Engineers at Twitter and Cloudera, with Julien Le Dem among the creators, built a columnar file format for the Hadoop ecosystem, drawing on the record-shredding ideas from Google’s Dremel paper to handle nested data properly, something earlier columnar attempts had fumbled. The bet was that analytical storage should be columnar, compressed, and self-describing, and that an open format would beat every vendor’s private one. The bet was not obviously right at the time. Row-oriented formats dominated, and columnar was a warehouse-vendor specialty.

Chapter two, 2016 to 2019, was the victory. Spark made Parquet its default, every SQL-on-Hadoop engine standardized on it, cloud object storage made file formats matter more than databases, and the Arrow project arrived as the in-memory complement, with the two communities intertwining from the start. By the end of the chapter, Parquet was less a choice than an assumption, and the exabytes began accumulating.

Chapter three, 2020 to 2024, was the lakehouse consolidation. Iceberg, Delta, and Hudi all chose Parquet as their substrate, which quietly changed the format’s job description: it was no longer just a file people read, it was the physical layer of a transactional table abstraction, and every table-format ambition, statistics for planning, encryption for governance, column-level everything, arrived as a requirement on Parquet. Development in this chapter was steady and unglamorous: page indexes, bloom filters, modular encryption, better encodings, the compounding infrastructure work that made the layers above possible.

Chapter four is now, and its character should be clear from everything above: the AI era arrived with new shapes of data and new intensities of access, the lakehouse’s next generation is negotiating with the format layer in real time, and a community that spent a decade in maintenance mode is running its most ambitious renovation, in public, with the versioning question as the constitutional debate that will govern how all the rest lands. Thirteen years in, the format’s second act is genuinely more interesting than its first.

A Proper Refresher: How Parquet Actually Works

Everything in this article depends on the file anatomy, so let me build the mental model quickly and honestly, because most Parquet explanations stop one level too shallow.

A Parquet file organizes a table in three nested layers. The file is divided horizontally into row groups, each holding some slice of the rows, commonly in the hundreds of thousands. Within each row group, data is organized vertically into column chunks, one per column, so all the values of one column in that row slice sit together. Within each column chunk, values are stored in pages, the smallest unit of encoding and compression, typically around a megabyte.

This nesting is the whole trick. Row groups let engines parallelize and skip horizontally. Column chunks let queries read only the columns they touch. Pages let the format apply the right encoding per batch of values: dictionary encoding when values repeat, run-length encoding when they repeat consecutively, bit packing for small integers, delta encodings for sorted data, with general compression like Zstandard layered on top. The encodings are why Parquet files routinely land at a fraction of the size of the same data as CSV or JSON, and the layout is why queries can ignore most of a file’s bytes.

Then comes the part this year’s arguments revolve around: the footer. At the end of every Parquet file sits a metadata block, serialized with Apache Thrift, describing everything a reader needs: the schema, the location of every row group and column chunk, and statistics, minimum and maximum values, null counts, per column per row group. Readers open a Parquet file by reading the footer first, and the statistics power the pruning that makes analytics fast: a filter on date can skip every row group whose date range cannot match, before decompressing a single page. Auxiliary structures extend the same idea: page indexes push min and max tracking down to page granularity, and bloom filters answer “is this value definitely absent” for high-cardinality columns.

Hold two design facts from this tour, because the rest of the article pulls on them. First, the footer must be read before anything else, and it must be substantially decoded even when a query wants one column of a thousand, a property of the Thrift serialization that was harmless when tables were narrow and files were opened rarely. Second, the format’s power comes from types and statistics: every capability Parquet gains arrives as a new logical type, a new encoding, or a new statistic, which is exactly the shape of everything that shipped this year.

What Shipped: Variant, Geospatial, and Format 2.13

Start with the ratified and released, because 2026 opened with Parquet formally announcing two of the biggest type-system additions in its history.

The variant type went official. In February 2026, the Parquet community announced native support for the Variant type, the binary encoding and shredding specifications for semi-structured data that I have written about at length in the Iceberg context, because Iceberg v3’s variant support is built directly on these Parquet specs. The design lives at the Parquet layer on purpose: the binary encoding replaces JSON text with a compact, offset-navigable representation, and shredding extracts frequently occurring fields into real Parquet columns with real statistics, with engines able to supply an explicit shredding schema when read patterns are known or let inference decide. Because the specification is Parquet’s, every engine and table format that implements it shares one physical representation, which is why Spark can write shredded variants that Dremio reads transparently. The dev list traffic since the announcement shows a spec in the hardening phase: threads on realistic variant depth limits, on how pre-variant readers should behave when they meet variant columns, and on where shared components like the JSON parser should live. This is what success looks like for a format feature: the arguments move from “should it exist” to “what happens at the edges.”

Geospatial became a first-class citizen. Also in February, Parquet announced native geometry and geography logical types. For years, spatial data lived awkwardly outside mainstream analytics, in specialized formats or as opaque well-known-binary blobs that columnar engines could store but not understand, with the GeoParquet community convention bridging the gap admirably from the outside. The native types bring coordinates, spatial reference systems, and geometry semantics into the format itself, with statistics such as bounding boxes enabling spatial pruning the same way min and max enable numeric pruning. The follow-on dev list work has the same healthy hardening shape: clarifying coordinate reference system string formats, aligning with the parallel geospatial work in Iceberg v3, which adopted geometry and geography types in the same wave. Logistics, climate, mobility, and location intelligence workloads just got a columnar home that the whole ecosystem shares.

And the release train delivered. Parquet format 2.13.0 went through its release process this spring, carrying the accumulating spec work, while parquet-java shipped its 1.17 line with a 1.17.1 patch following. The community also passed a set of small, telling votes: defining ordering for the legacy INT96 timestamps, adopting IEEE 754 total ordering with NaN counts so floating point statistics finally handle NaN values coherently, and making a redundant schema-path field optional to shave footer weight. Individually minor, collectively these are the format sanding down decade-old ambiguities, the kind of work that only happens when implementers compare notes at scale.

The Eighty-Message Thread: The Future of Parquet Versioning

Now the argument that towers over the season’s dev list: what does a Parquet version even mean, and how should the format evolve from here?

The problem is one Parquet earned through success. The format nominally has versions, and files carry a version marker, but the marker long ago stopped describing reality. Features landed in the specification one by one over a decade, implementations adopted them at wildly different speeds, and “Parquet 2” ended up meaning different things to different writers. The practical result is that nobody negotiates compatibility by version number. Engines make conservative feature-by-feature choices about what to write, defaulting to the lowest common denominator because they cannot know what readers will meet their files. That conservatism has a real cost: excellent features like delta encodings and modern statistics sit underused for years because writers dare not emit what some reader somewhere might choke on.

The thread, running past eighty messages with contributors from across the implementer ecosystem, is wrestling with the way out, and the option space is instructive. One direction formalizes feature flags: files declare exactly which capabilities they use, readers declare what they support, and compatibility becomes a checklist rather than a version comparison, an approach with clear precedent in how table formats above Parquet handle the same problem. Another direction argues for meaningful version milestones, a genuine “Parquet 3” that bundles the modern feature set, footer improvements, new types, better defaults, into a named target that the ecosystem can rally around and test against, with the marketing clarity that a decade of accumulated features has lacked. The companion thread on documenting which features belong to which versions shows the community doing the archaeology either path requires.

I will not predict the outcome, but I will name what is actually at stake, because it is bigger than labeling. The versioning decision determines Parquet’s metabolism: how fast the format can absorb the AI-era additions discussed below without fracturing into dialects. A format read by thousands of independent implementations has one asset above all others, the guarantee that a Parquet file is a Parquet file, and the versioning thread is the community redesigning how to grow without spending that asset. It is the most important boring argument in the data stack right now.

The Footer Problem: Renovating the Front Door

The second great campaign of 2026 attacks the footer, and this one comes with a working group, regular sessions, and competing proposals.

The complaint, precisely stated: the Thrift-serialized footer must be parsed monolithically. A reader wanting the schema and the location of three columns must decode metadata for all one thousand columns, because Thrift’s compact protocol does not support jumping selectively into the structure. When tables were dozens of columns and files were opened once per long scan, nobody noticed. Then came the modern workloads: feature tables thousands of columns wide, machine learning pipelines opening thousands of files per second, interactive engines where footer decode time is visible in query latency, and metadata-heavy features, page indexes, bloom filters, variant shredding statistics, all growing the footer they attach to. Measurements across the ecosystem put footer decoding at a startling share of some scan workloads, and the wide-table AI cases suffer worst.

Two remedial philosophies are on the table, and the contrast is a beautiful engineering study. The first replaces Thrift with FlatBuffers, a serialization format designed for zero-copy access: readers map the footer bytes and jump directly to the pieces they need, decoding nothing they do not touch. It is the thorough fix, and it is also a breaking change to the most compatibility-critical bytes in the analytics world, which is why it has been debated carefully for over a year. The second philosophy, advanced this spring as an alternative, keeps Thrift but adds a lightweight byte-offset index, a small directory that tells readers where each column’s metadata lives inside the footer so they can decode selectively, buying much of the win with a fraction of the disruption. Alongside both runs a proposal to support non-contiguous pages, loosening layout constraints so writers can organize data and metadata more flexibly.

The footer working group has been convening openly, sessions announced on the list, notes flowing back, and the discussion has the flavor of the Iceberg v4 metadata debates, which is no coincidence: the layers are co-evolving. Iceberg’s efficient-column-update ambitions lean on Parquet metadata getting cheaper, and Arrow’s ecosystem supplies much of the implementation muscle. My read as of July: consensus that the problem is real and urgent is total, consensus on the remedy is not yet formed, and the versioning thread’s outcome will shape which remedy is even deliverable. Watch these threads together, because they are one renovation.

The AI-Era Type System: Vectors, Floats, and Files

The third theme of 2026 is the format learning the shapes of AI data, and three proposals carry it.

FIXED_SIZE_LIST for embeddings. Vector embeddings are the defining data type of the AI era, and today Parquet stores them as generic variable-length lists, an encoding that pays offset overhead to express variability that embeddings never use, since every vector in a column has identical dimensionality. A well-supported discussion proposes a fixed-size list logical type: declare the dimension once, store the values as a dense contiguous block, and gain both compactness and the alignment that vectorized readers and GPU consumers want, mirroring the fixed-size layout Arrow has offered in memory for years. It sounds small. Multiplied by the billions of embeddings landing in lakehouses for retrieval workloads, it is one of the highest-impact storage changes on the board, and it pairs naturally with the parallel conversations about vector indexes in the layers above.

ALP for floating point. Floating point data, sensor readings, metrics, model outputs, coordinates, has always compressed poorly under Parquet’s classic encodings, which were designed with integers and strings in mind. The community has been evaluating ALP, adaptive lossless floating point compression, a modern technique from the database research world that exploits how real-world floats cluster, with the dev list working through the remaining spec-level questions. Encodings are Parquet’s quietest superpower, and adding a float-native one addresses what practitioners have long known as the format’s weakest compression story, right as float-heavy AI and observability data becomes a dominant share of what gets written.

A File type for unstructured data. The boldest proposal of the spring introduces a new File logical type: a way to store whole unstructured payloads, documents, images, audio, model artifacts, as first-class values inside Parquet, with the format understanding that a value is a file with a media type rather than an anonymous blob. The motivation is the multimodal AI pipeline, which today shuttles metadata in tables and payloads in object-store sprawl, joining them by fragile path convention. Bringing the payloads into the columnar world, with the metadata, statistics, and governance that implies, would collapse that split. The thread has been appropriately spirited, because the proposal stretches Parquet’s identity: row groups and pages were sized for analytical values, not hundred-megabyte videos, and the boundary between “table format problem” and “file format problem” gets genuinely blurry here, the same layering question the Iceberg column-update debate keeps meeting from the other side. Whether File lands, shrinks, or migrates upward, the pressure it responds to is real and not going away: AI made unstructured data everyone’s analytical problem.

Add the variant hardening work to these three and the pattern is unmistakable. Parquet’s type system is being extended along exactly the axes AI workloads demand: semi-structured context, dense vectors, efficient floats, and raw payloads. The 2013 format assumed data was numbers, strings, and dates. The 2026 format is learning that data is whatever a model touches.

The Ecosystem: Implementations, Old and New

A specification is only as real as its implementations, and the implementation story reorganized quietly over recent years in ways worth understanding.

The historical center, parquet-java, remains the reference for the JVM world that Spark, Flink, Hive, and Iceberg’s Java core inhabit, and 2026 finds it in a deliberate modernization push: the 1.17 line shipping, a discussion to raise the minimum Java version to 17 in line with the platform-wide JDK modernization wave, sustained performance optimization work openly seeking reviewers, testing modernization, and automation of the release process itself. The community health signals surrounding it are good: a new committer welcomed this spring in Ed Seidl, a prolific contributor across the C++ and Rust ecosystems, regular open sync meetings, coordination with the Iceberg community’s calendar, and, in a sign of the times I could not have invented, a thread on adding an AGENTS.md file so AI coding assistants contribute to parquet-java under proper guidance, mirroring the AI-contribution policy conversations running across the Apache data projects.

The newer centers of gravity live inside the Arrow project, a structural fact I flagged in my Arrow state-of piece: the official C++, Rust, and Go Parquet implementations are developed within Arrow’s repositories, maintained by overlapping communities, and shipping on Arrow’s brisk cadences. The Rust implementation in particular has become the engine room for the new wave of lakehouse tooling, and much of the footer and encoding experimentation draws its benchmarks from there. The practical meaning for the ecosystem: Parquet evolves as a joint venture between two Apache communities, with the format specification governed in Parquet and the highest-velocity implementations governed in Arrow, an arrangement that has worked because the people substantially overlap.

And the edges keep growing new implementations, which is the surest sign a format remains alive. This spring brought the announcement of Hardwood 1.0, a new independent Parquet reader for the JVM, built for modern Java and modern performance expectations, arriving on the dev list to a welcome rather than a turf war. Thirteen years in, people still choose to write new Parquet readers from scratch. Formats die when that stops happening.

A Worked Example: One File, One Query, Every Layer Visible

The anatomy section gave you the parts. Let me now assemble them into a single concrete story, one file and one query, with the 2026 developments highlighted along the way, because the renovation only makes sense once you can feel where the time goes.

The file: a day of e-commerce order events written by a compaction job into an Iceberg table. Two million rows, forty columns, one gigabyte on object storage. The writer split it into four row groups of half a million rows each. Inside each row group, the country column chunk dictionary-encoded its two hundred distinct values down to a few kilobytes of dictionary plus tightly bit-packed indexes. The order_total column, floats, compressed less impressively, which is exactly the gap the ALP encoding work targets. A properties column holds semi-structured attributes as a variant, with the writer shredding properties.channel and properties.campaign into typed subcolumns because they appeared on nearly every row. The footer records all of it: schema, the byte locations of one hundred sixty column chunks, and min, max, and null counts for each, a few hundred kilobytes of Thrift at the tail of the file.

The query: total revenue from the mobile channel in Germany, yesterday afternoon.

Step one, the engine reads the footer. Today that means decoding metadata for all forty columns to use the four it needs, the exact inefficiency the footer working group is attacking, whether by FlatBuffers or by the byte-offset index that would let the reader decode only four entries. On this narrow table the cost is a rounding error. On the thousand-column feature table next door, opened thousands of times an hour by a training pipeline, it is the dominant cost, which is why that constituency is driving the redesign.

Step two, pruning. The filter wants Germany, mobile, and an afternoon time window. The engine checks row group statistics: two of the four row groups have event_time ranges entirely in the morning, skipped without touching a byte. Within the survivors, page indexes narrow further, and the country column’s statistics and bloom filter rule pages in or out. The shredded properties.channel subcolumn has its own min and max, so the mobile filter prunes like any typed column, the entire payoff of the variant shredding spec in one sentence: a filter on a JSON field just skipped physical bytes. A year ago, before the shredding spec, this predicate meant decoding every properties blob in every surviving row group.

Step three, reading. The engine fetches exactly the surviving pages of exactly four columns, event_time, country, order_total, and the channel subcolumn, a few dozen megabytes of the gigabyte file, decompresses and decodes them with vectorized kernels into Arrow batches, and aggregates. The other thirty-six columns were never touched. The result returns in the time a row-oriented format would still have spent parsing.

Now run the same story forward two years, with the 2026 proposals landed. The footer read decodes four entries instead of one hundred sixty. The order_total chunk is thirty percent smaller under a float-native encoding. The recommendation team added a 768-dimension embedding column, stored as a fixed-size list, dense and aligned, that the training pipeline reads straight into GPU memory. The support team attached call recordings through a File-typed column, governed and pruned like everything else, instead of orphaned in a bucket joined by path string. Same format, same guarantee that every reader can open it, and a file that serves workloads the 2013 designers never imagined. That continuity, renovation without rupture, is the whole game, and it is what the versioning thread exists to protect.

Parquet and the Layers Above: One Co-Evolution

I write constantly about Iceberg, and a theme of this year’s series has been how often Iceberg’s frontier turns out to be Parquet’s frontier wearing a different name. Let me make the co-evolution explicit, because it is the strategic frame for everything above.

The variant type is the cleanest case: Iceberg v3 declared the type, Parquet defined the encoding and shredding, and the interoperability that makes variant valuable exists precisely because the physical layer standardized once for everyone, Delta included. Geospatial ran the same play in the same release wave. The footer renovation is entangled with Iceberg v4’s ambitions, since efficient column updates and richer per-file statistics presuppose metadata that is cheap to read and extend. The versioning debate mirrors, and will interact with, how table formats negotiate feature support with their readers. Even the File type debate is at bottom a negotiation over which layer owns which problem, the same negotiation the Iceberg column-family discussion conducts from above.

The lesson I keep drawing for practitioners: the lakehouse stack is one organism with three specification layers, memory in Arrow, files in Parquet, tables in Iceberg, and capabilities flow through all three or arrive hobbled. When you evaluate a roadmap claim at any layer, ask what it requires of the layer below. And when you want to see eighteen months into Iceberg’s future, read Parquet’s dev list today, which is, not coincidentally, why my weekly newsletter covers both.

How Parquet Decides: The Machinery Behind the Threads

Since this article leans so heavily on dev list threads, working groups, and votes, a short guide to the project’s decision machinery will make everything above more legible, and it doubles as a template for reading any Apache format project.

Parquet’s constitution is unusual among the projects I cover, because the specification and the implementations have different centers of gravity. The format itself lives in the parquet-format repository as documentation plus Thrift definitions, governed by the Parquet PMC, and changes to it are the highest-stakes decisions in the project: a spec change binds every implementation, forever, against exabytes of existing files. The implementations then live in several places, parquet-java under the Parquet project directly, and the C++, Rust, and Go implementations inside Arrow’s repositories under Arrow’s cadence, with heavily overlapping contributors keeping the two communities aligned.

Ideas move through a recognizable pipeline. They surface as DISCUSS threads, often paired with a design document and a GitHub issue, and the message count is a decent proxy for how contested the design space is, which is how you should read the eighty-message versioning thread and the fourteen-message File type thread differently. Sustained topics graduate to working groups with scheduled sessions and posted notes, the footer effort being this year’s example. Decisions land as VOTE threads on the list, spec changes like the NaN-count statistics and the INT96 ordering passing this way in recent months, and releases of both the format and the libraries go through release-candidate votes with public verification.

Two practical habits follow for anyone tracking the project. First, weight artifacts by their stage: a merged spec change outranks a passed vote outranks a working group draft outranks a lively thread, and vendor blog posts rank below all of them. Second, watch the implementation gap deliberately, because Parquet features become real for you only when your engines’ Parquet libraries ship them, which typically trails the spec by quarters, and the community’s own effort to document feature support per version exists precisely because that gap has historically been foggy. The monthly community syncs, coordinated openly enough that scheduling around the Iceberg Summit made the list, are where the two halves, spec ambition and implementation reality, reconcile.

If the Iceberg and Polaris articles in this series taught the lesson that open governance is slow on purpose, Parquet is the senior example: a thirteen-year-old format still making every consequential decision in a searchable public archive, one thread at a time, with the patience of a project that knows its files must outlive every company reading them.

What Practitioners Should Do in 2026

Grounded guidance, in the order I would give it to a platform team this quarter.

Harvest the shipped features. If semi-structured data lives in your tables as JSON strings, the variant encoding with shredding is production-real across a growing engine set, and the read-side wins are large. If spatial data lives in your stack as blobs or sidecar systems, the native geospatial types are the migration target to plan for as engine support arrives through the year. Neither requires waiting on any of the debates above.

Audit your compression and encoding posture. Most teams write Parquet with whatever defaults their engine chose in 2019. A periodic pass on compression codec, dictionary behavior, row group sizing, and statistics settings routinely recovers double-digit storage percentages and scan speedups, and the arrival of new encodings like ALP will reward teams that know their current baseline. Your files are read thousands of times more than they are written, so write-side care is the cheapest performance you can buy.

If you run wide tables or file-per-second workloads, follow the footer work actively, and quantify your own footer overhead now, because you are the constituency the working group is designing for, and because the interim mitigations, trimming unneeded statistics, moderating column counts, caching decoded metadata, are available today.

And calibrate your format expectations to reality: Parquet changes slowly on purpose, features reach you through your engines rather than from the spec directly, and the version marker on a file tells you little. Track capabilities, not versions, which is, after all, exactly the conclusion the eighty-message thread is circling.

Questions I Hear Most Often

The recurring questions from meetups, the podcast, and customer conversations.

Is anything actually going to replace Parquet? The research world keeps producing candidate successors, and the honest reading of the past few years is that their best ideas get absorbed rather than their names winning. New encodings like ALP come straight from that research current, the footer work responds to the sharpest criticisms the newer formats raised, and the AI-era types address the workload gaps challengers pointed at. Parquet’s moat was never technical perfection, it is the thousands of independent implementations and the exabytes already written, and the community’s observable strategy is to metabolize the challengers’ insights faster than the challengers can build ecosystems. My bet remains on the incumbent that learns.

Should I store embeddings in Parquet today? Yes, with eyes open. Variable-length list storage works, the ecosystem does it at enormous scale already, and keeping vectors next to their metadata in governed tables beats a separate store for many retrieval architectures. The fixed-size list work will make it meaningfully better, and the vector-index conversation in the layers above will decide how much of similarity search belongs near the storage. For high-QPS low-latency vector serving, a specialized index still earns its place, with Parquet as the durable system of record beneath it, the same hot-and-cold pattern I described for streaming.

What about page-level and file-level encryption? Parquet modular encryption is mature, specified, and implemented: columns can be encrypted with separate keys, footers can be encrypted or signed, and integrity verification is built in. Adoption has historically lagged the capability, mostly because key management is an organizational problem before it is a format problem. The rising governance pressure around AI data is changing that calculus, and the encryption machinery is one of the format’s underused assets worth a fresh look.

Row groups, file sizes, what should I actually choose in 2026? The classic guidance holds: row groups sized so a scan unit is meaningful, files in the hundreds of megabytes to low gigabytes for object storage economics, achieved through your table format’s compaction rather than hand-tuning writers. The new wrinkle is metadata weight: very wide tables now pay footer costs per file, which argues for fewer, larger files and pruning unneeded per-column statistics until the footer work lands. As ever, measure on your workload, because the defaults were tuned for someone else’s.

How does the versioning debate affect files I have already written? It should not, and that constraint shapes the whole debate. Backward compatibility, old files readable forever, is the community’s non-negotiable, reaffirmed constantly in the thread. What is being decided is forward evolution: how new capabilities get declared, negotiated, and adopted without fragmenting readers. Your existing exabytes are the constituency every proposal must serve, which is precisely why the argument is long.

Where do I follow all this without reading eighty-message threads myself? The dev list archives at lists.apache.org are the source of truth, the monthly community syncs are open with notes posted, and the parquet.apache.org blog now carries substantive feature announcements like the variant and geospatial posts. For the digest version, this is exactly what my weekly Apache Data Lakehouse newsletter exists for: I read the Parquet, Iceberg, Polaris, and Arrow lists so you can spend your hour on your own stack.

Closing Thoughts

The state of Apache Parquet in 2026 is a paradox worth savoring: the most settled format in the data stack is having its most unsettled year, and both halves of that sentence are good news. Settled, because the moat of implementations and exabytes has never been deeper, the release train runs, and the community handles decade-old ambiguities with quiet competence. Unsettled, because the lakehouse above it and the AI era around it are demanding renovations, richer types, cheaper metadata, a saner evolution model, and the community is conducting all of them in the open, working groups and eighty-message threads and all.

Formats are where the industry’s real decisions get made, slowly, byte by byte, in public. The picture of a table in memory was decided this way in Arrow. The picture of a table’s metadata was decided this way in Iceberg. The picture of the data itself, the bottom of the entire stack, is being redecided right now in Parquet, and everything built above will live with the outcome for the next decade.

If you want the kind of foundation that makes these layers legible, from file internals through table formats, catalogs, and the AI workloads reshaping them all, that is what my books are for. I co-authored Apache Iceberg: The Definitive Guide and Apache Polaris: The Definitive Guide for O’Reilly, with further titles on lakehouse architecture, data engineering, and agentic analytics.

Browse the full collection of my books on data and AI at books.alexmerced.com.