I\u2019m looking for the "state of the art" in 2026. Specifically:
LLM4Rec: Beyond just using LLMs for feature engineering\u2014who is doing generative recommendation well?
Retrieval vs. Ranking: Any new breakthroughs in the "Two-Tower" paradigm or vector database integration?
Real-world Scale: Papers that address the latency/cost trade-offs of these newer, heavier models.
What has been the most influential paper you\u2019ve read recently that changed how you think about discovery?"},"title":{"matchLevel":"none","matchedWords":[],"value":"Ask HN: What are the recommender systems papers from 2024-2025?"}},"_tags":["story","author_haensi","story_46692368","ask_hn"],"author":"haensi","children":[46700418],"created_at":"2026-01-20T14:50:24Z","created_at_i":1768920624,"num_comments":1,"objectID":"46692368","points":15,"story_id":46692368,"story_text":"I\u2019ve been keeping up with the classics (NCF, Wide & Deep, LightGCN), but the field seems to have shifted dramatically in the last 18\u201324 months toward LLM-based reasoning and graph-based retrieval at scale.
I\u2019m looking for the "state of the art" in 2026. Specifically:
LLM4Rec: Beyond just using LLMs for feature engineering\u2014who is doing generative recommendation well?
Retrieval vs. Ranking: Any new breakthroughs in the "Two-Tower" paradigm or vector database integration?
Real-world Scale: Papers that address the latency/cost trade-offs of these newer, heavier models.
What has been the most influential paper you\u2019ve read recently that changed how you think about discovery?","title":"Ask HN: What are the recommender systems papers from 2024-2025?","updated_at":"2026-03-05T23:29:02Z"},{"_highlightResult":{"author":{"matchLevel":"none","matchedWords":[],"value":"yoloshii"},"story_text":{"fullyHighlighted":false,"matchLevel":"full","matchedWords":["vector","database","2026"],"value":"Simple Apify actor that scrapes websites and indexes them in Google's new Gemini File Search API (launched Nov 6).
The workflow: Scrape \u2192 Clean content \u2192 Upload to Gemini \u2192 Get permanent queryable knowledge base with automatic citations.
Technical approach:\n- Intelligent scraper selection from 5 Apify-native scrapers\n- Automatic content cleaning (strips nav/ads/fluff)\n- Uploads to Gemini File Search (persistent storage)\n- Per-page PPE pricing ($0.02 start, $0.0015/page)
Potential use cases:\n- Turn documentation into AI chatbots\n- Make company wikis naturally searchable\n- Build RAG apps without managing vector databases
Basically streamline your Gemini file search RAG ingestion with an Apify scraper run AIO.
You can also employ the actor programmatically with agents using Apify's actor mcp.
Built this over a weekend for the Apify 1M Actor Challenge. It's my first Apify actor, so curious to hear if the pricing makes sense.
Note* There is a banned websites to scrape list filter due to the constraints of the challenge. This will be lifted after the challenge ends (Jan 31, 2026)."},"title":{"matchLevel":"none","matchedWords":[],"value":"Show HN: Scrape websites into queryable Gemini RAG knowledge bases"},"url":{"matchLevel":"none","matchedWords":[],"value":"https://apify.com/yoloshii/gemini-file-search-builder"}},"_tags":["story","author_yoloshii","story_46260371","show_hn"],"author":"yoloshii","created_at":"2025-12-14T02:46:32Z","created_at_i":1765680392,"num_comments":0,"objectID":"46260371","points":1,"story_id":46260371,"story_text":"Simple Apify actor that scrapes websites and indexes them in Google's new Gemini File Search API (launched Nov 6).
The workflow: Scrape \u2192 Clean content \u2192 Upload to Gemini \u2192 Get permanent queryable knowledge base with automatic citations.
Technical approach:\n- Intelligent scraper selection from 5 Apify-native scrapers\n- Automatic content cleaning (strips nav/ads/fluff)\n- Uploads to Gemini File Search (persistent storage)\n- Per-page PPE pricing ($0.02 start, $0.0015/page)
Potential use cases:\n- Turn documentation into AI chatbots\n- Make company wikis naturally searchable\n- Build RAG apps without managing vector databases
Basically streamline your Gemini file search RAG ingestion with an Apify scraper run AIO.
You can also employ the actor programmatically with agents using Apify's actor mcp.
Built this over a weekend for the Apify 1M Actor Challenge. It's my first Apify actor, so curious to hear if the pricing makes sense.
Note* There is a banned websites to scrape list filter due to the constraints of the challenge. This will be lifted after the challenge ends (Jan 31, 2026).","title":"Show HN: Scrape websites into queryable Gemini RAG knowledge bases","updated_at":"2026-03-05T23:11:30Z","url":"https://apify.com/yoloshii/gemini-file-search-builder"},{"_highlightResult":{"author":{"matchLevel":"none","matchedWords":[],"value":"StephSpanjian"},"comment_text":{"fullyHighlighted":false,"matchLevel":"full","matchedWords":["vector","database","2026"],"value":"I shelved a project in March 2025 because it cost $360/month to run.
I rebuilt it in January 2026 for $1.12/month.
Same functionality. Better architecture. No vector database.
It's a RAG pipeline \u2014 API Gateway \u2192 Lambda \u2192 Amazon Bedrock \u2192 S3 embeddings \u2192 in-memory cosine similarity search. It lives on my site and answers questions about my experience and work history in real time, grounded in structured data I built and curated myself.
The interesting parts:\n\u2014 Why I killed OpenSearch after less than a week\n\u2014 How in-memory search outperformed a network call at this scale\n\u2014 The Anthropic/Bedrock access issue I still haven't fully resolved (Llama works fine)\n\u2014 Why I handcrafted every knowledge base chunk instead of automating it"},"story_title":{"matchLevel":"none","matchedWords":[],"value":"RAG on a Budget: How I Replaced a $360/Month OpenSearch Cluster for $1.12/Month"},"story_url":{"matchLevel":"none","matchedWords":[],"value":"https://stephaniespanjian.com/blog/rag-cost-reduction-replaced-opensearch-s3-in-memory-search"}},"_tags":["comment","author_StephSpanjian","story_47160232"],"author":"StephSpanjian","comment_text":"I shelved a project in March 2025 because it cost $360/month to run.
I rebuilt it in January 2026 for $1.12/month.
Same functionality. Better architecture. No vector database.
It's a RAG pipeline \u2014 API Gateway \u2192 Lambda \u2192 Amazon Bedrock \u2192 S3 embeddings \u2192 in-memory cosine similarity search. It lives on my site and answers questions about my experience and work history in real time, grounded in structured data I built and curated myself.
The interesting parts:\n\u2014 Why I killed OpenSearch after less than a week\n\u2014 How in-memory search outperformed a network call at this scale\n\u2014 The Anthropic/Bedrock access issue I still haven't fully resolved (Llama works fine)\n\u2014 Why I handcrafted every knowledge base chunk instead of automating it","created_at":"2026-02-26T00:38:33Z","created_at_i":1772066313,"objectID":"47160233","parent_id":47160232,"story_id":47160232,"story_title":"RAG on a Budget: How I Replaced a $360/Month OpenSearch Cluster for $1.12/Month","story_url":"https://stephaniespanjian.com/blog/rag-cost-reduction-replaced-opensearch-s3-in-memory-search","updated_at":"2026-03-05T23:37:31Z"},{"_highlightResult":{"author":{"matchLevel":"none","matchedWords":[],"value":"westurner"},"comment_text":{"fullyHighlighted":false,"matchLevel":"full","matchedWords":["vector","database","2026"],"value":"Np. Still learning about how to reference agentskills from my coding LLM here. Haven't yet worked with MCP or A2A much. I should port instruction prompts from each project's AGENTS.md to reusable skills in .claude/skills/skillname/SKILL.md ; so that I can reference "/skillname" in a prompt to reuse that prompt text.
Copilot looks for agent skills in .claude/skills/, .github/skills/, or .agents/skills/ .
FWIU there are package managers for agent skills?
PAKS: \nhttps://github.com/stakpak/paks
vercel-labs/skills: \nhttps://github.com/vercel-labs/skills :
export DISABLE_TELEMETRY=1\n npx skills add vercel-labs/agent-skills\nA reproducibility, traceability, and auditability concern:
How to show the text of the exact version of the skill referenced in each input prompt in each chat log? GH copilot's JSON export format is a fairly complete trace compared to e.g. Gemini Chat.
.
ElasticSearch (Java) and Meilisearch (Rust) do at least porter stemming before indexing.
MeiliSearch can be used as a vector database for langchain.
meilisearch/meilisearch: https://github.com/meilisearch/meilisearch :
Meilisearch docs > langchain guide > Performing Similarity Search: \nhttps://www.meilisearch.com/docs/guides/langchain#performing...
from langchain.vectorstores import Meilisearch\n from langchain.embeddings.openai import OpenAIEmbeddings\nopenobserve/openobserve : \nhttps://github.com/openobserve/openobserve :
> OpenObserve is an open-source observability platform for logs, metrics, traces, and frontend monitoring. A cost-effective alternative to Datadog, Splunk, and Elasticsearch with 140x lower storage costs and single binary deployment. with SQL in Rust
OpenObserve (AGPL) docs > MCP: \nhttps://openobserve.ai/docs/integration/mcp/ :
> This capability is supported in the Enterprise edition of OpenObserve
https://github.com/openobserve/openobserve/issues/6804
openobserve docs > Comparison with Alternatives > \nHow does OpenObserve compare to Elasticsearch: \nhttps://openobserve.ai/docs/overview/comparison/
meilisearch blog > "What is GraphRAG: Complete guide [2026]" https://www.meilisearch.com/blog/graph-rag :
> How is GraphRAG different from baseline RAG?
> GraphRAG represents one of the different types of RAG, and its retrieval process differs from baseline RAG.
> Baseline RAG is vector search-based, while GraphRAG uses structured relationships to get the end result. GraphRAG can still use vector and full-text search, but relationships drive what gets retrieved.
/? graphrag sqlite fts : https://www.google.com/search?q=graphrag+sqlite+fts"},"story_title":{"matchLevel":"none","matchedWords":[],"value":"Show HN: Saga \u2013 A Jira-like project tracker MCP server for AI agents (SQLite)"}},"_tags":["comment","author_westurner","story_47106215"],"author":"westurner","children":[47159534],"comment_text":"Np. Still learning about how to reference agentskills from my coding LLM here. Haven't yet worked with MCP or A2A much. I should port instruction prompts from each project's AGENTS.md to reusable skills in .claude/skills/skillname/SKILL.md ; so that I can reference "/skillname" in a prompt to reuse that prompt text.
Copilot looks for agent skills in .claude/skills/, .github/skills/, or .agents/skills/ .
FWIU there are package managers for agent skills?
PAKS: \nhttps://github.com/stakpak/paks
vercel-labs/skills: \nhttps://github.com/vercel-labs/skills :
export DISABLE_TELEMETRY=1\n npx skills add vercel-labs/agent-skills\nA reproducibility, traceability, and auditability concern:
How to show the text of the exact version of the skill referenced in each input prompt in each chat log? GH copilot's JSON export format is a fairly complete trace compared to e.g. Gemini Chat.
.
ElasticSearch (Java) and Meilisearch (Rust) do at least porter stemming before indexing.
MeiliSearch can be used as a vector database for langchain.
meilisearch/meilisearch: https://github.com/meilisearch/meilisearch :
Meilisearch docs > langchain guide > Performing Similarity Search: \nhttps://www.meilisearch.com/docs/guides/langchain#performing...
from langchain.vectorstores import Meilisearch\n from langchain.embeddings.openai import OpenAIEmbeddings\nopenobserve/openobserve : \nhttps://github.com/openobserve/openobserve :
> OpenObserve is an open-source observability platform for logs, metrics, traces, and frontend monitoring. A cost-effective alternative to Datadog, Splunk, and Elasticsearch with 140x lower storage costs and single binary deployment. with SQL in Rust
OpenObserve (AGPL) docs > MCP: \nhttps://openobserve.ai/docs/integration/mcp/ :
> This capability is supported in the Enterprise edition of OpenObserve
https://github.com/openobserve/openobserve/issues/6804
openobserve docs > Comparison with Alternatives > \nHow does OpenObserve compare to Elasticsearch: \nhttps://openobserve.ai/docs/overview/comparison/
meilisearch blog > "What is GraphRAG: Complete guide [2026]" https://www.meilisearch.com/blog/graph-rag :
> How is GraphRAG different from baseline RAG?
> GraphRAG represents one of the different types of RAG, and its retrieval process differs from baseline RAG.
> Baseline RAG is vector search-based, while GraphRAG uses structured relationships to get the end result. GraphRAG can still use vector and full-text search, but relationships drive what gets retrieved.
/? graphrag sqlite fts : https://www.google.com/search?q=graphrag+sqlite+fts","created_at":"2026-02-25T23:05:14Z","created_at_i":1772060714,"objectID":"47159322","parent_id":47143490,"story_id":47106215,"story_title":"Show HN: Saga \u2013 A Jira-like project tracker MCP server for AI agents (SQLite)","updated_at":"2026-03-05T23:37:28Z"},{"_highlightResult":{"author":{"matchLevel":"none","matchedWords":[],"value":"ckarani"},"comment_text":{"fullyHighlighted":false,"matchLevel":"full","matchedWords":["vector","database","2026"],"value":"I built Wax because every RAG solution required either Pinecone/Weaviate in the cloud or ChromaDB/Qdrant running locally. I wanted the SQLite of RAG -- import a library, open a file, query. Except for multimodal content at GPU speed.
The architecture that makes this work:\nMetal-accelerated vector search -- Embeddings live directly in unified memory (MTLBuffer). Zero CPU-GPU copy overhead. Adaptive SIMD4/SIMD8 kernels + GPU-side bitonic sort = sub-millisecond search on 10K+ vectors (vs ~100ms CPU). This isn't just "faster" -- it enables interactive search UX that wasn't possible before.
Atomic single-file storage (.mv2s) -- Everything in one crash-safe binary: embeddings, BM25 index, metadata, compressed payloads. Dual-header writes with generation counters = kill -9 safe. Sync via iCloud, email it, commit to git. The file format is deterministic -- identical input produces byte-identical output.
Query-adaptive hybrid fusion -- Four parallel search lanes (BM25, vector, timeline, structured memory). Lightweight classifier detects intent ("when did I..." \u2192 boost timeline, "find documentation about..." \u2192 boost BM25). Reciprocal Rank Fusion with deterministic tie-breaking = identical queries always return identical results.
Photo/Video RAG -- Index your photo library with OCR, captions, GPS binning, per-region embeddings. Query "find that receipt from the restaurant" searches text, visual similarity, and location simultaneously. Videos get segmented with keyframe embeddings + transcript mapping. Results include timecodes for jump-to-moment navigation. All offline -- iCloud-only photos get metadata-only indexing.\nSwift 6.2 strict concurrency -- Every orchestrator is an actor. Thread safety proven at compile time, not runtime. Zero data races, zero @unchecked Sendable, zero escape hatches.
Deterministic context assembly -- Same query + same data = byte-identical context every time. Three-tier surrogate compression (full/gist/micro) adapts based on memory age. Bundled cl100k_base tokenizer = no network, no nondeterminism.
import Wax
let brain = try await MemoryOrchestrator(at: URL(fileURLWithPath: "brain.mv2s"))
// Index\ntry await brain.remember("User prefers dark mode, gets headaches from bright screens")
// Retrieve\nlet context = try await brain.recall(query: "user display preferences")\n// Returns relevant memories with source attribution, ready for LLM context
What makes this different:
Zero dependencies on cloud infrastructure -- No API keys, no vendor lock-in, no telemetry\nProduction-grade concurrency -- Not "it works in my tests," but compile-time proven thread safety\nMultimodal from the ground up -- Text, photos, videos indexed with shared semantics\nPerformance that unlocks new UX -- Sub-millisecond latency enables real-time RAG workflows
## Wax Performance (Apple Silicon, as of Feb 17, 2026)
- 0.84ms vector search at 10K docs (Metal, warm cache)\n - 9.2ms first-query after cold-open for vector search\n - ~125x faster than CPU (105ms) and ~178x faster than SQLite FTS5 (150ms) in\n the same 10K benchmark\n - 17ms cold-open \u2192 first query overall\n - 10K ingest in 7.756s (~1289 docs/s) with hybrid batched ingest\n - 0.103s hybrid search on 10K docs\n - Recall path: 0.101\u20130.103s (smoke/standard workloads)\nThe storage format and search pipeline are stable. The API surface is early but functional. If you're building RAG into Swift apps, I'd love your feedback.
GitHub: https://github.com/christopherkarani/Wax
Star it if you're tired of spinning up vector databases for what should be a library call."},"story_title":{"matchLevel":"none","matchedWords":[],"value":"Sub-Millisecond RAG on Apple Silicon. No Server. No API. One File"},"story_url":{"matchLevel":"none","matchedWords":[],"value":"https://github.com/christopherkarani/Wax"}},"_tags":["comment","author_ckarani","story_47048731"],"author":"ckarani","children":[47051763,47051939,47052322],"comment_text":"I built Wax because every RAG solution required either Pinecone/Weaviate in the cloud or ChromaDB/Qdrant running locally. I wanted the SQLite of RAG -- import a library, open a file, query. Except for multimodal content at GPU speed.
The architecture that makes this work:\nMetal-accelerated vector search -- Embeddings live directly in unified memory (MTLBuffer). Zero CPU-GPU copy overhead. Adaptive SIMD4/SIMD8 kernels + GPU-side bitonic sort = sub-millisecond search on 10K+ vectors (vs ~100ms CPU). This isn't just "faster" -- it enables interactive search UX that wasn't possible before.
Atomic single-file storage (.mv2s) -- Everything in one crash-safe binary: embeddings, BM25 index, metadata, compressed payloads. Dual-header writes with generation counters = kill -9 safe. Sync via iCloud, email it, commit to git. The file format is deterministic -- identical input produces byte-identical output.
Query-adaptive hybrid fusion -- Four parallel search lanes (BM25, vector, timeline, structured memory). Lightweight classifier detects intent ("when did I..." \u2192 boost timeline, "find documentation about..." \u2192 boost BM25). Reciprocal Rank Fusion with deterministic tie-breaking = identical queries always return identical results.
Photo/Video RAG -- Index your photo library with OCR, captions, GPS binning, per-region embeddings. Query "find that receipt from the restaurant" searches text, visual similarity, and location simultaneously. Videos get segmented with keyframe embeddings + transcript mapping. Results include timecodes for jump-to-moment navigation. All offline -- iCloud-only photos get metadata-only indexing.\nSwift 6.2 strict concurrency -- Every orchestrator is an actor. Thread safety proven at compile time, not runtime. Zero data races, zero @unchecked Sendable, zero escape hatches.
Deterministic context assembly -- Same query + same data = byte-identical context every time. Three-tier surrogate compression (full/gist/micro) adapts based on memory age. Bundled cl100k_base tokenizer = no network, no nondeterminism.
import Wax
let brain = try await MemoryOrchestrator(at: URL(fileURLWithPath: "brain.mv2s"))
// Index\ntry await brain.remember("User prefers dark mode, gets headaches from bright screens")
// Retrieve\nlet context = try await brain.recall(query: "user display preferences")\n// Returns relevant memories with source attribution, ready for LLM context
What makes this different:
Zero dependencies on cloud infrastructure -- No API keys, no vendor lock-in, no telemetry\nProduction-grade concurrency -- Not "it works in my tests," but compile-time proven thread safety\nMultimodal from the ground up -- Text, photos, videos indexed with shared semantics\nPerformance that unlocks new UX -- Sub-millisecond latency enables real-time RAG workflows
## Wax Performance (Apple Silicon, as of Feb 17, 2026)
- 0.84ms vector search at 10K docs (Metal, warm cache)\n - 9.2ms first-query after cold-open for vector search\n - ~125x faster than CPU (105ms) and ~178x faster than SQLite FTS5 (150ms) in\n the same 10K benchmark\n - 17ms cold-open \u2192 first query overall\n - 10K ingest in 7.756s (~1289 docs/s) with hybrid batched ingest\n - 0.103s hybrid search on 10K docs\n - Recall path: 0.101\u20130.103s (smoke/standard workloads)\nThe storage format and search pipeline are stable. The API surface is early but functional. If you're building RAG into Swift apps, I'd love your feedback.
GitHub: https://github.com/christopherkarani/Wax
Star it if you're tired of spinning up vector databases for what should be a library call.","created_at":"2026-02-17T15:43:37Z","created_at_i":1771343017,"objectID":"47048732","parent_id":47048731,"story_id":47048731,"story_title":"Sub-Millisecond RAG on Apple Silicon. No Server. No API. One File","story_url":"https://github.com/christopherkarani/Wax","updated_at":"2026-03-05T23:34:26Z"},{"_highlightResult":{"author":{"matchLevel":"none","matchedWords":[],"value":"TeMPOraL"},"comment_text":{"fullyHighlighted":false,"matchLevel":"full","matchedWords":["vector","database","2026"],"value":"Deep Search is RAG - that is, if we're still expanding the acronym instead of treating it as a word that just means "queries a vector database".
Prediction for Next Hot Thing in Q4 2025 / Q1 2026: someone will make the Nobel prize-worthy discovery that you can stuff results of your deep search into a database (vector or otherwise) and then use it to improve the ability to compile a higher-quality report from much larger amount of sources.
We'll call it DeepRAG or Retrieval Augmented Deep Research or something.
Prediction for Q2 2026: next Nobel prize awarded for realizing you may as well stop treating report generation as the core aspect of "deep research" (as it obviously makes no sense, but hey, time traveler's spoilers, sorry!), and stop at the "stuff search results into a database" and let users "chat with the search results", making the research an interactive process.
We'll call this huge scientific breakthrough "DeepRAG With Human Feedback", or "DRHF"."},"story_title":{"matchLevel":"none","matchedWords":[],"value":"The Differences Between Deep Research, Deep Research, and Deep Research"},"story_url":{"matchLevel":"none","matchedWords":[],"value":"https://leehanchung.github.io/blogs/2025/02/26/deep-research/"}},"_tags":["comment","author_TeMPOraL","story_43236184"],"author":"TeMPOraL","children":[43296060,43338107],"comment_text":"Deep Search is RAG - that is, if we're still expanding the acronym instead of treating it as a word that just means "queries a vector database".
Prediction for Next Hot Thing in Q4 2025 / Q1 2026: someone will make the Nobel prize-worthy discovery that you can stuff results of your deep search into a database (vector or otherwise) and then use it to improve the ability to compile a higher-quality report from much larger amount of sources.
We'll call it DeepRAG or Retrieval Augmented Deep Research or something.
Prediction for Q2 2026: next Nobel prize awarded for realizing you may as well stop treating report generation as the core aspect of "deep research" (as it obviously makes no sense, but hey, time traveler's spoilers, sorry!), and stop at the "stuff search results into a database" and let users "chat with the search results", making the research an interactive process.
We'll call this huge scientific breakthrough "DeepRAG With Human Feedback", or "DRHF".","created_at":"2025-03-06T07:53:26Z","created_at_i":1741247606,"objectID":"43277591","parent_id":43267539,"story_id":43236184,"story_title":"The Differences Between Deep Research, Deep Research, and Deep Research","story_url":"https://leehanchung.github.io/blogs/2025/02/26/deep-research/","updated_at":"2025-04-16T15:43:58Z"},{"_highlightResult":{"author":{"matchLevel":"none","matchedWords":[],"value":"serengil"},"story_text":{"fullyHighlighted":false,"matchLevel":"partial","matchedWords":["vector","database"],"value":"DeepFace previously relied on filesystem-based datasets and pickle caches for face search, which made it stateful and hard to expose via APIs.
We introduced register and search functions that store embeddings in a backend DB (Postgres, Mongo, Weaviate, Neo4j).
This makes face recognition stateless, horizontally scalable, and suitable for API use.
For Postgres and Mongo, FAISS is used for ANN search; Weaviate and Neo4j handle vector indexing natively.
Additional databases and vector stores can be added over time."},"title":{"fullyHighlighted":false,"matchLevel":"partial","matchedWords":["vector"],"value":"Show HN: DeepFace now supports DB-backed vector search for face recognition"},"url":{"fullyHighlighted":false,"matchLevel":"partial","matchedWords":["2026"],"value":"https://sefiks.com/2026/01/01/introducing-brand-new-face-recognition-in-deepface/"}},"_tags":["story","author_serengil","story_46608519","show_hn"],"author":"serengil","created_at":"2026-01-13T21:37:22Z","created_at_i":1768340242,"num_comments":0,"objectID":"46608519","points":2,"story_id":46608519,"story_text":"DeepFace previously relied on filesystem-based datasets and pickle caches for face search, which made it stateful and hard to expose via APIs.
We introduced register and search functions that store embeddings in a backend DB (Postgres, Mongo, Weaviate, Neo4j).
This makes face recognition stateless, horizontally scalable, and suitable for API use.
For Postgres and Mongo, FAISS is used for ANN search; Weaviate and Neo4j handle vector indexing natively.
Additional databases and vector stores can be added over time.","title":"Show HN: DeepFace now supports DB-backed vector search for face recognition","updated_at":"2026-03-05T23:23:05Z","url":"https://sefiks.com/2026/01/01/introducing-brand-new-face-recognition-in-deepface/"},{"_highlightResult":{"author":{"matchLevel":"none","matchedWords":[],"value":"fs90"},"story_text":{"fullyHighlighted":false,"matchLevel":"full","matchedWords":["vector","database","2026"],"value":"Hey HN,
I've been working on a multi-model database called NodeDB.
Originally, i've found out the idea of SurrealDB quite good. However, it doesn't have some graph and vector features that I need. And since it is just a KV wrapper, instead of purpose-built engine, the performance will never be close to the specialized databases (like Neo4j, Pinecone, Clickhouse, etc).
And i've asked myself, what if, there is a database that have the same idea, but built differently? Instead of just treating it as KV database, we build specialized engines for the data.
Besides that, I want it to be able to support my IOT/edge project, where i need offline sync capabilities (Currentyl still in progress).
Will it work?
I put it into test. I've been experimenting and researching for a year, creating multiple versions, and then I created NodeDB.
Disclaimer: It is still in public beta (as of May 2026), but it really excites me if I can make this db work. And I use AI as assistant for coding and planning. It is nearly impossible to do as a solo developer without any AI assistance.
Would love feedback from HN:
- Are there specific features or improvements that would make it more useful?
If you're interested in experimenting or contributing, the repo is here: GitHub Repo: https://github.com/nodedb-lab/nodedb
Looking forward to your thoughts!"},"title":{"fullyHighlighted":false,"matchLevel":"partial","matchedWords":["database"],"value":"Show HN: NodeDB \u2013 High Perfomance Multi-Model Database"},"url":{"matchLevel":"none","matchedWords":[],"value":"https://github.com/nodedb-lab/nodedb"}},"_tags":["story","author_fs90","story_48102084","show_hn"],"author":"fs90","children":[48104383,48107469],"created_at":"2026-05-11T23:21:42Z","created_at_i":1778541702,"num_comments":1,"objectID":"48102084","points":5,"story_id":48102084,"story_text":"Hey HN,
I've been working on a multi-model database called NodeDB.
Originally, i've found out the idea of SurrealDB quite good. However, it doesn't have some graph and vector features that I need. And since it is just a KV wrapper, instead of purpose-built engine, the performance will never be close to the specialized databases (like Neo4j, Pinecone, Clickhouse, etc).
And i've asked myself, what if, there is a database that have the same idea, but built differently? Instead of just treating it as KV database, we build specialized engines for the data.
Besides that, I want it to be able to support my IOT/edge project, where i need offline sync capabilities (Currentyl still in progress).
Will it work?
I put it into test. I've been experimenting and researching for a year, creating multiple versions, and then I created NodeDB.
Disclaimer: It is still in public beta (as of May 2026), but it really excites me if I can make this db work. And I use AI as assistant for coding and planning. It is nearly impossible to do as a solo developer without any AI assistance.
Would love feedback from HN:
- Are there specific features or improvements that would make it more useful?
If you're interested in experimenting or contributing, the repo is here: GitHub Repo: https://github.com/nodedb-lab/nodedb
Looking forward to your thoughts!","title":"Show HN: NodeDB \u2013 High Perfomance Multi-Model Database","updated_at":"2026-05-24T15:54:17Z","url":"https://github.com/nodedb-lab/nodedb"},{"_highlightResult":{"author":{"matchLevel":"none","matchedWords":[],"value":"phillipclapham"},"story_text":{"fullyHighlighted":false,"matchLevel":"full","matchedWords":["vector","database","2026"],"value":"There is a shortfall to our current approach to agent memory. Right now, we are just collecting flat facts across a flat memory surface and creating vectorized chains of ambiguity, then wondering why when we ask an agent why it did something the best answer we can get is a probabilistic half-hallucinated half-answer that does not address the actual details of the issue, because it is simply pattern matching to find untyped similarities.
So I built FlowScript.
FlowScript is a typed reasoning graph that your agent builds through tool calls during your everyday work. It is NOT a graph database. What it is is a small set of unique opinionated primitives: things like thoughts, questions, decisions, blockers, and each of those have typed relationships between them. Your agent calls the tools as it works and it builds this typed graph, and then afterwards you can query that structure to get actual deterministic answers using five queries: tensions, blocked, why, whatIf, alternatives.
What does this look like in practice? Here's an agent that has been reasoning about database choices for a few sessions:
> mem.query.why("node_postgres_decision")\n\n PostgreSQL chosen\n \u2190 "Need ACID for payment processing"\n \u2190 "Original requirement: handle refunds atomically"\n \u2190 "Stripe webhook failures in staging revealed race condition"\n\n > mem.query.tensions()\n\n ><[performance vs cost]\n "Redis: sub-ms reads critical for UX" vs "Redis cluster: $200/mo for 3 nodes"\nOther memory systems, when they come across a tension or a contradiction, for the most part they are just simply deleting that. And that is wrong because that tension is new knowledge. Knowledge that we need to actually keep for auditing and because it tells us about the evolution of the system and its cognition over time. So instead of deleting contradictions, we relate and create named relationships for them. Relationships you can query.
Every decision, every tension, every piece of reasoning is being deterministically captured into an audit trail and hash-encoded. Now, not only do you have a deterministic reasoning chain, but that reasoning chain is auditable. You can go back to any point within the time that you have audit logs for and deterministically review and understand the actual reasoning chain that your model was using. Something that no other system can offer. The EU AI Act is going to require exactly this kind of transparency by August 2026, and as far as I can tell, FlowScript is the first open source agent memory system that is designed to meet that bar.
Try it NOW: Our MCP server in Claude Code or Cursor. Install and check our Get Started guide so you can add one JSON block to your editor config and drop a snippet into your project CLAUDE.md file, then restart. Your AI assistant gets a full set of reasoning tools that actually trace causality.
pip install flowscript-agents openai\nOr grab the TypeScript SDK for programmatic use:
npm install flowscript-core\nRepo: <https://github.com/phillipclapham/flowscript>\nDocs: <https://flowscript.org>\nPython SDK: <https://github.com/phillipclapham/flowscript-agents>"},"title":{"matchLevel":"none","matchedWords":[],"value":"Show HN: FlowScript \u2013 Agent memory where contradictions are features"},"url":{"matchLevel":"none","matchedWords":[],"value":"https://github.com/phillipclapham/flowscript"}},"_tags":["story","author_phillipclapham","story_47516792","show_hn"],"author":"phillipclapham","children":[47518627,47538689],"created_at":"2026-03-25T13:01:58Z","created_at_i":1774443718,"num_comments":1,"objectID":"47516792","points":2,"story_id":47516792,"story_text":"There is a shortfall to our current approach to agent memory. Right now, we are just collecting flat facts across a flat memory surface and creating vectorized chains of ambiguity, then wondering why when we ask an agent why it did something the best answer we can get is a probabilistic half-hallucinated half-answer that does not address the actual details of the issue, because it is simply pattern matching to find untyped similarities.
So I built FlowScript.
FlowScript is a typed reasoning graph that your agent builds through tool calls during your everyday work. It is NOT a graph database. What it is is a small set of unique opinionated primitives: things like thoughts, questions, decisions, blockers, and each of those have typed relationships between them. Your agent calls the tools as it works and it builds this typed graph, and then afterwards you can query that structure to get actual deterministic answers using five queries: tensions, blocked, why, whatIf, alternatives.
What does this look like in practice? Here's an agent that has been reasoning about database choices for a few sessions:
> mem.query.why("node_postgres_decision")\n\n PostgreSQL chosen\n \u2190 "Need ACID for payment processing"\n \u2190 "Original requirement: handle refunds atomically"\n \u2190 "Stripe webhook failures in staging revealed race condition"\n\n > mem.query.tensions()\n\n ><[performance vs cost]\n "Redis: sub-ms reads critical for UX" vs "Redis cluster: $200/mo for 3 nodes"\nOther memory systems, when they come across a tension or a contradiction, for the most part they are just simply deleting that. And that is wrong because that tension is new knowledge. Knowledge that we need to actually keep for auditing and because it tells us about the evolution of the system and its cognition over time. So instead of deleting contradictions, we relate and create named relationships for them. Relationships you can query.
Every decision, every tension, every piece of reasoning is being deterministically captured into an audit trail and hash-encoded. Now, not only do you have a deterministic reasoning chain, but that reasoning chain is auditable. You can go back to any point within the time that you have audit logs for and deterministically review and understand the actual reasoning chain that your model was using. Something that no other system can offer. The EU AI Act is going to require exactly this kind of transparency by August 2026, and as far as I can tell, FlowScript is the first open source agent memory system that is designed to meet that bar.
Try it NOW: Our MCP server in Claude Code or Cursor. Install and check our Get Started guide so you can add one JSON block to your editor config and drop a snippet into your project CLAUDE.md file, then restart. Your AI assistant gets a full set of reasoning tools that actually trace causality.
pip install flowscript-agents openai\nOr grab the TypeScript SDK for programmatic use:
npm install flowscript-core\nRepo: <https://github.com/phillipclapham/flowscript>\nDocs: <https://flowscript.org>\nPython SDK: <https://github.com/phillipclapham/flowscript-agents>","title":"Show HN: FlowScript \u2013 Agent memory where contradictions are features","updated_at":"2026-03-27T03:06:51Z","url":"https://github.com/phillipclapham/flowscript"},{"_highlightResult":{"author":{"matchLevel":"none","matchedWords":[],"value":"robeenly"},"story_text":{"fullyHighlighted":false,"matchLevel":"full","matchedWords":["vector","database","2026"],"value":"I've been working on NeuG (pronounced "new-gee"), an embeddable graph database that follows the same philosophy as sqlite and DuckDB \u2014 in-process, zero configuration, just pip install and query.
What's different from existing embedded graph DBs:
- Dual-mode: start embedded, flip one line to expose as a network service \u2014 same data, same queries, no migration\n- Built on GraphScope Flex, the engine behind the current LDBC SNB Interactive world record (80k+ QPS)
Local benchmark highlights on LDBC SNB SF1 (~3M nodes, 17M edges):
Embedded mode vs LadybugDB (Kuzu-based): NeuG wins 8/9 LSQB queries single-threaded vs LadybugDB's best multi-threaded result. 287x on triangle patterns (Q3), 91x on two-hop filtering (Q2).
Service mode vs Neo4j: 617 QPS vs Neo4j's 12 QPS on LDBC SNB Interactive \u2014 50.6x throughput. P95 latency 20ms vs Neo4j's 1,728ms.
Currently Python only. Node.js bindings and GraphRAG/vector extensions are on the roadmap.
Would love feedback \u2014 especially from anyone who's tried K\u00f9zu, LadybugDB, or runs Neo4j in production.
GitHub: https://github.com/alibaba/neug\nBlog post with full details: https://graphscope.io/blog/tech/2026/04/12/neug-one-engine-t..."},"title":{"matchLevel":"none","matchedWords":[],"value":"Show HN: NeuG \u2013 High-performance Embedded graph DB, one line to serve"}},"_tags":["story","author_robeenly","story_47843670","show_hn"],"author":"robeenly","created_at":"2026-04-21T02:03:31Z","created_at_i":1776737011,"num_comments":0,"objectID":"47843670","points":2,"story_id":47843670,"story_text":"I've been working on NeuG (pronounced "new-gee"), an embeddable graph database that follows the same philosophy as sqlite and DuckDB \u2014 in-process, zero configuration, just pip install and query.
What's different from existing embedded graph DBs:
- Dual-mode: start embedded, flip one line to expose as a network service \u2014 same data, same queries, no migration\n- Built on GraphScope Flex, the engine behind the current LDBC SNB Interactive world record (80k+ QPS)
Local benchmark highlights on LDBC SNB SF1 (~3M nodes, 17M edges):
Embedded mode vs LadybugDB (Kuzu-based): NeuG wins 8/9 LSQB queries single-threaded vs LadybugDB's best multi-threaded result. 287x on triangle patterns (Q3), 91x on two-hop filtering (Q2).
Service mode vs Neo4j: 617 QPS vs Neo4j's 12 QPS on LDBC SNB Interactive \u2014 50.6x throughput. P95 latency 20ms vs Neo4j's 1,728ms.
Currently Python only. Node.js bindings and GraphRAG/vector extensions are on the roadmap.
Would love feedback \u2014 especially from anyone who's tried K\u00f9zu, LadybugDB, or runs Neo4j in production.
GitHub: https://github.com/alibaba/neug\nBlog post with full details: https://graphscope.io/blog/tech/2026/04/12/neug-one-engine-t...","title":"Show HN: NeuG \u2013 High-performance Embedded graph DB, one line to serve","updated_at":"2026-04-21T02:44:17Z"},{"_highlightResult":{"author":{"matchLevel":"none","matchedWords":[],"value":"MissMajordazure"},"story_text":{"fullyHighlighted":false,"matchLevel":"full","matchedWords":["vector","database","2026"],"value":"Alphabet's upcoming policy to force developer verification for all sideloaded Android apps (effective September 2026) is being marketed as an anti-malware security update. In reality, it is the death of general-purpose computing on Android and a direct threat to enterprise and military operational security.
1. The Compromise of Enterprise and Air-Gapped OpSec\nBy forcing offline/sideloaded apps to pass through Alphabet's Play Protect verification pipeline, highly sensitive enterprise tools and proprietary air-gapped field apps are forced to "ping home" to Mountain View. Alphabet is inserting itself as a mandatory gatekeeper for internal trade secrets. True self-sovereign development environments are dead if local execution requires a cryptographic nod from a trillion-dollar monopoly.
2. The Death of Device Ownership\nThis marks the absolute end of the right to compile your own code and run it on hardware you physically own. If a student, a sysadmin, or a privacy advocate cannot execute a local binary without registering their real identity, paying a fee, and handing over signing keys to Google, they do not own the device. They are merely renting execution privileges.
3. The Frontline/Geopolitical Catastrophe\nThis is where the policy moves from anticompetitive to actively dangerous. Modern asymmetric warfare, such as the defense of Ukraine, relies heavily on COTS (Commercial Off-The-Shelf) Android devices.
Troops rely on custom, rapidly iterated, securely sideloaded APKs for encrypted communications, drone targeting, and artillery mapping (e.g., Kropyva). With this update, deploying new devices on the frontlines will require these highly classified, tactical applications to be subjected to Alphabet's signing APIs. \n- Military OpSec cannot rely on the uptime, database, or policy whims of a foreign tech corporation.\n- Pinging external servers for app authorization in a high-EW (Electronic Warfare) environment is an unacceptable vector for failure and geolocation tracking.
Alphabet is effectively introducing a kill switch that dictates who gets to deploy tactical software in active warzones. It is time to stop pretending this is about "user safety" and recognize it as an unprecedented enclosure of global hardware sovereignty."},"title":{"matchLevel":"none","matchedWords":[],"value":"Alphabet's sideloading auth: a kill switch for frontline and enterprise OpSec"}},"_tags":["story","author_MissMajordazure","story_47247588","ask_hn"],"author":"MissMajordazure","created_at":"2026-03-04T14:11:42Z","created_at_i":1772633502,"num_comments":0,"objectID":"47247588","points":2,"story_id":47247588,"story_text":"Alphabet's upcoming policy to force developer verification for all sideloaded Android apps (effective September 2026) is being marketed as an anti-malware security update. In reality, it is the death of general-purpose computing on Android and a direct threat to enterprise and military operational security.
1. The Compromise of Enterprise and Air-Gapped OpSec\nBy forcing offline/sideloaded apps to pass through Alphabet's Play Protect verification pipeline, highly sensitive enterprise tools and proprietary air-gapped field apps are forced to "ping home" to Mountain View. Alphabet is inserting itself as a mandatory gatekeeper for internal trade secrets. True self-sovereign development environments are dead if local execution requires a cryptographic nod from a trillion-dollar monopoly.
2. The Death of Device Ownership\nThis marks the absolute end of the right to compile your own code and run it on hardware you physically own. If a student, a sysadmin, or a privacy advocate cannot execute a local binary without registering their real identity, paying a fee, and handing over signing keys to Google, they do not own the device. They are merely renting execution privileges.
3. The Frontline/Geopolitical Catastrophe\nThis is where the policy moves from anticompetitive to actively dangerous. Modern asymmetric warfare, such as the defense of Ukraine, relies heavily on COTS (Commercial Off-The-Shelf) Android devices.
Troops rely on custom, rapidly iterated, securely sideloaded APKs for encrypted communications, drone targeting, and artillery mapping (e.g., Kropyva). With this update, deploying new devices on the frontlines will require these highly classified, tactical applications to be subjected to Alphabet's signing APIs. \n- Military OpSec cannot rely on the uptime, database, or policy whims of a foreign tech corporation.\n- Pinging external servers for app authorization in a high-EW (Electronic Warfare) environment is an unacceptable vector for failure and geolocation tracking.
Alphabet is effectively introducing a kill switch that dictates who gets to deploy tactical software in active warzones. It is time to stop pretending this is about "user safety" and recognize it as an unprecedented enclosure of global hardware sovereignty.","title":"Alphabet's sideloading auth: a kill switch for frontline and enterprise OpSec","updated_at":"2026-03-06T16:45:29Z"},{"_highlightResult":{"author":{"matchLevel":"none","matchedWords":[],"value":"quantdiy"},"comment_text":{"fullyHighlighted":false,"matchLevel":"full","matchedWords":["vector","database","2026"],"value":"In my hunt for an excellent open-source ERP, I couldn't help but be disappointed with the available options. No true lightweight, modern solution exists that I felt I should invest my time with. My other open-source project, QuanuX, is about to launch, and I wanted to set it up from the outset with a highly modern, scalable ERP solution.\nI've recently rebuilt the CLI for QuanuX in Go and had a fantastic experience. It quickly occurred to me that I could build my own ERP atop Google's IAM-based role management and Google Workspace\u2014completely eliminating the need for Twilio, WhatsApp, and a million third-party apps via the Workspace API. And since the Workspace API made this all possible, why not build the whole thing on GCP to complete the hat tip?
But I had to take it a step further. It's 2026\u2014who wants to run a boring ERP when agents or bots can manage it 100x better than humans?
Enter SKILL.md and what I call the "Knowledge Vector." By utilizing Google's GCP data suite (Vector/ScaNN) and Qdrant, GERP turns all SKILL.md files, Unix man pages, and developer docs into a perfect vector graph. This ensures any developer\u2014human or AI\u2014can enter the repository anywhere and instantly understand the laws of physics governing the system via semantic search.
Speaking of AI, my favorite tool in GERP is the native Model Context Protocol (MCP) server. It exposes the ERP's CLI tools directly over STDIO, allowing LLMs and AI Agents to natively read the immutable audit logs and trigger complex workflows without expensive context switching.
GERP is a headless ERP infrastructure built almost entirely in Go with a GraphQL-ready schema for your frontend integration. To achieve infinite horizontal scale, it uses zero SQL foreign keys. Instead, it uses a "Golden Thread" architecture across 8 perfectly isolated Google Cloud Spanner databases, and is orchestrated by Temporal Sagas to handle distributed ACID compensations.
There's a lot to add and a ways to go before it replaces NetSuite, but we aren't that far off!
Check it out: https://github.com/quantDIY/GERP\nThis is MIT Licensed and ready for you to explore.
@quantDIY"},"story_title":{"fullyHighlighted":false,"matchLevel":"partial","matchedWords":["vector"],"value":"GERP \u2013 A Headless ERP Built with Go, Spanner, Temporal, and GCP Vector"},"story_url":{"matchLevel":"none","matchedWords":[],"value":"https://github.com/quantDIY/GERP"}},"_tags":["comment","author_quantdiy","story_47534245"],"author":"quantdiy","comment_text":"In my hunt for an excellent open-source ERP, I couldn't help but be disappointed with the available options. No true lightweight, modern solution exists that I felt I should invest my time with. My other open-source project, QuanuX, is about to launch, and I wanted to set it up from the outset with a highly modern, scalable ERP solution.\nI've recently rebuilt the CLI for QuanuX in Go and had a fantastic experience. It quickly occurred to me that I could build my own ERP atop Google's IAM-based role management and Google Workspace\u2014completely eliminating the need for Twilio, WhatsApp, and a million third-party apps via the Workspace API. And since the Workspace API made this all possible, why not build the whole thing on GCP to complete the hat tip?
But I had to take it a step further. It's 2026\u2014who wants to run a boring ERP when agents or bots can manage it 100x better than humans?
Enter SKILL.md and what I call the "Knowledge Vector." By utilizing Google's GCP data suite (Vector/ScaNN) and Qdrant, GERP turns all SKILL.md files, Unix man pages, and developer docs into a perfect vector graph. This ensures any developer\u2014human or AI\u2014can enter the repository anywhere and instantly understand the laws of physics governing the system via semantic search.
Speaking of AI, my favorite tool in GERP is the native Model Context Protocol (MCP) server. It exposes the ERP's CLI tools directly over STDIO, allowing LLMs and AI Agents to natively read the immutable audit logs and trigger complex workflows without expensive context switching.
GERP is a headless ERP infrastructure built almost entirely in Go with a GraphQL-ready schema for your frontend integration. To achieve infinite horizontal scale, it uses zero SQL foreign keys. Instead, it uses a "Golden Thread" architecture across 8 perfectly isolated Google Cloud Spanner databases, and is orchestrated by Temporal Sagas to handle distributed ACID compensations.
There's a lot to add and a ways to go before it replaces NetSuite, but we aren't that far off!
Check it out: https://github.com/quantDIY/GERP\nThis is MIT Licensed and ready for you to explore.
@quantDIY","created_at":"2026-03-26T19:06:53Z","created_at_i":1774552013,"objectID":"47534370","parent_id":47534245,"story_id":47534245,"story_title":"GERP \u2013 A Headless ERP Built with Go, Spanner, Temporal, and GCP Vector","story_url":"https://github.com/quantDIY/GERP","updated_at":"2026-03-26T23:29:51Z"},{"_highlightResult":{"author":{"matchLevel":"none","matchedWords":[],"value":"linuxhiker"},"comment_text":{"fullyHighlighted":false,"matchLevel":"full","matchedWords":["vector","database","2026"],"value":"The Call for Papers is from:
Thursday, October 9. 2025 until Friday, January 30. 2026.
Your proposal is expected to be reviewed before:
Friday, February 6. 2026.
We have 6 tracks:
Postgres Extensions Day: Dedicated to developers building and maintaining PostgreSQL extensions. Share your work, learn from others, and connect with the extensions community.
Dev: Application development with PostgreSQL. Topics include using extensions like pg_vector for enhanced search performance, creating custom data types, building applications, and leveraging PostgreSQL features in your development workflow.
Ops: Operational practices for PostgreSQL and related technologies. Covers deployment, monitoring, performance tuning, backup strategies, high availability, replication, and infrastructure management.
Essentials: Deep dives into core PostgreSQL functionality. Explore data types, built-in features, query optimization, indexing strategies, and fundamental concepts. If it\u2019s in the documentation or should be, this track explores it thoroughly. Core PostgreSQL knowledge that provides long-term career value.
Life and Fun: Nothing about Postgres goes here. Non-technical topics that make us human. Share your hobbies, side projects, and interests outside of databases. Topics include beekeeping, gardening, homesteading, solar projects, IoT experiments, mountain biking, camping, and anything else that brings you joy.
Professional Development & Wellness: Career growth and personal well-being. Topics include career advancement, managing burnout, work-life integration, mental health, communication skills, leadership development, and building sustainable careers in technology."},"story_title":{"matchLevel":"none","matchedWords":[],"value":"[dead]"}},"_tags":["comment","author_linuxhiker","story_46722477"],"author":"linuxhiker","comment_text":"The Call for Papers is from:
Thursday, October 9. 2025 until Friday, January 30. 2026.
Your proposal is expected to be reviewed before:
Friday, February 6. 2026.
We have 6 tracks:
Postgres Extensions Day: Dedicated to developers building and maintaining PostgreSQL extensions. Share your work, learn from others, and connect with the extensions community.
Dev: Application development with PostgreSQL. Topics include using extensions like pg_vector for enhanced search performance, creating custom data types, building applications, and leveraging PostgreSQL features in your development workflow.
Ops: Operational practices for PostgreSQL and related technologies. Covers deployment, monitoring, performance tuning, backup strategies, high availability, replication, and infrastructure management.
Essentials: Deep dives into core PostgreSQL functionality. Explore data types, built-in features, query optimization, indexing strategies, and fundamental concepts. If it\u2019s in the documentation or should be, this track explores it thoroughly. Core PostgreSQL knowledge that provides long-term career value.
Life and Fun: Nothing about Postgres goes here. Non-technical topics that make us human. Share your hobbies, side projects, and interests outside of databases. Topics include beekeeping, gardening, homesteading, solar projects, IoT experiments, mountain biking, camping, and anything else that brings you joy.
Professional Development & Wellness: Career growth and personal well-being. Topics include career advancement, managing burnout, work-life integration, mental health, communication skills, leadership development, and building sustainable careers in technology.","created_at":"2026-01-22T17:36:45Z","created_at_i":1769103405,"objectID":"46722478","parent_id":46722477,"story_id":46722477,"story_title":"[dead]","updated_at":"2026-03-05T23:23:27Z"},{"_highlightResult":{"author":{"matchLevel":"none","matchedWords":[],"value":"gk1"},"title":{"fullyHighlighted":false,"matchLevel":"full","matchedWords":["vector","database","2026"],"value":"What is a Vector Database? (2021)"},"url":{"fullyHighlighted":false,"matchLevel":"partial","matchedWords":["vector","database"],"value":"https://www.pinecone.io/learn/vector-database/"}},"_tags":["story","author_gk1","story_35826929"],"author":"gk1","children":[35827373,35827433,35827436,35827557,35827628,35827656,35827660,35827679,35827714,35827760,35827782,35827823,35827922,35827995,35828055,35828069,35828072,35828098,35828106,35828445,35828667,35829097,35829580,35829972,35829991,35830004,35830034,35830862,35831384,35831642,35832000,35832016,35833786,35859089],"created_at":"2023-05-05T09:12:28Z","created_at_i":1683277948,"num_comments":202,"objectID":"35826929","points":409,"story_id":35826929,"title":"What is a Vector Database? (2021)","updated_at":"2025-12-14T20:35:08Z","url":"https://www.pinecone.io/learn/vector-database/"},{"_highlightResult":{"author":{"matchLevel":"none","matchedWords":[],"value":"Fendyfd"},"title":{"fullyHighlighted":false,"matchLevel":"full","matchedWords":["vector","database","2026"],"value":"Milvus Vector Database in 2023"},"url":{"fullyHighlighted":false,"matchLevel":"full","matchedWords":["vector","database","2026"],"value":"https://milvus.io/blog/milvus-in-2023-unprecedented-vector-database-amidst-tech-buzz.md"}},"_tags":["story","author_Fendyfd","story_38875103"],"author":"Fendyfd","children":[38875826],"created_at":"2024-01-05T02:43:54Z","created_at_i":1704422634,"num_comments":0,"objectID":"38875103","points":7,"story_id":38875103,"title":"Milvus Vector Database in 2023","updated_at":"2024-09-20T16:05:51Z","url":"https://milvus.io/blog/milvus-in-2023-unprecedented-vector-database-amidst-tech-buzz.md"},{"_highlightResult":{"author":{"matchLevel":"none","matchedWords":[],"value":"tim_sw"},"title":{"matchLevel":"none","matchedWords":[],"value":"AI startup Pinecone valued at $700M"},"url":{"fullyHighlighted":false,"matchLevel":"full","matchedWords":["vector","database","2026"],"value":"https://www.businessinsider.com/chroma-weaviate-pinecone-raise-funding-a16z-index-vector-database-ai-2023-3"}},"_tags":["story","author_tim_sw","story_35352194"],"author":"tim_sw","children":[35352731,35352797,35352837],"created_at":"2023-03-29T03:49:44Z","created_at_i":1680061784,"num_comments":6,"objectID":"35352194","points":13,"story_id":35352194,"title":"AI startup Pinecone valued at $700M","updated_at":"2024-09-20T13:39:05Z","url":"https://www.businessinsider.com/chroma-weaviate-pinecone-raise-funding-a16z-index-vector-database-ai-2023-3"},{"_highlightResult":{"author":{"matchLevel":"none","matchedWords":[],"value":"codekisser"},"comment_text":{"fullyHighlighted":false,"matchLevel":"full","matchedWords":["vector","database","2026"],"value":"what place do vector-native databases have in 2025? I feel using pgvector or redisearch works well and most setups will probably be using postgres or redis anyway."},"story_title":{"fullyHighlighted":false,"matchLevel":"partial","matchedWords":["database"],"value":"Show HN: Chroma Cloud \u2013 serverless search database for AI"},"story_url":{"matchLevel":"none","matchedWords":[],"value":"https://trychroma.com/cloud"}},"_tags":["comment","author_codekisser","story_44944241"],"author":"codekisser","children":[44954200,44954263],"comment_text":"what place do vector-native databases have in 2025? I feel using pgvector or redisearch works well and most setups will probably be using postgres or redis anyway.","created_at":"2025-08-19T17:38:26Z","created_at_i":1755625106,"objectID":"44954123","parent_id":44944241,"story_id":44944241,"story_title":"Show HN: Chroma Cloud \u2013 serverless search database for AI","story_url":"https://trychroma.com/cloud","updated_at":"2026-03-05T22:31:29Z"},{"_highlightResult":{"author":{"matchLevel":"none","matchedWords":[],"value":"blackcat201"},"comment_text":{"fullyHighlighted":false,"matchLevel":"full","matchedWords":["vector","database","2026"],"value":"I have been following the vector database trend back in 2020 and I ended up with the conclusion: vector search features are a nice to have features which adds more value on existing database (postgres) or text search services (elasticsearch) than using an entirely new framework full of hidden bugs. You could get way higher speedup when you are using the right embedding models and encoding way than just using the vector database with the best underlying optimization. And the bonus side is that you are using a stack which was battle tested (postgres, elasticsearch) vs new kids (pinecone, milvus ... )"},"story_title":{"fullyHighlighted":false,"matchLevel":"partial","matchedWords":["vector","database"],"value":"Do we really need a specialized vector database?"},"story_url":{"matchLevel":"none","matchedWords":[],"value":"https://modelz.ai/blog/pgvector"}},"_tags":["comment","author_blackcat201","story_37097004"],"author":"blackcat201","comment_text":"I have been following the vector database trend back in 2020 and I ended up with the conclusion: vector search features are a nice to have features which adds more value on existing database (postgres) or text search services (elasticsearch) than using an entirely new framework full of hidden bugs. You could get way higher speedup when you are using the right embedding models and encoding way than just using the vector database with the best underlying optimization. And the bonus side is that you are using a stack which was battle tested (postgres, elasticsearch) vs new kids (pinecone, milvus ... )","created_at":"2023-08-12T11:19:40Z","created_at_i":1691839180,"objectID":"37099031","parent_id":37097004,"story_id":37097004,"story_title":"Do we really need a specialized vector database?","story_url":"https://modelz.ai/blog/pgvector","updated_at":"2024-09-20T14:55:12Z"}],"hitsPerPage":20,"nbHits":167,"nbPages":9,"page":0,"params":"query=vector+database+2026&advancedSyntax=true&analyticsTags=backend","processingTimeMS":17,"processingTimingsMS":{"_request":{"roundTrip":15},"afterFetch":{"format":{"highlighting":2,"total":2},"merge":{"mergeLoop":{"prepareNextHit":2,"total":2},"total":2},"total":2},"fetch":{"query":5,"scanning":8,"total":14},"total":17},"query":"vector database 2026","serverTimeMS":20}