.Net SQLite connector use case

[SteveSandersonMS]

I was trying out https://github.com/microsoft/semantic-kernel/tree/main/dotnet/src/Connectors/Connectors.Memory.Sqlite and, although it works, I'm unsure what use case it is meant for. If there are docs that explain the intent that would be great - apologies if I just missed them.

I can see in its implementation that, on every GetNearestMatchesAsync call, it does a select * from table where collection=name. Performance-wise, that's going to limit its usefulness to cases where you have only really tiny collections (say, < 1000 items at most). I tested and in practice, "find nearest" queries take ~2500ms on my machine given a collection of size ~50k, whereas if I bypass Connectors.Memory.Sqlite and write my own ISemanticTextMemory that loads from SQLite but has an in-memory cache of the key/embedding pairs, it reduces the "find nearest" query cost to ~10ms.

So my question is:

• Is the goal to make Connectors.Memory.Sqlite perform reasonably, and if so, will you consider adding a caching layer or some other mechanism to speed things up?
• Or is it better to understand Connectors.Memory.Sqlite as for small proofs-of-concept only? If so that's totally reasonable but I'd recommend putting big health warnings on it so people don't get the wrong idea :)

[dmytrostruk]

@SteveSandersonMS Thanks a lot for your detailed feedback! In short, most of the memory connectors were added at early stage of Semantic Kernel and some of them are not optimized for production yet. As for now, I would recommend using memory connectors for POCs and experimentation. In fact, all memory-related functionality is marked with Experimental attribute: https://github.com/microsoft/semantic-kernel/blob/0de7d34be3de11ffc86f9548b82ef0e888c27ea9/dotnet/src/Connectors/Connectors.Memory.Sqlite/AssemblyInfo.cs#L6

We also have a document with list of all experimental features: https://github.com/microsoft/semantic-kernel/blob/0de7d34be3de11ffc86f9548b82ef0e888c27ea9/dotnet/docs/EXPERIMENTS.md

But we do have a plan to revise SK memory abstraction, which will also impact connectors implementation. During this part of work, I think it will be possible to check each connector and optimize it for production usage.

[stephentoub]

But we do have a plan to revise SK memory abstraction

The goal is to do that revision and complete it within the next month-ish, right?

[markwallace-microsoft]

We are going to start work on the Semantic Kernel memory and search abstractions in the coming weeks. Our priority is defining a search abstraction to cover basic text search. We also aim to update the memory abstractions to address the many issues that have been raised. Once we get through planning we can share more details with the community.

[github-actions[bot]]

This issue is stale because it has been open for 90 days with no activity.

[github-actions[bot]]

This issue was closed because it has been inactive for 14 days since being marked as stale.