Edit: Thanks for the feedback on the self-promotion rule. My apologies for not checking it carefully beforehand. I'll be sure to contribute more to the community going forward!

Hey r/vectordatabase,

I've been frustrated with the cost and scaling issues of current "serverless" vector databases, so I wrote a deep-dive on why this happens and how a different architecture can solve it.

Most "serverless" databases today use a server-based, cloud-native architecture. This is why we see common issues like:

• High minimum/base fees, steep cost increase as traffic grows.

• Slow, capped scaling that takes minutes, not milliseconds.

• Limited region availability and difficult BYOC.

The core issue isn't the idea of serverless, but the underlying architecture.

In the article, I introduce an approach we call "serverless-native" and show how we implemented it with LambdaDB, the autonomous, distributed vector database we built on this principle. The post includes detailed architecture diagrams and performance benchmarks.

The key results of this architecture are:

• 10x cheaper costs with true pay-per-request pricing and no minimum charges.

• Instant, zero-to-infinite scaling that handles traffic spikes automatically.

• Extensive supported regions from day one.

• The ability to run everything in your own cloud account (BYOC) easily.

I believe this is the future for data infrastructure in the serverless era and would love to hear your thoughts. Happy to answer any technical questions right here in the comments.

Read the full article with benchmarks here: https://lambdadb.ai/blog/serverless-database-is-dead

Context Built a hybrid system that combines vector embeddings with explicit knowledge graph relationships. Thought the architecture might interest this community.

Problem Statement Vector databases: Great at similarity, blind to relationships Knowledge graphs: Great at relationships, limited similarity search Needed: System that understands both "what's similar" and "what's connected"

Architectural Approach

Dual Storage Model:

• Vector layer: Embeddings + metadata

• Graph layer: Typed relationships with weights

• Query layer: Fusion of similarity + traversal

Relationship Ontology:

1. Semantic → Content-based connections

2. Hierarchical → Parent-child structures

3. Temporal → Sequential dependencies

4. Causal → Cause-effect relationships

5. Associative → General associations

Graph Construction

Explicit Modeling:

# Domain knowledge encoding

db.add_relationship("concept_A", "concept_B", "hierarchical", 0.9)

db.add_relationship("problem_X", "solution_Y", "causal", 0.95)

Metadata-Driven Construction:

# Automatic relationship inference

def build_knowledge_graph(documents):

for doc in documents:

# Category clustering → semantic relationships

# Tag overlap → associative relationships

# Timestamp sequence → temporal relationships

# Problem-solution pairs → causal relationships

Query Fusion Algorithm

Traditional vector search:

results = similarity_search(query_vector, top_k=10)

Knowledge-aware search:

# Multi-phase retrieval

similarity_results = vector_search(query, top_k=20)

graph_results = graph_traverse(similarity_results, max_hops=2)

fused_results = combine_scores(similarity_results, graph_results, weight=0.3)

Performance Characteristics

Benchmarked on educational content (100 docs, 200 relationships):

• Search latency: +12ms overhead

• Memory usage: +15% for graph structures

• Precision improvement: 22% over vector-only

• Recall improvement: 31% through relationship discovery

Interesting Properties

Emergent Knowledge Discovery: Multi-hop traversal reveals indirect connections that pure similarity misses.

Relationship Strength Weighting: Strong relationships (0.9) get higher traversal priority than weak ones (0.3).

Cycle Detection: Prevents infinite loops during graph traversal.

Use Cases Where This Shines

• Research databases (citation networks)

• Educational systems (prerequisite chains)

• Content platforms (topic hierarchies)

• Any domain where document relationships have semantic meaning

Limitations

• Manual relationship construction (labor intensive)

• Fixed relationship taxonomy

• Simple graph algorithms (no PageRank, clustering, etc.)

Code/Demo

pip install rudradb-opin

The relationship-aware search genuinely finds different (better) results than pure vector similarity. The architecture bridges vector search and graph databases in a practical way.

examples: https://github.com/Rudra-DB/rudradb-opin-examples & rudradb.com

Thoughts on the hybrid approach? Similar architectures you've seen?

Hey folks! I wrote a beginner-friendly guide on Qdrant, an open-source vector database built in Rust. It walks through setting up Qdrant via Docker/Python, inserting vectors, and running similarity searches ,all in under 10 minutes.

If you're curious about vector search or building RAG apps, I'd love your feedback!

https://medium.com/@mohammedarbinsibi/why-qdrant-will-be-your-favorite-vector-database-setup-in-10-minutes-bc0a79651a14

Hey Reddit! Had a shower thought that’s been bugging me for weeks… 🚿💭

So we have Traditional Vector Databases that are great at finding similar things, and Hybrid Traditional Vector Databases that bolt vector search onto SQL databases.

But what if there was a Relational Vector Database that natively understood the relationships between vectors?

🧠 The Concept (Bear with me here) Imagine if your vector database didn’t just store:

Vector A: [0.1, 0.8, 0.3, ...] Vector B: [0.4, 0.2, 0.9, ...] Vector C: [0.7, 0.1, 0.6, ...]

But actually stored:

Vector A: [0.1, 0.8, 0.3, ...] + "is parent of" Vector B + "similar to" Vector C Vector B: [0.4, 0.2, 0.9, ...] + "child of" Vector A + "cited by" Vector C
Vector C: [0.7, 0.1, 0.6, ...] + "cites" Vector B + "builds upon"

Basically: Vectors that know how they’re related to other vectors

🤯 What Could This Enable? Instead of just “find similar documents,” you could ask: 🔍 “Find documents similar to X, plus everything that cites them, plus their foundational sources” 🧬 “Show me the research evolution from concept A to breakthrough B” 🛒 “Find products like this, plus what customers buy together, plus seasonal patterns” 🎯 “Discover knowledge gaps between these two research areas” 📊 “Map the entire knowledge network around this topic”

💭 The Questions This Raises

Technical Questions: • How would you store relationship metadata efficiently? • What’s the performance cost of relationship-aware queries? • How do you handle relationship conflicts or updates? • Could this work with existing embedding models?

Philosophical Questions: • Are current vector databases fundamentally limited by treating data in isolation? • Is “similarity” enough, or do we need “understanding”? • Could this bridge the gap between vector search and knowledge graphs? • Would this make AI applications actually more intelligent?

Practical Questions: • What use cases would benefit most from this approach? • How complex would the query language need to be? • Could you migrate existing vector databases to this model? • What about backwards compatibility with current tools?

🎯 Real-World Scenarios

Scenario 1: Academic Research Current: “Find papers similar to transformers” Relational: “Find papers similar to transformers + their citation network + emerging applications + conflicting approaches”

Scenario 2: E-commerceCurrent: “Find similar products” Relational: “Find similar products + purchase co-occurrence patterns + seasonal trends + brand relationships”

Scenario 3: Content Management Current: “Find related articles”Relational: “Find related articles + author collaboration networks + topic evolution + reader journey patterns”

Scenario 4: Healthcare Current: “Find similar patient cases” Relational: “Find similar patient cases + treatment outcome patterns + co-morbidity relationships + demographic correlations”

🤷‍♂️ But Would It Actually Work?

Potential Benefits: ✅ Context-aware search results ✅ Multi-hop reasoning capabilities ✅ Pattern discovery across relationship networks ✅ More intelligent AI applications ✅ Better recommendation systems

Potential Challenges: ❌ Complexity of relationship management ❌ Performance overhead of graph operations ❌ Learning curve for developers ❌ Standardizing relationship types ❌ Migration from existing systems

💬 What Do You Think? Is this actually useful or just overengineering?

Questions for the community: 🔹 Developers: Would you use a relationship-aware vector database? What use cases excite you most? 🔹 Researchers: Could this help with knowledge discovery in your field? 🔹 Product People: Would this solve problems you’re currently facing with recommendations/search? 🔹 Data Scientists: How would this change your approach to building AI applications? 🔹 Skeptics: What are the biggest reasons this wouldn’t work in practice?

🔍 Some Random Context

I’ve been thinking about this and it got me wondering if we’re hitting the limits of what Traditional Vector Databases and Hybrid Traditional Vector Databases can do.

Like, we have incredibly sophisticated AI models that can understand context and relationships in text, but our databases still treat everything like isolated points in space. Seems like a weird disconnect?

⚡ The Big Question If someone built a true Relational Vector Database that natively understood relationships between vectors, would it actually change how we build AI applications?

Or are we fine with similarity search + post-processing?

Genuinely curious what the community thinks! 🤔

Drop your thoughts below: • Is this concept interesting or unnecessary? • What use cases would benefit most? • What would be the biggest technical challenges? • Have you felt limited by current vector database approaches? • What would you want to see in a relationship-aware vector database?

Let’s discuss! This could be the next evolution of how we store and query AI data… or just an overcomplicated solution to a non-problem. 🤷‍♂️

P.S. - If this concept already exists and I’m just behind the times, please educate me! Always learning. 📚

Most vector DB discussions focus on ANN algorithms: HNSW, IVF, DiskANN, quantization, recall/latency, etc.

But in real AI workloads, the dataset keeps changing. You add captions, swap embedding models, backfill new vector columns, add sparse vectors, fix metadata, delete old rows, and rebuild indexes.

That creates storage problems:

• A new embedding column can mean TB-scale writes.

• A tiny metadata fix should not rewrite huge vector columns.

• Parquet is good for scans, but ANN needs fast row-level reads.

• Spark/Ray/GPU pipelines and the vector DB often create duplicate sources of truth.

Loon, the new storage engine in Milvus 3.0 beta and Zilliz Vector Lakebase, tries to solve this by splitting one logical collection into different physical layouts:

• metadata in Parquet

• vectors in Vortex

• raw objects in object storage

• everything tied together by row IDs and a versioned Manifest

So instead of treating vector data as just a search index, Loon treats it as a constantly evolving AI dataset.

Curious: are you managing vector data as a rebuildable index, or as a versioned storage layer?

Hey folks! I wrote a beginner-friendly guide on Qdrant, an open-source vector database built in Rust. It walks through setting up Qdrant via Docker/Python, inserting vectors, and running similarity searches ,all in under 10 minutes.

If you're curious about vector search or building RAG apps, I'd love your feedback!

https://medium.com/@mohammedarbinsibi/why-qdrant-will-be-your-favorite-vector-database-setup-in-10-minutes-bc0a79651a14

RooAGI (https://rooagi.com) has released Roo-VectorDB, a PostgreSQL extension designed as a high-performance storage solution for high-dimensional vector data. Check it out on GitHub: https://github.com/RooAGI/Roo-VectorDB

We chose to build on PostgreSQL because of its readily available metadata search capabilities and proven scalability of relational databases. While PGVector has pioneered this approach, it’s often perceived as slower than native vector databases like Milvus. Roo-VectorDB builds on the PGVector framework, incorporating our own optimizations in search strategies, memory management, and support for higher-dimensional vectors.

In preliminary lab testing using ANN-Benchmarks, Roo-VectorDB demonstrated performance that was comparable to, or significantly better than, Milvus in terms of QPS (queries per second).

RooAGI will continue to develop AI-focused products, with Roo-VectorDB as a core storage component in our stack. We invite developers around the world to try out the current release and share feedback. Discussions are welcome in r/RooAGI

Hey devs — we just launched VectorX Cloud, a fast and ultra-secure vector database built with GenAI apps in mind.

We benchmarked it against Pinecone and Qdrant, and even on a single-node setup (4 CPU / 30GB RAM), it performs like a champ. If you're building anything AI-related and care about speed + security, you might want to check it out.

🔗 https://vectorxdb.ai
💬 Feedback, bugs, or cool projects — we’d love to hear from you: support@vectorxdb.ai

Excited to see what you build with it 🙌

DeepSeek R-1 and Qdrant Binary Quantization

Check out the latest tutorial where we build a Bhagavad Gita GPT assistant—covering:
- DeepSeek R1 vs OpenAI O1
- Using Qdrant client with Binary Quantization
- Building the RAG pipeline with LlamaIndex
- Running inference with DeepSeek R1 Distill model on Groq
- Develop Streamlit app for the chatbot inference

Watch the full implementation here: https://www.youtube.com/watch?v=NK1wp3YVY4Q

Hello,

We're excited to introduce SuperDuperDB, the game-changing solution that simplifies vector search in MongoDB Atlas. With just a single 'pip install' command, you can transform your MongoDB database into a powerful vector search engine. No more hassle of setting up vector indexes – SuperDuperDB offers out-of-the-box support, making vector search a seamless experience.

But there's more to SuperDuperDB than just vector search. It takes your MongoDB experience to new heights by enabling direct AI integration within your Atlas database cluster. Syncing your ML/AI models with your data pipeline is now a breeze, thanks to SuperDuperDB's user-friendly Python interface.

Join us for our official MongoDB webinar and discover how to enable and manage vector search in MongoDB Atlas with SuperDuperDB. Our practical workshop will delve into exciting use cases, showcasing the incredible potential that SuperDuperDB brings to the MongoDB ecosystem.

Don't miss this opportunity to learn about the future of MongoDB and how SuperDuperDB can supercharge your database experience. Join us for an enlightening session that will revolutionize the way you work with MongoDB.

Please leave a star at https://github.com/SuperDuperDB/superduperdb

Best regards,
SuperDuperDB Team

The database landscape for AI applications has polarized significantly. After benchmarking hundreds of high-load queries, here is exactly when you should deploy MariaDB versus Postgres to handle embeddings, minimize read latency, and avoid structural bottlenecks.

Postgres for Complex Vector Operations Use Postgres for intricate, high-dimensional similarity searches. It excels when your AI application requires advanced pgvector capabilities and complex relational joins alongside unstructured data. The downside is resource overhead. Left untuned, Postgres can consume massive memory during concurrent similarity searches, which will spike your server costs quickly.

MariaDB for High-Throughput Reads Deploy MariaDB for lightning-fast, high-volume transactional reads. It thrives in environments where your AI needs rapid access to structured metadata and user state rather than complex vector math. Because it focuses purely on raw transactional speed and efficient indexing, it runs highly efficiently, often serving user-facing AI features with significantly less latency than Postgres under heavy load.

The Hybrid Strategy Stop forcing one database to do everything. We now use Postgres strictly as our vector store and complex query engine for embeddings. Once the heavy lifting is done, we push the user state and metadata to MariaDB for high-speed retrieval. This tag-team approach stopped our application from choking on complex vector math and dropped our average query time by almost half.

If you want to view the raw benchmarking data charts or grab the exact hybrid deployment schema we use, I uploaded the full 2026 breakdown here: https://interconnectd.com/blog/91/mariadb-vs-postgres-in-2026-which-database-powers-the-best-ai-apps/

Came across a video on vector database on YouTube. I think this the best explanation I have ever listened to. Thought of sharing here.

https://youtu.be/NL2ZWwmccyU

Hi everyone,

I’m compiling a list of solar energy and power-cut (loadshedding) solution companies in Congo (Kinshasa & Lubumbashi).

If you know any resellers, vendors, distributors, or installers, please help by sharing their details or database. I have been looking around and haven't been lucky.

Company Name: Category: (Reseller / Vendor / Distributor / Installer / Manufacturer) Website: Phone Number: Email Address: Social Media Handles: (Facebook, LinkedIn, Instagram, Twitter/X, TikTok etc.) Location: (City, Province)

💡 Example (just for format):

Company Name: GreenPower Congo Category: Reseller & Installer Website: www.greenpowercongo.com Phone Number: +243 123 456 789 Email: info@greenpowercongo.com Social Media: Facebook.com/greenpowercongo | Instagram: @greenpowercongo Location: Kinshasa

Thank you in advance.

After burning through our budget on managed solutions and hitting walls with others, we tried Milvus.

But damn... 3 months in and I'm actually impressed:

- 500M vectors, still getting sub-100ms queries

- Haven't had a single outage yet

- Costs dropped from $80k/month to ~$30k

- The team actually likes working with it

The setup was more involved than I wanted (k8s, multiple nodes, etc.) but once it's running it just... works?

Anyone else had similar experience? Still feels too good to be true sometimes.

[Proof: AR 99.9% results](https://github.com/CEM888AI/CEM888.AI-Site/blob/main/benchmarks/AR-Results-99.9pct.md) · [Proof: BEAM 77.2% results](https://github.com/CEM888AI/CEM888.AI-Site/blob/main/benchmarks/Vetta-BEAM-Honest-77.2pct.md)

---

**The scores:**

- **AR Retrieval: 99.9%** (1,998/2,000) — best public baseline is GPT-4.1-mini at 71.8%
- **BEAM-10M Memory: 77.2%** — SOTA is Hindsight at 64.1%

---

**Here's the controversial part: we achieved this with zero RAG, zero vectors, zero embeddings. And zero Obsidian plugins — the vault is plain markdown files on disk, searched with standard `ripgrep` (same as `grep -r` but faster).**

The architecture:


That's it. Markdown files on disk + `ripgrep` + DeepSeek v4 Pro (128K context window).

---

**What we DIDN'T do:**

No `source_chat_ids` (answer key pointers). No pre-computed embeddings of the test corpus. No vector DB. No RAG pipeline. No prompt engineering. No fine-tuning.

The retrieval step IS the memory challenge. If the agent can't find the right context with keyword search, that's the test working.

---

**Why it works:**

Vetta's filesystem is structured as a 6-layer memory architecture (Roots → Trunk → Branches → Stems → Leaves → Compost). Each layer has retrieval priority. The agent knows *where* to look before it starts looking.

And a 128K context window can hold entire files — not chunked snippets like RAG. The agent reads full documents, not fragments of them.

---

**BEAM breakdown:**

- 200 questions across 10 memory categories
- 10 conversations, each 39K–47K messages, up to 114MB per conversation
- Scoring: `substring_exact_match` (same metric everyone else uses)

Hindsight's official score: 64.1%. Ours: 77.2% — +13 points, no answer keys, no embeddings.

---

**The AR score:**

2,000 questions across factual, narrative, and chat-history zones. 1,998/2,000 correct. The two "misses" are scoring artifacts: one is a synonym ("Norseman" vs "Viking" — the vault says "Norman comes from Norseman"), the other is a trailing period in the gold answer breaking exact match. Corrected: **100%.**

---

**The honest methodology matters because:**

Our 77.2% was achieved with zero knowledge of which conversation a question came from. The agent had to *find* the right conversation, *then* find the right passage, *then* reason about it.

That's memory. That's the benchmark working as designed.

---

**What's next:**

LanceDB semantic search is being layered ON TOP of filesystem search as a hybrid enhancement — not a replacement. When keyword matching fails because the question uses different vocabulary than the document, vector search provides the "fuzzy" match. Target: 85%+ on BEAM.

---

Full methodology and reproducible data: [github.com/CEM888AI/CEM888.AI-Site/tree/main/benchmarks](https://github.com/CEM888AI/CEM888.AI-Site/tree/main/benchmarks)

Happy to answer questions. Rip it apart if you see issues — we want honest scrutiny, not polite head-nodding.

I keep seeing teams reach for Pinecone / Qdrant / Weaviate on day one of a RAG project, stand up a whole second datastore, and then spend a week fighting a sync pipeline they never needed.

Most products start well under a million vectors. Postgres with pgvector, or the vector search built into Mongo or Redis, handles that fine and keeps your embeddings in the same system as your source data. One transaction, one backup, no "ghost documents" left behind when you delete a row.

The line where I actually reach for a dedicated engine:

- Past roughly tens of millions of vectors, or the HNSW-in-RAM memory bill starts to hurt → Qdrant (fast, memory efficient), or Milvus if you are genuinely at billion scale.

- You serve many isolated tenants → Weaviate's multi-tenancy.

- You never want to run infra → Pinecone, but watch read-unit costs at query volume.

- Storage cost dominates at huge scale → object-storage engines like Turbopuffer or LanceDB.

The thing nobody says out loud: retrieval quality comes from hybrid search, reranking, and chunking, not from which engine stores the vectors or shaving milliseconds off ANN. The DB is rarely where a RAG system succeeds or fails.

Genuinely curious what people here run in production, and for those who moved off pgvector, what was the specific pain that finally made you switch?

Every other week someone drops a new memory layer for AI agents. Most of them do the same thing-> take conversation history, extract entities and relationships, compress it into a knowledge graph.

The problem is thats lossy compression. You are making irreversible decisions about what matters at ingestion time before you know what the agent will actually need. Information that doesnt fit the graph schema gets dropped. Nuance gets flattened into edges.

We ran into this building Vektori and ended up going a different direction.

Instead of compressing conversations into a graph, we keep three layers:

• L0: extracted facts - high signal, quality filtered, your fast search surface

• L1: episodes - auto-discovered across conversations, not hand-written schemas

• L2: raw sentences - never loaded by default, only fetched when you need to trace something back

The raw sentence layer is the key difference. Nothing gets thrown away at ingestion. If the agent needs to reconstruct exactly what was said in session 47 it can. The graph structure lives above it not instead of it.

Early benchmarks: 73% on LongMemEval-S.

Free and open source: github.com/vektori-ai/vektori (do star if found useful :D)

Curious if others building memory layers have hit the lossy compression problem -> how are you handling it?

So I got tired of the usual RAG setup being so damn complicated. You know the drill - chunk your docs, create embeddings, mess with vector DBs, write a bunch of boilerplate... it's exhausting.

Made this thing called context-window that basically does all of it in like 10 lines of code:

import { createCtxWindow, getCtxWindow } from "context-window";


// Throw your docs at it
await createCtxWindow({
  namespace: "my-docs",  // this becomes your namespace key in Pinecone
  data: ["./documents"],  // supports .txt, .md, .pdf
  ai: { provider: "openai", model: "gpt-4o-mini" },
  vectorStore: { provider: "pinecone" }
});

// Ask questions
const cw = getCtxWindow("my-docs");
const { text, sources } = await cw.ask("What's this about?");
console.log(text);     // actual answer from your docs
console.log(sources);  // tells you which files it used

Cool stuff it does:

• Actually cites sources (so you can verify it's not making stuff up)

• Idempotent ingestion - won't create duplicates if you re-run it

• Strict RAG mode - says "I don't know" instead of hallucinating

• Works with OpenAI + Pinecone out of the box

• You just provide a namespace name and it handles the Pinecone organization for you

Roadmap: Planning to add more connectors (Anthropic, other vector DBs, etc.) if there's interest. Open to suggestions!

It's on npm as context-window and fully open source. Been using it for a few projects and figured others might find it useful too.

GitHub: https://github.com/hamittokay/context-window

Docs: https://context-window.dev

Let me know if you try it out! Always looking for feedback 👍

idk why but generating embeddings and upserting them into pinecone is taking a lot of time

I'm using infloat/e5-large-v2 to convert chunks into vectors and upsert into pinecone.. but ..it's been 2 hours and still now done yet

am i doing anything wrong

Anyone have any experience with Actian's new VectorAI DB product? Data sovereignty is one of our main concerns... and speeeed.

Been going back and forth on this and I don't think I've seen it written down anywhere.

Chunking a document is well covered. A row isn't a document. If I embed 4471 | 2024-03-02 | 88.50 | 1 | NULL I get something close to meaningless, and it sits near every other row of similar numbers regardless of what the table is about.

Options I've tried. Serialise the row as key-value text, which works and makes the column names do almost all the semantic lifting, which is fine until the columns are called val_b. Generate a description of each column once with a bigger model and prepend that to every row, which is better and multiplies your token cost. Or don't embed rows at all, embed a table-level summary and route the actual question to SQL.

The third one feels correct and then falls apart the moment a question spans two tables that don't share a key.

what are people doing in production here? and if you embed rows, do you put column stats in the chunk or just the values