The integration is actually a pain. If something could be done to make it easier, I would really appreciate it. The reason I am saying this is that if I have a migration script that I need to run in the database, it is difficult to run migration scripts on Vespa because each time I run a migration script, I have to restart Vespa. This makes the CI process a little bit difficult. A UI would be nice to have. It is not something I thought of earlier, but now that I am thinking of it, I believe a UI would be beneficial, similar to how Neo4j offers it. Of course, I have not looked into it extensively, so I do not know if it offers a UI because for my use case, I did not need the UI. The documentation could also be improved, although the documentation was quite easy to follow for me. I do not know if it is a skill issue or not. For beginners, for someone just getting into vector databases and they just discover Vespa, I believe it will be somewhat harder for them. If the documentation can be made more beginner-friendly, it would be better. The migration script and the amount of resources Vespa requires is significant. The embedding is good. I have actually used it; the only problem is that if I need some more context passed into the embedding, then with Vespa, it is difficult, meaning I have to pass the text through an external LLM to extract the context and then pass it into Vespa for embedding. If there is a way I can improve the embedding context, to pass some context into Vespa's embedding so that I can just pass a string and let it handle the embedding by itself, that would be beneficial. I noticed Vespa only requires deployment within the environment. If I have an internal network and since Vespa does not support passwords and usernames, it makes it difficult to control what level of access a user has to data. This raises some questions regarding integrity. If two different services are using the same Vespa instance, then data protection is at risk. If Vespa can introduce username and passwords, this would solve many things. With this structure, it also means that Vespa cannot be exposed to the public. If I want to buy more resources on a different vendor and have my services on a different vendor, exposing Vespa to the public means additional setup, which means IP mapping or something similar. If the IPs are changing, then I am also running into a different problem. Therefore, username and passwords, although basic, can really help, or at least roles.
