Alternatives
Products that do what Zep – pgvector-based memory store for LLM apps does
Hey HN - we launched Zep's document vector DB today. Zep is an open source memory store for LLM apps, and this builds on existing chat history memory persistence, embedding, and enrichment capabilities. Zep uses Postgres and pgvector for database operations and vector search. Vector search can be complicated on Postgres, with careful configuration required at both index creation and query time. We've focused on significantly improving this developer experience. Zep automatically selects index and query parameters for developers based on best practices and known heuristics. Vector database…
- 1IR
Hey HN! I built a proof-of-concept for AI memory using Git instead of vector databases. The insight: Git already solved versioned document management. Why are we building complex vector stores when we could just use markdown files with Git's built-in diff/blame/history? How it works: Memories stored as markdown files in a Git repo Each conversation = one commit git diff shows how understanding evolves over time BM25 for search (no embeddings needed) LLMs generate search queries from conversation context Example: Ask "how has my project evolved?" and it uses git diff to show actual…
2025 · github.com
- 2ZL
Zep is a long-term memory store designed for conversational AI applications built using modern LLMs. It handles the storage, summarization, embedding, indexing, and enrichment of chat histories, and offers developers a simple, low-latency API to this data. Chat history storage is an infrastructure challenge all developers and enterprises face as they look to move from prototypes to deploying conversational AI applications that provide rich and intimate experiences to users. Key features include long-term memory persistence, auto-summarization, vector search, auto-token counting, and Python…
2023
- 3LA
We are excited to share Lantern! Lantern is a PostgreSQL vector database extension for building AI applications. Install and use our extension here: https://github.com/lanterndata/lantern We have the most complete feature set of all the PostgreSQL vector database extensions. Our database is built on top of usearch — a state of the art implementation of HNSW, the most scalable and performant algorithm for handling vector search. There’s three key metrics we track. CREATE INDEX time, SELECT throughput, and SELECT latency. We match or outperform pgvector and pg_embedding…
2023 · docs.lantern.dev
- 4PA
2024 · github.com
- 5YA
Built this for my LLM workflows - needed searchable, persistent memory that wouldn't blow up storage costs. I also wanted to use it locally for my research. It's a content-addressed storage system with block-level deduplication (saves 30-40% on typical codebases). I have integrated the CLI tool into most of my workflows in Zed, Claude Code, and Cursor, and I provide the prompt I'm currently using in the repo. The project is in C++ and the build system is rough around the edges but is tested on macOS and Ubuntu 24.04.
2025 · github.com
- 62F
2023 · github.com
- 7
- 8
- 9GL
Hey HN! We're Paul, Preston, and Daniel from Zep. We've just open-sourced Graphiti, a Python library for building temporal Knowledge Graphs using LLMs. Graphiti helps you create and query graphs that evolve over time. Knowledge Graphs have been explored extensively for information retrieval. What makes Graphiti unique is its ability to build a knowledge graph while handling changing relationships and maintaining historical context. At Zep, we build a memory layer for LLM applications. Developers use Zep to recall relevant user information from past conversations without including the entire…
2024 · github.com
- 10IO
2024 · github.com
- 11VY
2025 · vectorvfs.readthedocs.io
- 12PO
Hey HN! We’re Kevin and Steve. We’re building PromptTools (https://github.com/hegelai/prompttools): open-source, self-hostable tools for experimenting with, testing, and evaluating LLMs, vector databases, and prompts. Evaluating prompts, LLMs, and vector databases is a painful, time-consuming but necessary part of the product engineering process. Our tools allow engineers to do this in a lot less time. By “evaluating” we mean checking the quality of a model's response for a given use case, which is a combination of testing and benchmarking. As examples: - For generated…
2023 · github.com
- 13PE
Last summer we faced a conundrum at my company, Tiger Data, a Postgres cloud vendor whose main business is in timeseries data. We were trying to grow our business towards emerging AI-centric workloads and wanted to provide a state-of-the-art hybrid search stack in Postgres. We'd already built pgvectorscale in house with the goal of scaling semantic search beyond pgvector's main memory limitations. We just needed a scalable ranked keyword search solution too. The problem: core Postgres doesn't provide this; the leading Postgres BM25 extension, ParadeDB, is guarded behind AGPL; developing our…
Mar 2026 · github.com
- 14CO
I keep running in the same problem of each AI app “remembers” me in its own silo. ChatGPT knows my project details, Cursor forgets them, Claude starts from zero… so I end up re-explaining myself dozens of times a day across these apps. The deeper problem 1. Not portable – context is vendor-locked; nothing travels across tools. 2. Not relational – most memory systems store only the latest fact (“sticky notes”) with no history or provenance. 3. Not yours – your AI memory is sensitive first-party data, yet you have no control over where it lives or how it’s queried. Demo video:…
2025 · github.com
- 15EO
Hey HN! We are building Epsilla (https://github.com/epsilla-cloud/vectordb), an open-source, self-hostable vector database for semantic similarity search that specializes in low query latency. When do we need a vector database? For example, GPT-3.5 has a 16k context window limit. If we want to let it answer a question about a 300 page book, we cannot put the whole book content into the context. We have to choose the sections of the book that are most relevant to the question. Vector database is specialized at ranking and picking the most relevant content from a large pool…
2023 · github.com
- 16AL
Dec 2025 · github.com
- 17VA
Hey HN, My friend Sam and I were bored one weekend, and wanted to make something self-contained but still useful. We ended up with Victor [0], a vector database designed to run in the browser. It’s written in Rust, which gives us access to things like super-fast and compact serialization and deserialization, but it’s compiled to WASM and uses web-sys to interact with the browser’s JS APIs to write the database contents to disk. We worked hard on designing it in a way that makes sense for the browser. It uses the private origin file system [1] and stores the vectors in a compact format (one…
2023 · github.com
- 18LM
I built a super easy to integrate memory storage and retrieval system for NodeJS projects because I saw a need for information to be shared and persisted across LLM chat sessions (and many other LLM feature interactions). I tried to keep the barrier to use as low as possible so I included built-in support for major LLMs (GPT, Gemini, and Claude) as well as major vector store providers (Weaviate and Pinecone). The memory store works by ingesting and automatically extracting “memories” (summarized single bits of information) from LLM interactions and vectorizing those. When you want to provide…
Mar 2026 · github.com
- 19PP
Mar 2026 · github.com
- 20
- 21VD
Discover, evaluate, and access relevant embeddings in your go-to framework. Skip all the infra for scraping, cleaning, indexing, and updating high-quality embeddings.
2023 · embedding.store
- 22AG
This is a vector index I built that supports insertion and k-nearest neighbors (k-NN) querying, optimized for GPUs. It operates entirely in CUDA and can process queries on half a billion vectors in under 200 milliseconds. The codebase is structured as a standalone library with an HTTP API for remote access. It’s intended for high-performance search tasks—think similarity search, AI model retrieval, or reinforcement learning replay buffers. The codebase is located at https://github.com/rodlaf/BinaryGPUIndex.
2025 · rlafuente.com
- 23ZT
Zvec is a lightweight, SQLite-like embedded vector database purpose-built for edge and on-device workloads. It delivers four core advantages: out-of-the-box usability, configurable resource budgets, extreme performance, and versatile vector capabilities. Open-sourced under the Apache 2.0 license, Zvec aims to provide developers with a one-stop path from prototyping to production deployment on the edge. Try Zvec—we’re excited to see your adoption, feedback, and contributions. For a more detailed introduction, you can refer to https://zvec.org/en/blog/introduction/
Jan 2026 · github.com
- 24
I've been working on Polign and built a small prototype around something I've been thinking about with agent memory. I have built a lightweight/stateless vector db + BM25 search which works really well with typed facts and structured queries. 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
11d ago · polign.com
Ranked by how close each launch is in meaning, then by votes. Refine with a description →