parquet-dotnet: an Apache Parquet library written for .NET rather than around it

Written for .NET rather than wrapped around .NET

Parquet.Net is described as a fully managed, safe, extremely fast .NET library to read and write Apache Parquet files, designed for the .NET world and explicitly not a wrapper. The package is published on NuGet under the name Parquet.Net, and the documentation lives at the author's own site rather than on a shared docs host.

The not-a-wrapper framing is the substantive claim, and the rest of the feature list follows from it. The first item is zero dependencies, described as a pure library that just works anywhere .NET works, on desktops, servers, phones and watches. The target runtimes are modern .NET only, such as .NET 10 and .NET 8, which is a deliberate narrowing. Parquet.Net does not target the .NET Standard surfaces that some other Parquet libraries still carry for Xamarin and Unity users, so a project still on those targets is out of scope.

That combination, no dependencies and modern-only targets, is what makes the package practical to drop into an application. A Parquet reader that drags in a compression library and a native codec is a set of deployment questions; a managed implementation with the encodings and compressions built in is one assembly.

The audience is a .NET developer who has to read a Parquet file from Spark or write one for a data pipeline, and who would rather not take a dependency on a native library or a Java implementation to do it.

Dynamic schemas and three levels of API

The feature list names two things that separate this library from a thin reader.

The first is dynamic schemas, described as the only library that supports them. A static schema means the shape of the data is known when the file is written and the columns have fixed names and types. A dynamic schema means the schema can vary, which matters for the real world of data engineering where a column appears in one day's export and not the next.

The second is the number of API levels: low-level, high-level and untyped. The low-level API works with columns and encodings directly, the high-level API serialises C# classes, and the untyped API sits between them for data whose shape you know at run time but not at compile time.

The high-level API supports class serialisation for all simple and complex Parquet types, which the README points out explicitly as a distinguishing feature. Complex types matter here because Parquet has nested structures, lists and maps, and mapping those onto a C# object model is where a naive implementation falls down.

Two more features belong to the same category. There is access to file and column metadata, so a reader can inspect a file before deciding how to read it, and encodings can be fine-tuned per column, which is a real performance lever when a file mixes a dictionary-encoded string column with a plain numeric one.

Format coverage and the performance claim

The README states that Parquet.Net supports all Parquet types, encodings and compressions, and that it is designed to utilise .NET and made for .NET developers.

The performance section is where a reader should be careful. The README says the library is really fast, faster than Python and Java and alternative C# implementations, and even faster than native C++ implementations, with hardware acceleration added in more and more places.

That is a claim from the project's own README, with no methodology, no workload description and no numbers attached to it in the text available here. Parquet read and write performance depends heavily on the data: a file with a few wide dictionary-encoded columns behaves differently from one with thousands of narrow ones, and compression ratios change the picture again. The repository does contain a perf/ directory and a scripts/ directory, so the tooling for measuring exists, and a reader who cares should look there rather than take the sentence on trust.

The more defensible part of the same claim is the shape of the implementation. A fully managed library has no native codec to deploy and no cross-process boundary, so it fits into a container image or a serverless function without extra work. For many .NET teams that practicality is the deciding factor rather than the last few percent of throughput.

The DataFrame support is a further integration point: the README lists integration with DataFrames, Microsoft.Data.Analysis, which means Parquet data can move into the .NET DataFrame ecosystem rather than being converted by hand.

Who is actually using it

The Used by section is the most informative part of the README, because it lists projects rather than adjectives.

Among them are RavenDB, described as an ACID NoSQL document database, and ML.NET, the machine learning framework for .NET. Both are projects where a Parquet implementation is on a critical path rather than a convenience: a document database that ingests Parquet exports, and a machine learning pipeline that reads columnar training data. The Cosmos DB Desktop Data Migration Tool uses it too, and PSParquet is a PowerShell module for Parquet, and ParquetViewer is a Windows desktop application for viewing and querying Parquet files.

The rest of the list shows the range. Cinchoo ETL is an ETL framework, FastBCP exports to Parquet in parallel from Oracle, SQL Server, MySQL, PostgreSQL, ODBC, Teradata, Netezza, SAP HANA and ClickHouse from one command line, and Kusto-loco is a C# KQL query engine. Parquet.FSharp adds first-class support for F# types such as records, options, lists and discriminated unions, and DeltaIO is the author's own Delta Lake implementation in pure .NET.

Two observations. First, the mix of a document database, a machine learning framework and a data migration tool tells you the library is used where the data volume justifies a columnar format, not for small files. Second, a PowerShell module and a desktop viewer tell you it is also used for one-off inspection, which is a different requirement: a library that is fast on large files is often awkward on small ones, and the fact that both kinds of consumer exist is a sign that the API handles both.

The list ends with an invitation to raise a pull request to appear there, which is how the section stays current.

The rule about LLMs, and what it tells you

The IMPORTANT notice at the top of the README is unusual enough to be worth quoting closely. The project does not use LLMs for writing code. It will not accept LLMs for issues. No pull requests written by LLMs will be accepted. No LLMs for comments anywhere. Attempts to circumvent this may prevent future contributions to the repository.

That is a contributor policy, and it is the author's right to set one. It also carries consequences for anyone planning to use the project, because it signals how contributions will be reviewed and how fast.

A repository with a single primary maintainer, an explicit refusal of machine-generated pull requests, and a policy that comments must not contain LLM output is going to have a human review bottleneck. That is a real consideration for a library where you might otherwise expect a steady stream of community fixes, and it is worth weighing against the alternative of choosing a Parquet implementation with a larger contributor base.

The notice also explains part of the repository's shape. The topics list includes a no-ai marker and a no-ai-allowed marker.

None of this says anything about the code. The used-by list, which is checkable, is the better basis for a decision.

Licence, releases and the shape of the tree

The licence field on the repository says MIT, with the LICENSE file at the top of the tree. For a library you reference from a proprietary application, that is the simplest possible arrangement, with the usual obligation to keep the copyright notice with redistributed copies.

The release record shows an active 6.x line: 6.1.0 on 2026-08-11, 6.0.3 on 2026-05-13 and 6.0.2 on 2026-05-07. The repository is not archived and the last push was on 2026-08-25, so the code is being worked on, and the 6.1.0 release suggests the major rewrite to a fully managed implementation has landed rather than being announced as a plan.

The tree is small and tells you the shape of the work: src/ for the implementation, docs/ for the documentation, perf/ for the performance work that the performance claims rest on, scripts/ for the build and release automation, and tools/ for supporting tools.

The one thing the README does not spell out is the compatibility story across versions. Parquet has accumulated a large set of optional extensions over the years, and a library that positions itself on complete format coverage has to decide, for each one, whether to read it, write it or refuse it. The documentation site is where that is described, and for anyone whose data comes from a variety of writers, that reference is the thing to read before choosing the library over reading the file with something else.

Editorial conclusion

parquet-dotnet suits a .NET team that reads or writes Parquet files as part of a product, and that wants a library with no third party dependencies and support for modern .NET runtimes. It does not suit a project that needs the older .NET Framework or .NET Standard targets that other Parquet libraries still carry, and it does not suit a team whose contribution process depends on automated tooling for pull requests. Before adopting, open the documentation site linked from the README, check the release notes for 6.1.0 and 6.0.3 to see what changed in the managed rewrite, and decide whether you need the high level class serialization or the low level column-oriented API before you write any code against it.

Frequently asked questions

Official sources

1. aloneguid/parquet-dotnet on GitHub
2. Issues
3. License: MIT
4. README
5. Releases