Data teams often split closely related work across batch jobs, streaming systems, and separate incremental pipelines. Krishiv is being built around a different shape: one compute framework with a shared data model and explicit runtime seams.
What exists now
Krishiv has implemented batch SQL foundations, streaming APIs and windowing examples, explicit embedded, single-node, and distributed runtime modes, scheduler and executor crates, shuffle, state, and checkpoint abstractions, and Python bindings.
Iceberg is the primary lakehouse target. Kafka, Parquet, S3 and object-store, and catalog integrations retain Preview maturity where end-to-end certification is still pending.
Why Rust, Arrow, and DataFusion
Rust and Tokio provide the runtime foundation. Apache Arrow RecordBatch is the columnar data model and IPC shape. DataFusion provides SQL parsing, planning, expressions, and local execution.
That lets Krishiv concentrate its Engine work on placement, dataflow, state, shuffle, checkpoints, and connector boundaries instead of rebuilding the entire query stack.
Batch, streaming, and incremental processing
Batch SQL is available in the source workspace. Stateful streaming remains Preview. DeltaBatch and IncrementalFlow provide Experimental incremental view maintenance based on weighted Arrow rows.
Distributed execution and connector guarantees depend on the exact runtime, storage, source, sink, state, and checkpoint combination being evaluated.
Where to go next
Read the Engine docs for current APIs, the architecture page for system boundaries, and the maturity matrix before depending on a Preview or Experimental path.
The public copy stays deliberately conservative: no invented benchmarks, competitor comparisons, availability dates, or unsupported guarantees.