QIHSE is a native C database ecosystem and a systems engineering showcase built around a single, uncompromising rule:
Approximation is allowed to propose candidates. It is not allowed to silently decide truth.
Modern applications often suffer from the "impedance mismatch" of stitching together a half-dozen specialized databases—a vector DB for AI, Redis for caching, PostgreSQL for documents, and Kafka for events. QIHSE eliminates this fragmentation. It is not a cosmetic ANN wrapper or a patchwork of microservices. It is a fully fortified, multi-modal database system combining eight distinct storage engines within the exact same process space.
Everything is natively orchestrated. Fast paths are visible. Memory is strictly managed. And data travels from the network interface straight to the computation layer with zero intermediate copies.
QIHSE seamlessly weaves together eight specialized compute engines to handle any workload you can throw at it:
- The Vector DB: Acting as the optic nerve of the engine, it uses an exactness-first
float32core. Accelerators like Trinary signatures (qtri/qmag), INT8 quantization, and sparse indexing act as execution layers that rapidly reduce the search space before an authoritative, exact rerank. - The Key-Value Store: An O(k) Trinary Trie memory engine backed by native LSM-Trees and SSTable persistence for instantaneous, lock-free lookups.
- The Document Store: A JIT-compiled JSON document engine that translates hot access patterns directly into executing bytecode.
- The Time-Series DB: Lock-free ingress buffers paired with Gorilla XOR bit-packing act as a temporaӏ sink to absorb massive telemetry streams effortlessly.
- The Columnar Engine: An AVX-accelerated OLAP backend utilizing strided OS page alignments for massive aggregations and Run-Length Encoding sweeps.
- The Graph Engine: Multi-hop traversal routed dynamically via Anchor and HNSW algorithms.
- The FTS Engine: Zero-copy lexical tokenization with native BM25 scoring for pinpoint full-text search.
- The Event Stream: A raw, append-only log engine bypassing user-space entirely via Linux
mmapandsendfileDMA, effectively policing the karma of system events.
To drive these engines without trashing the CPU cache, QIHSE invented the Unified Wire Protocol (UWP). UWP is a strictly binary, memory-aligned protocol that maps incoming network packets directly to internal C structs. It employs pthread detachment and SO_RCVTIMEO kernel enforcement to block Slowloris attacks, ensuring data traverses the network into the engines with blistering, zero-copy efficiency.
UWP routes these database families explicitly:
| Target | Engine | Current command |
|---|---|---|
0x01 |
Key-Value Store | Set |
0x02 |
Vector DB | Upsert |
0x03 |
Document Store | Insert JSON |
0x04 |
Columnar Engine | Append float32 |
0x05 |
Time-Series DB | Insert point |
0x06 |
Graph Engine | Reserved target |
0x07 |
Event Stream | Append event |
The QIHSE sync replication layer currently serializes KV set and vector set payloads over the internal cluster path while the remaining engines are served through UWP or their native APIs.
QIHSE treats search like a low-level systems problem rather than a dashboard feature.
The engine acts as a hierarchical memory laboratory: per-vector access tracking (vectors.qtier) allows hot/cold temperatures to automatically drive memory maintenance across Unified (UMA) and Heterogeneous (HMA) Memory Architectures.
And crucially, it degrades gracefully. The build system natively supports AVX-512 and AVX2/FMA instructions for extreme parallel throughput. However, if your system lacks these features (like older Intel chips, ARM processors, or constrained VMs), QIHSE detects this at runtime and seamlessly falls back to highly optimized scalar math. It works flawlessly on any system.
⚠️ TEMPORARY INFRASTRUCTURE ADVISORY Due to a recent "unfortunate incident" involving the primary testing laptop (we're totally blaming the NSA for this one 😉), direct access to NPU/GNA silicons and AVX-512 pipelines is currently unavailable. While these pathways are implemented, they are not currently fully tested, optimized, or fleshed out under the strict Omni-Test harness. A repair is currently planned for the laptop, so we will have these pathways fully remedied and verified soon! In the meantime, the engine correctly and automatically routes all execution to the fully validated AVX2/FMA and scalar pipelines.
To keep this showcase clean, all intensive code examples, API usage, and benchmark commands live in our detailed documentation suite:
- API Reference: Comprehensive C API maps for Vector DB, UWP, KV Store, and Document components.
- Python Native SDK: Zero-overhead Python bindings utilizing CPython to expose the engine, proxies, and Supernatural Auth Gates directly to Python space.
- Persistence Model: File formats, WAL structure, and engine durability.
- Onboarding & Building: Instructions for compiling, running test suites, and executing benchmark harnesses (
make test-persist,make bench-micro, etc.). - Trinary Policy Rationale: The theory behind
qmagcandidate selection.
Most users will never need to think about this feature—by default, QIHSE grants full access so you can build fast. If you don't need it, it stays completely out of your way.
However, for those building intelligence, defense, or ultra-secure forensic systems, QIHSE natively supports US / Five Eyes / SCI compartmentation woven directly into the low-level data plane. Every single record can carry a Classification Boundary and SCI bitmask.
This is not a gateway filter. The clearance check is the absolute first mathematical operation in the pipeline. Built with paranoia-level self-protections, if a user queries a key or vector they lack clearance for, the system executes an identical algorithmic path as if the data simply did not exist. There are zero timing leaks, and unauthorized users mathematically cannot deduce the existence of classified data. Even the most muscular network taps will see nothing but uniform algorithmic noise.
Read the full Security Architecture deep dive here.
QIHSE natively supports cryptographic logging for all security-relevant access and clearance modifications.
- Stealth Integrity & CNSA 2.0 Lockdown: To achieve CNSA 2.0 standard integrity checks, the engine stores an append-only, SHA-256 hash chain of the entire auth log state in a highly obfuscated camouflage file (
.DS_Store). Every time theqihse_auth.datlog is modified, this stealth hash is updated. If an adversary tampers with the binary log, the engine will detect the hash mismatch immediately and violently lock down the entire execution process until a God-Mode Operator (Role 0) or Hardware-Token Analyst (Role 1) physically intervenes at the terminal to resume execution. - Silent Callout Webhook: Every time non-UNCLASSIFIED data is accessed, a pure C native raw TCP socket fires a silent HTTP POST payload to
http://127.0.0.1:8080/callout. This happens natively without spawning externalcurlor shell processes, leaving absolutely zero trace in process execution audits (like Sysmon or Auditd). If no webhook listener is configured, the callout simply drops into the void—normal users won't even notice the feature exists.- Note: You must update
qihse_audit.cto point to your actual webhook listener URL and configure the expected data ingestion contract. The payload format sent is:{"event":"classified_access", "user_id":<UID>, "classif":<LEVEL>, "sci":<COMPARTMENTS>}.
- Note: You must update
QIHSE is licensed under AGPL-3.0. Read LICENSE before use.
Personal, research, and compliant self-hosted use is welcome under the license. Commercial, proprietary, closed-source, hosted, or derivative use requires written permission or a separate license first. Unauthorized commercial use, relicensing, removal of attribution, or repackaging outside the license is not permitted and will be pursued to the maximum extent of the law.
