parqeye: a terminal viewer for Parquet files

A Parquet file in four tabs

parqeye lets you peek inside Parquet files from the terminal, and the interface is organised as four tabs that each answer a different question. The Visualize tab is the data browser, a table view of the file's contents with keyboard navigation. The Schema tab is the schema explorer, showing column types, nested structures and field definitions. The Metadata tab shows the file level information, which the README lists as the version, who created the file, encoding statistics and more. The fourth tab covers row groups, exposing row group level metadata, statistics and the distribution of data across those groups. The last two are the distinguishing feature. Most quick inspection tools show you rows; parqeye also shows you how the file is physically organised, which is what you need when a file is slow to read or when column statistics tell you something is wrong with the data upstream. The project credits csvlens as the inspiration.

Running it and installing it

The usage is a single argument, the path to the file:

parqeye <path-to-parquet-file>

bash

There is also a uvx route for running it without installing anything:

uvx parqeye <path-to-parquet-file>

bash

The distribution channels are unusually broad for a small Rust tool. It is on crates.io for Rust users, who can build it directly:

cargo install parqeye

bash

Homebrew is supported:

brew install parqeye

bash

Windows users have winget:

winget install --id kaushiksrini.parqeye

bash

And a release artefact can be downloaded from the Releases page, or built from source with `cargo build --release`. The presence of a PyPI badge means there is also a Python distribution, and the pyproject.toml in the repository explains how: the build backend is maturin, the bindings are set to bin, and the manifest path points at the Rust Cargo.toml. That is the standard maturin arrangement for wrapping a Rust binary so that `pip install` and `uvx` can both fetch a prebuilt executable rather than compiling the crate on the user's machine.

The Rust dependency set explains the design

Cargo.toml is short and every entry has a purpose. The `clap` dependency at version 4 with the derive feature handles CLI parsing. The core reading comes from the `parquet` crate at version 59.0.0 with the cli, async, json and arrow features enabled, and the `arrow` crate at the same version supplies the arrays and data types. `parquet-format` at 4.0.0 gives access to the Thrift structs, which is how the metadata views are populated. The terminal interface is built on `ratatui` and `crossterm`, both at 0.29.0, and `chrono` handles timestamps, `itertools` the iteration, and `serde_json` the serialisation. The largest dependency is `polars` at 0.55.0 with the lazy, parquet, dtype-full, dtype-extension and timezones features, which is what makes the lazy and streaming work described in the TODOs plausible as an eventual goal. The crate is on edition 2024, and the dist profile inherits release with thin LTO.

The Makefile is a map of the project's quality gates

The Makefile in the repository is worth reading because it documents what the maintainer considers finished work. There is a `build` target that compiles all targets with all features across the workspace, a `check-fmt` target running `cargo fmt --all -- --check`, and a `check-clippy` target that runs clippy across all targets and features with warnings denied. A `check` target combines the two, and a `clean` target runs `cargo clean`. The test targets are layered. `doc-test` runs the documentation tests, `unit-test` depends on it and adds the library tests, and `test` depends on that and runs the full set across all targets and features, with `--no-fail-fast` so one failure does not hide the rest. The help target prints a colourised list of the targets, which is a small thing that tells you the project expects people other than the author to run these commands.

Three things the project has not built yet

The TODO list at the end of the README is short and specific, and it is the most useful section for judging whether the tool fits your case. Lazy and streaming loading of Parquet files is not implemented, which means a large file is loaded rather than paged through, and the memory cost of a big file is the cost of holding it. Filtering columns by value in the visualize tab is not implemented, so the browsing experience is a table view without a query over it. And reading Parquet files from the cloud, with s3 paths, is not implemented either, which means the file has to be local. All three are on the list as unchecked boxes, so the honest reading is that this is a pre-1.0 tool with a working core and a clear sense of what comes next. The version numbering agrees: v0.0.2 in November 2025, v0.1.0 in August 2026, and v0.2.0 on 2026-09-16.

Where it sits against the alternatives

The realistic alternatives are a Python session with pyarrow or polars, a notebook, or DuckDB from the command line. The difference in approach is what you are optimising for. A Python session gives you full programmatic control and the entire ecosystem, but it is stateful, it is a script you write rather than a tool you run, and for a quick look at one file it is a lot of setup. A notebook is comfortable for exploring but heavy for a single inspection. DuckDB can query Parquet directly from the shell and is a better fit when you want to filter, aggregate or join, which is exactly the filtering that parqeye has not implemented. Where parqeye is stronger is in the metadata and row group views, which no shell query gives you in the same shape, and in the fact that it is a single Rust binary with no runtime, no interpreter startup and no configuration. The trade is capability for immediacy, and for a file you need to look at rather than query, that is a reasonable exchange.

What the repository contains and how it is packaged

The top level of the repository shows how small this is: a `.github/` directory with the CI workflow and the demo asset, a `Makefile`, a `Cargo.toml` and `Cargo.lock`, a `pyproject.toml` for the Python distribution, a `dist-workspace.toml` for the release tooling, a `CHANGELOG.md`, the `LICENSE`, the `README.md` and a `src/` directory. Two entries are worth a note. The `parquet-testing` directory alongside a `.gitmodules` file points at the Parquet test data, which is how the project can test against real files rather than synthetic ones. The `src/` directory holds the Rust source, and the crate structure is the standard one. Releases are produced with the dist tooling and the metadata sets the CI backend to GitHub, so the release pipeline runs on GitHub Actions. The project is MIT licensed, which for a developer tool that reads other people's data files is the right default.

Editorial conclusion

parqeye is the right tool for a data engineer who wants to check a Parquet file's contents and schema without starting a notebook, a Python session or a query engine, and the row group and metadata views are the part that makes it more than a table printer. It is the wrong choice for large files, because lazy and streaming loading is still on the TODO list, and for cloud data, because reading from s3 is also unfinished. Before you rely on it, check the file size against the missing streaming support, and remember the three TODOs in the repository rather than assuming the feature list is final. The last push was on 2026-09-16 with v0.2.0 released the same day, the code is MIT licensed, and the crate is built on edition 2024.

Frequently asked questions

Official sources

1. Issues
2. kaushiksrini/parqeye on GitHub
3. License: MIT
4. README
5. Releases