Vespa definitely had its own set of challenges. It was really hard to get into initially, especially when I started implementing it in 2024 along with one junior employee, and the lack of documentation made it difficult. I aimed for an implementation with ColBERT, a sparse embedding mechanism, which I believed would fit well for e-commerce. We went through iterations during A/B testing because the initial set did not work as expected, which extended the process to about one and a half years. Vespa has a considerable learning curve, making it challenging for most people to get into, and it is also expensive, which can deter startups or those with smaller budgets from using it. Community support was decent, and we turned to it for clarifications. However, substantial improvements in documentation are necessary, especially more examples for handling DSL effectively. Having a runtime testing feature would greatly facilitate quick iterations.
Integration Related To Ai at RedBlink Technologies
MSP
Top 20
Jun 6, 2026
We want Vespa to implement some UI features so that we can visualize how our data goes and what embeddings it stores. The main thing Vespa has to implement is the UI. Right now, we are hitting the API and getting the results in Postman. One more improvement we want is an option in Vespa for getting some suggestions from Vespa. If you are storing a document in the vector store, Vespa could suggest some information you have to store for that particular document. My suggestion is going with implementing some features related to agentic AI. We have a couple of agents, so Vespa could decide which agent is best suitable for this user's query. That would be helpful.
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.
Open Source Databases are essential for businesses seeking customizable database solutions. They offer flexibility, security, and active community support, making them a popular choice for a wide range of applications and industries.Known for their adaptability, Open Source Databases enable organizations to tailor database management systems to their specific requirements. With the freedom to modify code, users can optimize performance and security in ways that proprietary databases might not...
Vespa definitely had its own set of challenges. It was really hard to get into initially, especially when I started implementing it in 2024 along with one junior employee, and the lack of documentation made it difficult. I aimed for an implementation with ColBERT, a sparse embedding mechanism, which I believed would fit well for e-commerce. We went through iterations during A/B testing because the initial set did not work as expected, which extended the process to about one and a half years. Vespa has a considerable learning curve, making it challenging for most people to get into, and it is also expensive, which can deter startups or those with smaller budgets from using it. Community support was decent, and we turned to it for clarifications. However, substantial improvements in documentation are necessary, especially more examples for handling DSL effectively. Having a runtime testing feature would greatly facilitate quick iterations.
We want Vespa to implement some UI features so that we can visualize how our data goes and what embeddings it stores. The main thing Vespa has to implement is the UI. Right now, we are hitting the API and getting the results in Postman. One more improvement we want is an option in Vespa for getting some suggestions from Vespa. If you are storing a document in the vector store, Vespa could suggest some information you have to store for that particular document. My suggestion is going with implementing some features related to agentic AI. We have a couple of agents, so Vespa could decide which agent is best suitable for this user's query. That would be helpful.
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.