Initially I thought we need a dedicated vector database but as we tried to build even a simple gen-ai applicaitons we realized that we need another "regular" database to build a complete application.
Instead with DataStax's Vector Search, we designed a document style API and corresponding clients that give you a Vector Native experience to do CRUD of vector and meta-data as well CRUD of other data models. Here is one client ref for example https://docs.datastax.com/en/astra/astra-db-vector/clients/p...
We will be publishing the github repo in the next couple of weeks. As you can imagine this is happening in real time and we want to cross check few things before we publish the repo.
I will reply to this thread once that has happened.
This is interesting because it does not mention Vector database powered by Apache Cassandra or the hosted serverless version DataStax Astra. Here is write up we did on 5 hard problems in Vector database and how we solved them. https://thenewstack.io/5-hard-problems-in-vector-search-and-...
In full transparency: I work for DataStatx and lead engineering for Vector database.
What a great tribute you have written. When I first found about swizzling through a seasoned iOS dev I was blown away. The swizzling capability in obj-c basically helped create my first startup, InstaOps, a long time back which allowed no code change to instrument an app to capture logs and network performance metrics.
Agree. You don't want to do Fashion Driven Development (FDD). You would end up chasing every shiny thing that comes out and not really master anything.
Pick any one stack, build some simple projects and then expand on it. You would also want to be able to read well written code from others on github and learn from those.
Nicely done. Couple of recommendations:
- Recommend to change your licensing if you want people to try.
- I understand why you want to have AGPL but I don't know many successful OSS projects with this license. There is another HN thread on this topic. https://news.ycombinator.com/item?id=1657071
I am assuming you are talking about our deployment on GCP Cloud Run? We have thought about sending a heartbeat API call. It we notice any user experience friction because of this lag then we will definitely do that. As we said in the blog, this has not been a major pain point as of today.
We supported batch api calls in v0. But as those API calls increased a new instanced would get spun up but boot time was longer. To get around it, we would have to keep more instances running all the time which obviously costs more money.
Thanks for the tips. Having everything colocated in a k8s cluster will definitely help with latency and probably overall infra cost but it will be at the expense of engineering times spent on running a k8s cluster in prod.
Fingers crossed that we keep growing which would mean that we can justify working on v2 architecture.
Totally. We did not have a need for custom models initially. We could load all our models on one VM so there was no need. We were tempted to get on the bandwagon. ;-)