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

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/#multiple-workers https://fastapi.tiangolo.com/deployment/server-workers/#mult... 2: https://docs.kuzudb.com/concurrency/#scenario-2-multiple-processes-that-create-read_only-databases https://docs.kuzudb.com/concurrency/#scenario-2-multiple-pro... 3: https://github.com/kuzudb/explorer/tree/master/src/server https://github.com/kuzudb/explorer/tree/master/src/server