Polars.NET: a Rust DataFrame engine for .NET 10 that leans on LibraryImport

A community post from Feb 6, 2026 put Polars.NET on my radar: a DataFrame engine for .NET backed by the Rust Polars core, exposing both C# and F# APIs. The pitch is not “we have a DataFrame”. It is “we have a DataFrame that is honest about where the performance comes from”.

If you are building on .NET 10 and C# 14, the details are the whole story: stable C ABI, prebuilt native binaries across platforms, and modern interop via LibraryImport.

Why LibraryImport matters for high-volume interop

DllImport works, but it is easy to accidentally pay for marshaling and allocations on hot paths. LibraryImport (source-generated interop) is the .NET direction of travel: it can generate glue code that avoids runtime marshaling overhead when you stick to blittable signatures and explicit spans.

This is the pattern Polars.NET claims to use. A minimal example looks like this:

using System;
using System.Runtime.InteropServices;

internal static partial class NativePolars
{
    // Name depends on platform: polars.dll, libpolars.so, libpolars.dylib.
    [LibraryImport("polars", EntryPoint = "pl_version")]
    internal static partial IntPtr Version();
}

static string GetNativeVersion()
{
    var ptr = NativePolars.Version();
    return Marshal.PtrToStringUTF8(ptr) ?? "<unknown>";
}

The important part is not pl_version. It is the shape: keep the boundary thin, keep it explicit, and do not pretend interop is free.

Prebuilt native binaries are the adoption accelerator

Interop-based libraries die when you ask every user to compile native dependencies. Polars.NET explicitly calls out prebuilt native binaries for Windows, Linux, and macOS.

When you evaluate it, look for a NuGet layout like:

• runtimes/win-x64/native/polars.dll
• runtimes/linux-x64/native/libpolars.so
• runtimes/osx-arm64/native/libpolars.dylib

That is the difference between “cool repo” and “usable dependency in CI and on dev machines”.

The real question: can you keep the memory model predictable?

DataFrames are a memory story. For a Rust core + .NET surface, I look for:

• Clear ownership rules: who frees buffers, and when?
• Zero-copy paths: Arrow interchange is a good sign, but check where it is real.
• Exception boundaries: does a native error become a structured .NET exception?

If those are solid, Polars.NET becomes a practical way to bring Rust-grade vectorized execution to .NET workloads without rewriting everything.

Sources:

• Polars.NET repository
• Reddit thread