It uses your own S3, or GCS bucket as primary storage, and restarting a node is fairly quick.
Demo + writeup: https://polign.com/blog-edge-agent-memory
Live search demo: https://demo.polign.com
Docs: https://polign.com
It uses your own S3, or GCS bucket as primary storage, and restarting a node is fairly quick.
Demo + writeup: https://polign.com/blog-edge-agent-memory
Live search demo: https://demo.polign.com
Docs: https://polign.com
I'm throwing in a bit of stank in those questions because I don't see anything here that's particularly unique, and keeping this closed and costly is just... absurd. I've vibe coded the same exact thing multiple times. It works, but it's only as useful as the philosophy of the person using it allows it to be.
So why would someone choose your solution? A vector database hosted in S3 is effectively trivial to set up at this point in time. What are you offering that I can't get from prompting a powerful enough model? If the answer to that question isn't the first thing people read when they open this post, then you can just consider all of this worthless and save yourself the hassle.
unified101•16h ago
anuptalwalkar•14h ago
Litestream with SQLite would solve some of these use cases, and backing up to S3 or GCS works well.
Here I was focused on more dynamic workloads. For example, larger indexes and corpus that can be accessed by multiple readers. I didn't want to invest in local storage, so the data is made to stay cold until it's actually accessed into warm cache.
Also, one node can serve all of that in one collection while serving typed agent memory in another.
Perhaps I missed something, but storage, memory, and operational overhead is something I wanted to worry less about.