Corvidae DB

Embedded columnar database built in Rust with a split-engine architecture: ECS for writes, DataFusion over sealed Parquet for reads. The two engines each do what they do well, with an immutable boundary between them.

Corvidae-DB is an embedded columnar database built in Rust. The crate compiles into the host binary, data lives on the local filesystem, and there's no daemon, separate service, or network dependency.

The architecture has two engines with a seal between them. The write side works like a game engine: a row starts in the fast RAM layer where it does its thing until it's ready to be saved, gets added to a Write-Ahead Log for durability, and then gets despawned from the engine once it's flushed out to a Parquet file. On the read side, those Parquet files are the storage, and DataFusion runs SQL queries against them. The seal between engines is total. In-flight ECS data is never visible to queries; the read surface is a snapshot at open time, advanced only when the writer flushes.

ECS fits the write side because the problem is fundamentally about entity lifecycle. A row has state that changes through phases: arriving, becoming durable, becoming queryable, leaving the live world. Component composition handles this state machine without requiring a custom one; spawn is cheap, change detection is built in, and the scheduler runs systems in parallel where they don't conflict.

corvidae-db is built for append-only workloads with batched durability and analytical reads. That covers a substantial class of real-world data shapes: application logs, event streams, telemetry, sensor data, training data, conversation history, audit trails. All of these share a pattern: rows accumulate over time, and value comes from querying the accumulated history rather than mutating individual rows. The included example, memory_coordinate_store, builds out one instance: a structured schema for LLM conversation history that stores embedding vectors as a column type and provides similarity search through a registered query function.

The architecture isn't scale-limited. ECS write throughput, columnar Parquet, and DataFusion all scale with hardware, and a TCP gateway mode supports many client processes writing to a single server. The constraints that remain are deliberate, not architectural. The seal keeps the read path simple by having only one source of truth: rows are immutable once written, there's no transactional consistency across rows, and reads don't see writes until the next flush. Exposing live mutations would require a second query surface with its own consistency story; that's real engineering, and the current design refuses the cost. The path stays open if a use case earns the work.

Four dependencies do the heavy lifting (bevy_ecs, arrow, parquet, datafusion). The project refuses most common conveniences in favor of small stdlib replacements: hand-rolled errors instead of anyhow, FNV-1a hashing instead of uuid, Arrow IPC as the WAL format instead of serde. The point isn't minimalism; it's keeping the maintenance surface small so the project doesn't rot quietly as upstream dependencies churn.

The repository is private. It's available to recruiters and collaborators on request — reach out at contact@usuallyinflux.dev.