Is your feature request related to a problem? Please describe.
Currently qdrant requires write access to storage directory, even if there are no write operations happening in the system.
It would be interesting in some scenarios to have an ability to run qdrant from read-only FS. For example, from the mounted network FS, so that multiple qdrant instances can serve same data.
Describe the solution you'd like
Introduce a new CLI argument --read-only which will enable read only mode in qdrant.
For update APIs read-only instance should behave in the same way as for read-only API key - respond with 403 Forbidden and explanation that the instance is in read-only mode.
Distributed deployment can't be read-only.
Describe alternatives you've considered
Automatic fallback into read-only if the file system doesn't allow writes, but it seems less flexible and error-prone.
Additional context
read-only mode assumes skipping WAL reading, so all changes should be applied and flushed to the real storage in advance
Note for contributors: Please consider this as tracking issue. If you think that it would be beneficial to split the task into multiple smaller PRs, please you are welcome to do so. Bounty will be rewarded for each PR independently
Is your feature request related to a problem? Please describe.
Currently qdrant requires write access to storage directory, even if there are no write operations happening in the system.
It would be interesting in some scenarios to have an ability to run qdrant from read-only FS. For example, from the mounted network FS, so that multiple qdrant instances can serve same data.
Describe the solution you'd like
Introduce a new CLI argument
--read-onlywhich will enable read only mode in qdrant.For update APIs read-only instance should behave in the same way as for read-only API key - respond with
403 Forbiddenand explanation that the instance is in read-only mode.Distributed deployment can't be read-only.
Describe alternatives you've considered
Automatic fallback into read-only if the file system doesn't allow writes, but it seems less flexible and error-prone.
Additional context
read-only mode assumes skipping WAL reading, so all changes should be applied and flushed to the real storage in advance
Note for contributors: Please consider this as tracking issue. If you think that it would be beneficial to split the task into multiple smaller PRs, please you are welcome to do so. Bounty will be rewarded for each PR independently