The article suggests running Kuzu in a FastAPI frontend for network access. A caveat: production Python servers like Uvicorn [1] typically spawn multiple worker processes.

A simple workaround is serving HTTP through a single process language like Go or JavaScript, since Kuzu has bindings for both. Other processes could access the database directly in read-only mode for analysis [2].

For better DX, the ideal would be Kuzu implementing the Bolt protocol of Neo4J directly in the binary, handling single-writer and multi-reader coordination internally. Simpler alternative: port the code from [3] to C++ and add a `kuzu --server` option.

--

1: https://fastapi.tiangolo.com/deployment/server-workers/#mult...

2: https://docs.kuzudb.com/concurrency/#scenario-2-multiple-pro...

3: https://github.com/kuzudb/explorer/tree/master/src/server