◉ COOLJAPAN
← All posts
July 18, 2026 • 10 min read

OxiSQL 0.4.0 Released — Exact Full-Triple Dependency Floors, and a Reproducible 0.4.x Baseline a Stale Cargo.lock Can't Break

OxiSQL — the COOLJAPAN ecosystem's sovereign Pure-Rust SQL layer and C-free SQLite-compatible engine — ships 0.4.0: every inter-crate dependency floor across all 17 crates is pinned to the exact full-triple 0.4.0, a clean 0.4.x baseline no stale Cargo.lock can break. A packaging bump, no source changes since 0.3.3.

release oxisql pure-rust cooljapan noffi sql database postgres mysql sqlite datafusion

A version requirement that the resolver happily satisfies with the wrong crate is not a convenience — it is a latent build break waiting for a stale Cargo.lock. OxiSQL 0.4.0 ships exactly zero lines of new engine code and closes that gap for the entire 17-crate family, permanently.

Today — July 18, 2026 — we released OxiSQL 0.4.0, the sovereign Pure-Rust SQL layer for the COOLJAPAN ecosystem. It is a packaging and release-hygiene minor bump with no source-code changes since 0.3.3: the engine, the wire protocols, and the public oxisql API are byte-for-byte identical. What changed is the dependency metadata. Every inter-crate dependency floor across all 17 crates is now pinned to the exact full-triple 0.4.0 — resolving to >= 0.4.0, < 0.5.0 — instead of the loose minor-only caret "0.4", giving the whole family one clean, reproducible baseline.

No C. No Fortran. No libpq, no libmysqlclient, no libsqlite3, no zstd-sys — OxiSQL’s dependency graph is exactly as C-free in 0.4.0 as it was in 0.3.3, because at the source level it is 0.3.3: the same C-free oxisqlite engine, the same Pure-Rust tokio-postgres and mysql_async wire clients, the same OxiTLS-routed TLS, the same open_from_bytes, the same PostgreSQL logical replication. 0.4.0 does not touch a line of it. It moves version numbers — and it moves them for a specific, load-bearing reason.

Why a packaging release earns a minor bump

A version that “resolves” is not the same as a version that builds. Until this line was drawn, the OxiSQL family carried a quiet trap in its own dependency metadata:

OxiSQL 0.4.0 makes that fix the permanent shape of the family:

Technical Deep Dive: where the version numbers actually moved

  1. The workspace manifest. The root Cargo.toml bumped [workspace.package].version to 0.4.0 and rewrote every [workspace.dependencies] inter-crate entry — oxisql-core, oxisql-parse, oxisql-embedded, oxisql-postgres, oxisql-mysql, oxisql-datafusion, oxisql-pool, oxisql-migrate, oxisql-sqlite-compat, and the oxisqlite / limbo_ext / limbo_macros engine paths — to carry the exact version = "0.4.0" alongside their path =.
  2. The engine’s internal chain. The floors that the 0.3.3 incident exposed one level at a time are now all exact: oxisql-sqlite-compat → oxisqlite, oxisqlite → oxisqlite-core, and oxisqlite-core → oxisqlite-sqlite3-parser / oxisqlite-time / oxisqlite-uuid. No link in that chain can resolve to a pre-0.4.0 sibling.
  3. The semver home for two internal breaking changes. 0.3.3 changed the shape of two low-level engine types: oxisqlite’s Params::Named moved its key type from String to Cow<'static, str> (so binding a 'static placeholder name borrows instead of allocating), and oxisqlite-sqlite3-parser’s lexer Token dropped its lifetime parameter (Token<'i>(usize, &'i [u8], usize) → Token(usize, Cow<'static, str>, usize)). Both are internal to the engine and parser beneath oxisql-sqlite-compat — the facade-level Connection::query_named / execute_named API is untouched — but a breaking change belongs behind a minor bump, and 0.4.0 provides one.
  4. What did not change: everything else. crates/*/src is byte-for-byte identical between the 0.3.3 and 0.4.0 tags. Engine behavior, wire protocols, and the public oxisql surface are the same code you were already running — this is a packaging-metadata release, and nothing more.

Getting Started

cargo add oxisql --features sqlite,pool-sqlite-compat

Or pin the exact baseline in Cargo.toml:

[dependencies]
oxisql = { version = "0.4.0", features = ["embedded", "postgres", "pool-embedded", "migrate"] }

The C-free SQLite path — the same oxisqlite engine, unchanged — supports real transactional ROLLBACK:

use oxisql::SqliteConnection;
use oxisql::prelude::*;

#[tokio::main]
async fn main() -> Result<(), oxisql::OxiSqlError> {
    let conn = SqliteConnection::open_memory().await?;
    conn.execute("CREATE TABLE t (id INTEGER, name TEXT)", &[]).await?;

    // BEGIN ... ROLLBACK discards the INSERT.
    conn.execute("BEGIN", &[]).await?;
    conn.execute("INSERT INTO t VALUES (1, 'Alice')", &[]).await?;
    conn.execute("ROLLBACK", &[]).await?;

    let rows = conn.query("SELECT COUNT(*) FROM t", &[]).await?;
    println!("rows after ROLLBACK: {:?}", rows); // → one row holding COUNT(*) = 0
    Ok(())
}

Everything 0.3.3 added is exactly where you left it — including open_from_bytes, which opens a database straight from an in-memory image with no temporary file:

use oxisql::SqliteConnection;

#[tokio::main]
async fn main() -> Result<(), oxisql::OxiSqlError> {
    let image: &[u8] = include_bytes!("bundled.sqlite");
    let conn = SqliteConnection::open_from_bytes(image).await?;
    let rows = conn.query("SELECT count(*) FROM sqlite_master", &[]).await?;
    println!("{:?}", rows);
    Ok(())
}

Reach the same engine through the facade with oxisql::connect("sqlite::memory:") or oxisql::connect("sqlite://path/to/file.db").

What’s New in 0.4.0

Tips

This is the foundation

OxiSQL’s facade/driver layer is 10 crates sitting on the 7-crate, C-free oxisqlite-* engine, alongside a perf benchmark crate and two vendored [patch.crates-io] shim crates (whoami-patched and zstd-shim) that keep the --all-features build genuinely C-free; the TLS crypto provider now arrives CVE-clean directly from OxiTLS, so no rustls patch is needed here anymore. As of 0.4.0 — source-identical to 0.3.3 — that is 2,157 tests passing with default features, 2,651 with --all-features, 0 failing, 0 clippy warnings, across roughly 178,591 lines of Rust in 484 source files.

OxiSQL itself sits on OxiTLS (transport/TLS), oxicode (row serde), OxiCrypto (encryption-at-rest), and OxiStore (lower storage layer). It is depended on by oxirouter, oxirs, oxify, oxigdal-db-connectors, oximedia, oxigaf, and oxirag — the database tier each of those reaches for when it needs SQL. A family that whole depends on resolving as one; 0.4.0 is the release that guarantees it always does.

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

Star the repo if you want a SQL layer where “the versions resolved” and “the code compiled” are the same promise, and a stale lockfile can never quietly pair a new caller with an old engine again.

The era of a green resolve hiding a red build is over. Pure Rust SQL — sovereign, safe, and now pinned to one clean, reproducible baseline — is here.

— KitaSan at COOLJAPAN OÜ July 18, 2026

↑ Back to all posts