.Net: Proposal: LiteDB Vector Store Connector (embedded, HNSW-based alternative to SqliteVec)

[JKamsker]

---

name: Feature request
about: Suggest an idea for this project

---

Motivation

I’m writing because of a recent Reddit discussion where a user mentioned that

“Microsoft uses the Sqlite-Vec connector for local RAG development… but it’s still alpha, has locking issues, and deleted vectors don’t get reclaimed.”

That comment made me wonder whether the Semantic Kernel team might be interested in exploring an embedded alternative with fewer external dependencies - namely, LiteDB, which recently added first-class vector indexing.

---

Context

The current preview SqliteVec connector works well for small local scenarios but inherits several limitations from sqlite-vec (e.g., issue #178: deleted vector blobs not reclaimed, file growth, potential locking constraints).
For desktop, mobile, or edge environments, an all-managed, single-file database could simplify local RAG setups.

---

Proposal

I’d like to propose adding a LiteDB Vector Store Connector for Semantic Kernel, built on top of LiteDB v6.0 (prerelease #52), which introduces native vector storage and HNSW-based approximate nearest neighbor (ANN) indexing.

LiteDB is a single-file, fully managed .NET database (MIT license, no native dependencies).
It already exposes a fluent vector API:

using LiteDB.Vector;

var docs = db.GetCollection<Document>("docs");
docs.EnsureIndex(x => x.Embedding, new VectorIndexOptions(256));

var results = docs.Query()
    .TopKNear(x => x.Embedding, queryVector, k: 5)
    .ToList();

This maps neatly to SK’s new Vector Store abstractions (IVectorStore, IVectorStoreRecordCollection<T>, IVectorSearchable<T>).

---

Advantages

• Pure managed code - no native sqlite-vec dependency.
• Reliable deletion - vector data removed transactionally.
• HNSW indexing - efficient ANN search for cosine, dot-product, or Euclidean distance.
• Single-file persistence - ideal for local/offline RAG development.
• MIT licensed & actively maintained - open-source friendly for embedding.

---

Benchmarks

---

Questions for the team

1. Would you be open to a LiteDbVectorStore connector (officially or community-maintained)?
2. Is there a template or checklist for new vector store connectors (tests, docs, package naming)?
3. Should such a connector live under the microsoft/semantic-kernel org (like SqliteVec) or begin as a community extension?

References

• LiteDB PR #2678 – Vector Search & Similarity Indexing
• Semantic Kernel Vector Store Overview
• Reddit discussion that inspired this idea

[markwallace-microsoft]

Hi @JKamsker
thanks for creating this issue

1. Would you be open to a LiteDbVectorStore connector (officially or community-maintained)?
   Yes

2. Is there a template or checklist for new vector store connectors (tests, docs, package naming)?
   We don't have a document but we would be happy to work with you. What this would look like is that we would set of a feature branch for this work and and review PR's as the implementation progresses. That way we could provide early feedback of things like package naming, etc.
   For documentation take a look here: https://learn.microsoft.com/en-us/semantic-kernel/concepts/vector-store-connectors/out-of-the-box-connectors/?pivots=programming-language-csharp
   For tests take a look here: https://github.com/microsoft/semantic-kernel/tree/main/dotnet/test/VectorData

3. Should such a connector live under the microsoft/semantic-kernel org (like SqliteVec) or begin as a community extension?
   Either option is fine, we are currently using both models.