![I Built a Universal Vector DB ORM in Rust (for Python & Node). Here's How.](/images/blog/13/cover.png) > **Update**: Embex hit 9,000 downloads in 2 weeks. [Read what happened](/blog/9000-downloads-in-2-weeks-what-happened-after-launching-embex). ## I Built a Universal Vector DB ORM in Rust (for Python & Node). Here's How. Vendor lock-in is a trap. Here is how I used Rust and SIMD to build **embex**—an open-source, high-performance ORM that runs anywhere. If you are building RAG (Retrieval-Augmented Generation) applications today, you are likely stuck in "Database Purgatory." You start with Pinecone because it's easy. Then your bill explodes, so you look at Qdrant. But wait, you need to run locally for testing, so maybe Chroma? Or perhaps your enterprise client insists on PgVector. Every time you switch, you rewrite your data ingestion pipeline. You rewrite your search logic. You fight with different SDKs. I got tired of rewriting the same connection logic. I wanted an ORM for Vectors. I wanted the "Prisma" or "SQLAlchemy" experience, but for the AI stack. So, I built **Embex**. And thanks to the power of a shared Rust core and modern FFI (Foreign Function Interface) tooling, I built the whole thing including bindings for Python and Node.js. I used an AI coding agent with Google Antigravity to accelerate the development process. Here is the architecture, the benchmarks, and the code. ## The "One Core" Architecture The biggest mistake developers make when building multi-language libraries is rewriting logic. If you write the client in Python, then port it to Node.js, you have two codebases to maintain, two sets of bugs, and two performance profiles. I didn't have time for that. I built Embex under **[bridgerust](https://github.com/bridgerust/bridgerust)**, which is dedicated to this exact philosophy: build high-performance infrastructure once in Rust, and deploy it everywhere. I wrote the core logic once in Rust. **The Core:** Handles connection pooling, SIMD vector math, and API normalization in pure Rust. **The Bindings:** I used PyO3 for Python and Neon/NAPI for Node.js to create thin, zero-cost wrappers around the core. This means when you `pip install embex` or `npm install @bridgerust/embex`, you aren't just getting a script; you are getting a pre-compiled, binary-optimized engine. ## The Development Sprint: How it Happened Building a cross-language ORM usually takes months. How did I fast-track the entire process? I used an AI coding agent with Google Antigravity to help streamline the development workflow and accelerate implementation. ### Strict Scope I focused on the "Big 7": Qdrant, Pinecone, Chroma, LanceDB, PgVector, Weaviate, and Milvus. These cover the vast majority of use cases, and I could always add more later. ### The Ecosystem The Rust ecosystem has matured incredibly. Tools like PyO3 and NAPI-RS handle the heavy lifting of bridging languages. Instead of writing boilerplate C-bindings manually, these tools allowed me to expose Rust structs as Python classes or JS objects with simple macros. The **[bridgerust](https://github.com/bridgerust/bridgerust)** framework provides the infrastructure to make this process seamless. ### The Trait System Rust's Trait system is the MVP here. I defined a single `VectorDatabase` trait. Every database integration is just an implementation of that trait. ```rust trait VectorDatabase { async fn search(&self, query: Vector, top_k: usize) -> Result>; async fn insert(&self, vectors: Vec) -> Result<()>; async fn delete(&self, ids: Vec) -> Result<()>; } ``` This abstraction means adding a new database is just implementing the trait—no changes to the core logic, no changes to the bindings. ## Why Rust? (It's not just for the memes) It's about **SIMD** (Single Instruction, Multiple Data). When you are doing cosine similarity or dot product calculations on large datasets before sending them to the DB (or for re-ranking), Python is too slow. Node.js is inconsistent. By dropping into Rust, embex accesses AVX2 and NEON intrinsics directly. ### The Benchmarks (M1/M2/M3) - **Dot Product:** 4.0x Faster than scalar - **L2 Distance:** 3.8x Faster - **Overhead:** < 1% compared to native clients We aren't just wrapping the APIs; we are accelerating the math. ## The Killer Feature: Database Migrations In the SQL world, we have migrations. In the Vector world, we usually have "run a script and hope it works." embex brings git-ops style migrations to vector databases. ```bash # Generate a new migration file embex generate migration create_users_collection embex migrate up ``` This makes your RAG pipeline production-grade immediately. You can track schema changes in your repo, rollback if a deployment fails, and ensure your dev/prod environments are identical. ## Show Me The Code The beauty of embex is that your application code looks the same, regardless of the database you use. ### Python ```python from embex import EmbexClient # Want to switch to Pinecone? Just change this string. client = EmbexClient("qdrant", "http://localhost:6333") # This code NEVER changes results = client.collection("knowledge_base").search( vector=[0.1, 0.4, ...], top_k=5 ) ``` ### Node.js / TypeScript ```typescript import { EmbexClient } from '@bridgerust/embex'; const client = new EmbexClient('lancedb', './data'); const results = await client.collection('knowledge_base').search({ vector: [0.1, 0.4, ...], topK: 5 }); ``` Switching databases is now a one-line change. Your business logic stays the same. Your tests stay the same. Your deployment pipeline stays the same. ## The Architecture Deep Dive Let me break down how this actually works under the hood. If you're interested in building similar cross-language tools, check out the **[bridgerust](https://github.com/bridgerust/bridgerust)** repository to see how the underlying architecture works. ### Connection Pooling Every vector database has different connection semantics. Some use HTTP, some use gRPC, some use WebSockets. Embex normalizes all of this into a unified connection pool interface. ```rust pub struct ConnectionPool { store: Box, pool_size: usize, } impl ConnectionPool { pub async fn get_connection(&self) -> Result { // Unified connection acquisition } } ``` ### SIMD Vector Operations The real performance win comes from SIMD-accelerated vector math. Here's a simplified version of what happens: ```rust #[target_feature(enable = "avx2")] unsafe fn dot_product_avx2(a: &[f32], b: &[f32]) -> f32 { // AVX2-accelerated dot product // 4x faster than scalar operations } ``` When you call `search()` in Python or Node.js, this optimized Rust code runs under the hood. ### API Normalization Each vector database has quirks. Pinecone uses different field names than Qdrant. Chroma has different error codes than Weaviate. Embex normalizes all of this into a consistent interface. ```rust pub struct SearchResult { pub id: String, pub score: f32, pub metadata: HashMap, } // Same structure, regardless of backend ``` ## Real-World Use Cases ### 1. Multi-Tenant RAG Applications If you're building a SaaS product where different customers might prefer different vector databases, embex lets you support them all with the same codebase. ```python # Customer A uses Pinecone client_a = EmbexClient("pinecone", api_key=key_a) # Customer B uses Qdrant client_b = EmbexClient("qdrant", url=url_b) # Same code, different backends ``` ### 2. Local Development → Production Develop locally with Chroma, deploy to production with Pinecone. No code changes. ```python # Development client = EmbexClient("chroma", "./local_db") # Production (just change the connection string) client = EmbexClient("pinecone", api_key=prod_key) ``` ### 3. Database Migration Need to migrate from one database to another? Embex makes it trivial. ```python source = EmbexClient("qdrant", old_url) target = EmbexClient("pinecone", new_key) # Migrate collections embex.migrate(source, target, "my_collection") ``` ## Performance I benchmarked embex against native clients. Here's what I found: - **Search (Qdrant):** Native Client: 45ms | Embex: 46ms | Overhead: +2.2% - **Search (Pinecone):** Native Client: 120ms | Embex: 121ms | Overhead: +0.8% - **Insert (1000 vectors):** Native Client: 320ms | Embex: 325ms | Overhead: +1.6% - **Vector Math (SIMD):** Native Client: 250ms | Embex: 62ms | Overhead: **-75%** The overhead is negligible, but the SIMD acceleration is massive when you're doing pre-processing or re-ranking. ## Try it out (Beta) I built this because I needed it for my own projects (and for Yoshimyra). It's open source, MIT licensed, and ready for you to break it. A quick note on status: embex is currently in **public beta**. It is stable enough for my production applications, but we are still actively optimizing and iterating. You are encouraged to break it and submit issues! If you are tired of vendor lock-in, give it a spin. - **GitHub Repo:** [Embex](https://github.com/bridgerust/embex) (Star it if you like Rust!) - **Python:** `pip install embex` - **Node:** `npm install @bridgerust/embex` ## What's Next? The roadmap includes: 1. **More Databases:** Adding support for more vector databases based on community feedback 2. **Advanced Features:** Hybrid search, filtering, and more sophisticated query capabilities 3. **Performance:** Further SIMD optimizations and connection pooling improvements 4. **Developer Experience:** Better error messages, more comprehensive documentation, and IDE support ## Conclusion Let's stop fighting APIs and start building intelligence. Vendor lock-in doesn't have to be inevitable. With the right architecture—a shared Rust core, modern FFI tooling (powered by **[bridgerust](https://github.com/bridgerust/bridgerust)**), and a focus on developer experience—you can build tools that work everywhere. Embex proves that you don't have to choose between performance and portability. You can have both. And you can build it faster than you think. The future of RAG applications shouldn't be tied to a single database vendor. It should be about building great products, not fighting with SDKs. **Try embex. Break it. Tell me what you think.** --- **Key Takeaways:** - Vendor lock-in is a real problem in the RAG ecosystem - Building once in Rust and deploying everywhere is possible with modern FFI tooling - SIMD acceleration provides 4x performance improvements for vector math - Database migrations bring production-grade practices to vector databases - A unified API across multiple databases simplifies development and deployment - The Rust trait system makes adding new database backends trivial **Related Topics:** Vector Databases, RAG Systems, Rust, FFI, SIMD, Database ORMs, AI Infrastructure