PandRS 0.3.0 Released — Pure Rust DataFrames, Now C-SQLite-Free

The DataFrame layer of the COOLJAPAN scientific stack just shed its last C dependency in the I/O surface.

Today we released PandRS 0.3.0 — a minor release with one big breaking change: PandRS ripped out its entire SQL/database stack to become C-SQLite-free, then modernized the columnar engine underneath.

No C. No Cython. No C SQLite. No Python GIL.
No libsqlite3-sys to compile. No bundled SQLite to link.
Just a pandas-class DataFrame that compiles to a single static binary (or WASM) and runs everywhere — laptops, browsers, edge devices, and clusters.

Why PandRS 0.3.0 matters

For a DataFrame library that prides itself on being Pure Rust, the SQL stack was the awkward exception. Pulling in sqlx and rusqlite dragged libsqlite3-sys along with them — and libsqlite3-sys is a full C SQLite build. That meant a C compiler in the loop, platform-specific link steps, and a feature surface that quietly broke the “single static binary” promise the rest of PandRS keeps.

0.3.0 cuts that drag away:

• The sql feature, the entire src/io/sql/ module, the database connector, sql_backup.rs, the SqlOps and SqlConnection traits, and all the database examples and tests are gone.
• With them go sqlx, rusqlite, and libsqlite3-sys — no C SQLite to build or link, on any platform.
• The default and feature surface now moves decisively toward 100% Pure Rust. The columnar I/O paths that remain — CSV, Parquet, Arrow, JSON — carry the load instead.

On top of the purge, the columnar engine got a fresh coat of paint: Arrow/Parquet jumped to 58.1 and DataFusion to 53.0, keeping the distributed query and columnar I/O layers current with the wider Arrow ecosystem.

Technical Deep Dive: A Cleaner Pure Rust DataFrame After the SQL Purge

1. The Pure Rust I/O surface.
With the SQL connector removed, PandRS standardizes on columnar and text formats for data exchange: CSV, Parquet, Arrow, and JSON. Parquet is now the recommended columnar path — it replaces what the removed SQL feature used to cover, with no C SQLite to link. Excel I/O via calamine (0.32 → 0.34) remains in place for spreadsheet workflows. Series and DataFrame keep their columnar storage with string pooling underneath.

2. The modernized columnar/distributed engine.
The columnar core tracks the Arrow ecosystem closely. This release bumps parquet/arrow from 57.3 to 58.1 and datafusion from 52.2 to 53.0, refreshing the distributed query engine and the Parquet reader/writer in one pass. A deprecated Parquet API was migrated along the way (set_max_row_group_size → set_max_row_group_row_count).

3. The SciRS2 0.4.0 integration tier.
The optional scirs2 feature — which routes statistics and linear algebra through scirs2-core, scirs2-stats, and scirs2-linalg — moves from SciRS2 0.3.1 to 0.4.0. PandRS now sits on the same SciRS2 0.4.0 line as NumRS2, keeping the scientific stack coherent from arrays through DataFrames.

4. Leaner builds and the Cranelift 0.130 JIT.
0.3.0 adds a global debug-info reduction via .cargo/config.toml, trimming build size across the workspace. The optional JIT layer moves to Cranelift 0.130, and the async runtime to Tokio 1.50. Compatibility fixes round it out: the rand 0.10.x API (RngExt imports) and the toml parser (0.9.10 → 1.1.0) are both current.

Getting Started

cargo add pandrs

use pandrs::{DataFrame, Series};

fn main() -> pandrs::error::Result<()> {
    let mut df = DataFrame::new();
    df.add_column(
        "product".to_string(),
        Series::from_vec(vec!["Widget", "Gadget", "Gizmo"], Some("product")),
    )?;
    df.add_column(
        "units".to_string(),
        Series::from_vec(vec![1200, 980, 1540], Some("units")),
    )?;

    // No C SQLite to link — columnar I/O is the Pure Rust path
    let top = df.filter("units > 1000")?;
    let total: i64 = df.column("units")?.sum()?;
    println!("{} top products, {} units total", top.shape().0, total);
    Ok(())
}

The same DataFrame/Series API you already know — now with a Pure Rust I/O surface and no C SQLite anywhere in the build.

What’s New in 0.3.0

• BREAKING — Pure Rust purge of the SQL/database stack. Removed all SQL/database dependencies (sqlx, rusqlite, libsqlite3-sys), the sql module (src/io/sql/), sql_backup.rs, the database connector, the SqlOps and SqlConnection traits, the sql feature flag, and all database examples and tests. Migration: if you were on the sql feature, move off it — use CSV/Parquet/Arrow I/O, or an external DB layer outside PandRS.
• Dependency modernization: parquet/arrow 57.3 → 58.1, datafusion 52.2 → 53.0, cranelift 0.129 → 0.130, tokio 1.48 → 1.50, calamine 0.32 → 0.34, toml 0.9.10 → 1.1.0, scirs2-* 0.3.1 → 0.4.0, cudarc 0.19.3 → 0.19.4, tempfile 3.26 → 3.27.
• Added a global debug-info reduction (.cargo/config.toml) for smaller build size.
• Fixed: rand 0.10.x API compatibility (RngExt imports); migrated a deprecated Parquet API (set_max_row_group_size → set_max_row_group_row_count).

Tips

• Migrating off the removed sql feature? There is no in-tree database connector anymore. Read and write through Parquet, Arrow, or CSV, and keep any database access in an external layer that hands DataFrames to PandRS.
• Columnar I/O lives behind a flag. Enable the parquet feature for Parquet read/write — it is the recommended columnar path now that the SQL route is gone.
• Stats and linalg are on SciRS2 0.4.0. Turn on the scirs2 feature to route statistics and linear algebra through the upgraded scirs2-core/scirs2-stats/scirs2-linalg 0.4.0.
• Your default build is leaner. With the SQL/C-SQLite dependencies gone and debug-info reduction in place, the default build is smaller and links faster — no C compiler required.
• Distributed query? Enable the distributed feature to pull in the DataFusion 53.0 engine for larger-than-memory and parallel query workloads.

This is the foundation

PandRS is the DataFrame layer of the COOLJAPAN scientific stack, now on SciRS2 0.4.0 alongside NumRS2:

• SciRS2 — the scientific computing core PandRS routes stats and linalg through
• NumRS2 — the numerical/array layer, on the same SciRS2 0.4.0 line
• OptiRS — optimization workloads fed by DataFrame pipelines
• OxiMedia — media and signal data flowing into columnar frames
• SkleaRS / TenfloweRS / TrustformeRS — ML and modeling on top of the data layer
• Pure Rust building blocks — oxiarc, oxifft, oxiz, oxiblas, oxicode — and recent additions like oxionnx and oxiwhisper

Repository: https://github.com/cool-japan/pandrs

Star the repo if you want pandas-class DataFrames without C SQLite, Cython, or Python overhead in your build.

Pure Rust DataFrames are here — fast, safe, and sovereign.

— KitaSan at COOLJAPAN OÜ March 27, 2026