You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
🚀 Release v3.1.0: The Spatial AI Engine (Zero-OOM, Lorentz Geometry, & MRL Cascade)
#9
Vector databases are hitting a wall. Flat Euclidean spaces fail to model complex reasoning hierarchies, and storing bloated 1536D dense vectors alongside JSON metadata in RAM leads to catastrophic Out-Of-Memory (OOM) errors at scale.
We are thrilled to announce HyperspaceDB v3.1.0. This release officially transitions HyperspaceDB from a semantic search index into a full-fledged Spatial AI Engine built for agentic swarms, massive enterprise RAG, and edge devices.
Here is what makes this release a game-changer.
🤯 1. The RAM Diet: 50x Memory Reduction via Schema-Driven MRL
We have entirely solved the RAM bloat problem. HyperspaceDB is the only engine natively built for Matryoshka Representation Learning (MRL).
Instead of holding massive vectors in memory, our engine automatically slices your embeddings. The lightweight navigation core (e.g., 64d or 129d) stays in ultra-fast RAM, while the heavy semantic tail streams dynamically from NVMe SSDs or S3 during the final re-ranking stage.
The Result: Under concurrent workloads with 100,000 vectors, HyperspaceDB consumes only ~72.0 MB of RAM, compared to >3,000 MB required by legacy databases like Chroma or Milvus. This slashes your cloud infrastructure bills by up to 95%.
🌌 2. First Hybrid Hyperbolic Database (Spatial Reasoning)
Stop forcing LLMs to guess hierarchical relationships. HyperspaceDB introduces the 801D Hybrid Vector architecture (33D Lorentz + 768D Euclidean MRL).
We natively support Poincaré disks and Lorentz hyperboloids directly inside the index.
Agentic systems can now map strict taxonomies (like legal codes or medical trees) into negative curvature geometry.
With our new MathSDK, developers get access to Riemannian math primitives: Geodesic path tracing, Parallel Transport, and Fréchet Mean calculations for continuous agent memory consolidation.
🗄️ 3. The End of the "Two-Database Problem" (Sidecar Payload)
You no longer need to glue Pinecone and MongoDB together with duct tape.
HyperspaceDB introduces Sidecar Document Storage. You can store massive raw texts, JSON objects, and chat histories directly in the index.
The engine automatically compresses this data (Zstd) and pushes it to fractal chunks (.hyp) on the disk. You get the microsecond speed of a vector engine and the convenience of a Document DB in one single binary.
🛡️ 4. Zero-Latency Pre-Filtering (Typed Metadata)
Parsing bloated JSON metadata during an HNSW graph traversal kills query performance. We fixed this with Typed Metadata.
Strict scalar types (int, bool, enum) are compiled directly into the HNSW graph nodes in RAM.
This provides a hardware-level Single-Stage Pre-Filter before mathematical distances are even calculated, ensuring 100% recall and strict B2B multitenancy isolation with zero QPS drop.
🐝 5. Surviving the Swarm (1000+ Concurrent Clients)
Designed for multi-agent architectures, our Rust-native, lock-free HNSW implementation refuses to bottleneck.
L0/L2 Cache Accelerator: A dual-tier caching system combines a ~1µs L1 DashMap with an automatic background HNSW graph cache.
Under extreme stress tests of 1,000 simultaneous active clients, HyperspaceDB maintains over 9,400 QPS with a p99 latency of just 11.83 ms. Competitors under the same load face lock contention, with latencies skyrocketing over 2,000 ms.
🌍 6. Edge-First & WASM Ready
HyperspaceDB is completely hardware-agnostic. You can run the entire spatial index locally on a $35 Raspberry Pi or ARM64 IoT hardware. It boots in under 10ms, operates stably on 512MB RAM with zero external dependencies, and features 256-bucket Merkle Tree XOR Sync for low-bandwidth edge-to-cloud updates.
SDKs: We offer native, zero-friction clients for Python, Rust, and Go, with official integrations for LangChain, LlamaIndex, and the Model Context Protocol (MCP).
reacted with thumbs up emoji reacted with thumbs down emoji reacted with laugh emoji reacted with hooray emoji reacted with confused emoji reacted with heart emoji reacted with rocket emoji reacted with eyes emoji
Uh oh!
There was an error while loading. Please reload this page.
Vector databases are hitting a wall. Flat Euclidean spaces fail to model complex reasoning hierarchies, and storing bloated 1536D dense vectors alongside JSON metadata in RAM leads to catastrophic Out-Of-Memory (OOM) errors at scale.
We are thrilled to announce HyperspaceDB v3.1.0. This release officially transitions HyperspaceDB from a semantic search index into a full-fledged Spatial AI Engine built for agentic swarms, massive enterprise RAG, and edge devices.
Here is what makes this release a game-changer.
🤯 1. The RAM Diet: 50x Memory Reduction via Schema-Driven MRL
We have entirely solved the RAM bloat problem. HyperspaceDB is the only engine natively built for Matryoshka Representation Learning (MRL).
Instead of holding massive vectors in memory, our engine automatically slices your embeddings. The lightweight navigation core (e.g., 64d or 129d) stays in ultra-fast RAM, while the heavy semantic tail streams dynamically from NVMe SSDs or S3 during the final re-ranking stage.
The Result: Under concurrent workloads with 100,000 vectors, HyperspaceDB consumes only ~72.0 MB of RAM, compared to >3,000 MB required by legacy databases like Chroma or Milvus. This slashes your cloud infrastructure bills by up to 95%.
🌌 2. First Hybrid Hyperbolic Database (Spatial Reasoning)
Stop forcing LLMs to guess hierarchical relationships. HyperspaceDB introduces the 801D Hybrid Vector architecture (33D Lorentz + 768D Euclidean MRL).
We natively support Poincaré disks and Lorentz hyperboloids directly inside the index.
Agentic systems can now map strict taxonomies (like legal codes or medical trees) into negative curvature geometry.
With our new MathSDK, developers get access to Riemannian math primitives: Geodesic path tracing, Parallel Transport, and Fréchet Mean calculations for continuous agent memory consolidation.
🗄️ 3. The End of the "Two-Database Problem" (Sidecar Payload)
You no longer need to glue Pinecone and MongoDB together with duct tape.
.hyp) on the disk. You get the microsecond speed of a vector engine and the convenience of a Document DB in one single binary.🛡️ 4. Zero-Latency Pre-Filtering (Typed Metadata)
Parsing bloated JSON metadata during an HNSW graph traversal kills query performance. We fixed this with Typed Metadata.
int,bool,enum) are compiled directly into the HNSW graph nodes in RAM.🐝 5. Surviving the Swarm (1000+ Concurrent Clients)
Designed for multi-agent architectures, our Rust-native, lock-free HNSW implementation refuses to bottleneck.
L0/L2 Cache Accelerator: A dual-tier caching system combines a ~1µs L1 DashMap with an automatic background HNSW graph cache.
Under extreme stress tests of 1,000 simultaneous active clients, HyperspaceDB maintains over 9,400 QPS with a p99 latency of just 11.83 ms. Competitors under the same load face lock contention, with latencies skyrocketing over 2,000 ms.
🌍 6. Edge-First & WASM Ready
HyperspaceDB is completely hardware-agnostic. You can run the entire spatial index locally on a $35 Raspberry Pi or ARM64 IoT hardware. It boots in under 10ms, operates stably on 512MB RAM with zero external dependencies, and features 256-bucket Merkle Tree XOR Sync for low-bandwidth edge-to-cloud updates.
📦 Getting Started
Ready to experience spatial AI?
Deploy instantly: Spin up a cluster on the [YAR Console](https://yar.ink/hyperspace).
SDKs: We offer native, zero-friction clients for Python, Rust, and Go, with official integrations for LangChain, LlamaIndex, and the Model Context Protocol (MCP).
Upgrade your agent's memory today.
👉 Read the full [Documentation](https://yar.ink/docs)
This discussion was created from the release 🚀 Release v3.1.0: The Spatial AI Engine (Zero-OOM, Lorentz Geometry, & MRL Cascade).
All reactions