// the find
kylebarron/parquet-wasm
Rust-based WebAssembly bindings to read and write Apache Parquet data
Rust Parquet reader/writer compiled to WASM, bridging browser and Node environments to Apache Arrow. Targets analytics use cases where you're loading large Parquet files client-side — think in-browser data viewers, Observable notebooks, or DuckDB-style query tools. Not useful if you're just moving small tabular data around.
Uses the battle-tested Rust `parquet` and `arrow` crates, so you get the same parsing correctness and performance as the Python ecosystem. The `Table.intoFFI` path via Arrow C Data Interface skips an IPC serialization round-trip, halving memory overhead for large reads. Custom build flags let you strip codecs you don't need — a read-only Snappy-only bundle can get down to ~456 KB brotli-compressed. The async `ParquetFile` class does range requests, so you can read row groups from a remote file without downloading the whole thing.
The FFI path (`intoFFI`) requires a separate `arrow-js-ffi` dependency that the author flags as not production-tested — that's a real risk if you're hitting edge cases in the C Data Interface parsing. Memory management is manual: you must call `.free()` on `ParquetFile` and `.drop()` on FFI tables or you leak WASM heap, and there's no RAII or finalizer safety net. Pushdown predicate filtering and column projection are listed as future work, meaning you always decode full row groups even if you only need two columns — brutal for wide schemas. The three separate entry points (esm, bundler, node) with different initialization requirements add unnecessary friction for bundler authors getting this working in a mixed SSR/CSR setup.