Allow async driver in retrievers

[psa-hms]

Hi :)
I noticed that the retrievers (e.g. Text2CypherRetriever, VectorCypherRetriever) only accept the synchronous version of the Neo4J driver.

We are refactoring our codebase and would like to move entirely to async execution instead of having to spawn threads in order to not block the whole application.

Because of the above mentioned limitation, we have to keep using both, the sync and async version of the Neo4J driver, which is not ideal.

Is an async version of these retrievers planned?

Thanks in advance for your answer :)

[onestardao]

Looks like you’ve hit a retriever I/O bottleneck — the retrievers are tied to the synchronous Neo4J driver, so even if your overall app is async, calls to these retrievers will block until the sync driver finishes. This is especially noticeable in RAG pipelines where retrieval latency compounds with model inference time.

A common workaround is to wrap the sync calls in an executor (essentially pushing the work into a separate thread) so they don’t block the event loop. It’s not as efficient as a true async driver, but it avoids having to maintain two driver versions in parallel.

If your use case involves frequent multi-retriever calls, this limitation can stack up quickly — worth checking if an async variant is on the roadmap or if you can abstract the driver calls to swap them later.

[stellasia]

Hi @psa-hms ,

This is not currently planned, but it does make sense to me. I'll put this feature request in our backlog, but I can't promise anything in terms of timescale. If you feel like taking a look yourself, we always welcome PRs (and we can guide you if needed) :)