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":"Shrey_07"},"comment_text":{"fullyHighlighted":false,"matchLevel":"full","matchedWords":["vector","database","2026"],"value":"Location: India
Remote: Yes
Willing to relocate: Yes \u2014 anywhere. India, EU, US, UK.
Technologies: Python, PyTorch, Redis LLM inference, LLM fine-tuning (Qlora, peft), Google ADK, Agentic systems, FastAPI, Playwright, Docker, SQL, AWS, Tensorflow, MLflow, MCP, RAG, Neo4j, Git/Github, CI/CD, Typescript, API, scikit-learn, Vector Databases, HuggingFace.
Resume - https://drive.google.com/file/d/1qUxHkYu8dx866aGJy4-GLejJui7...
Email: shrey7shrey@gmail.com
---
2026 CS grad looking for my first full-time role. I build things that\nhave to actually work, and I spend most of my time on the part where\nthey don't.
KARMA \u2014 KARMA (github.com/ShreySharma07/Multi-Agentic-CUDA-optimization): a self-improving multi-agent system that writes and tunes GPU code. Five specialized agents profile, plan, code, test and reflect, with a vector memory that carries lessons from one kernel to the next. github.com/ShreySharma07/Multi-Agentic-CUDA-optimization
Repliq \u2014 a computer-use agent that turns one narrated screen recording\ninto a self-verifying execution plan. Runs a 20-step Salesforce workflow\nend to end. Same lesson, different shape: it used to report every run as\na success while records silently failed to save. Fixed by giving each\nprimitive a postcondition contract checked against real application\nstate, not against the click returning.\ngithub.com/ShreySharma07/salesforce-agent
Currently working on developing novel technique to post-tune Gemma 4 31B model for swe tasks."},"story_title":{"fullyHighlighted":false,"matchLevel":"partial","matchedWords":["2026"],"value":"Ask HN: Who wants to be hired? (October 2026)"}},"_tags":["comment","author_Shrey_07","story_49922568"],"author":"Shrey_07","comment_text":"Location: India
Remote: Yes
Willing to relocate: Yes \u2014 anywhere. India, EU, US, UK.
Technologies: Python, PyTorch, Redis LLM inference, LLM fine-tuning (Qlora, peft), Google ADK, Agentic systems, FastAPI, Playwright, Docker, SQL, AWS, Tensorflow, MLflow, MCP, RAG, Neo4j, Git/Github, CI/CD, Typescript, API, scikit-learn, Vector Databases, HuggingFace.
Resume - https://drive.google.com/file/d/1qUxHkYu8dx866aGJy4-GLejJui7...
Email: shrey7shrey@gmail.com
---
2026 CS grad looking for my first full-time role. I build things that\nhave to actually work, and I spend most of my time on the part where\nthey don't.
KARMA \u2014 KARMA (github.com/ShreySharma07/Multi-Agentic-CUDA-optimization): a self-improving multi-agent system that writes and tunes GPU code. Five specialized agents profile, plan, code, test and reflect, with a vector memory that carries lessons from one kernel to the next. github.com/ShreySharma07/Multi-Agentic-CUDA-optimization
Repliq \u2014 a computer-use agent that turns one narrated screen recording\ninto a self-verifying execution plan. Runs a 20-step Salesforce workflow\nend to end. Same lesson, different shape: it used to report every run as\na success while records silently failed to save. Fixed by giving each\nprimitive a postcondition contract checked against real application\nstate, not against the click returning.\ngithub.com/ShreySharma07/salesforce-agent
Currently working on developing novel technique to post-tune Gemma 4 31B model for swe tasks.","created_at":"2026-10-03T11:35:41Z","created_at_i":1791027341,"objectID":"49943331","parent_id":49922568,"story_id":49922568,"story_title":"Ask HN: Who wants to be hired? (October 2026)","updated_at":"2026-10-05T18:20:32Z"},{"_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":"DonHopkins"},"comment_text":{"fullyHighlighted":false,"matchLevel":"full","matchedWords":["vector","database","2026"],"value":"We had a GT40 at the University of Maryland Vax lab, which we would play Lunar Lander on when the Vax was down.
Scott Swazey gave a great talk at VCF West 2024 about restoring a GT40 and getting Lunar Lander running on it again, and it touches on everything in this thread: core memory, bootloaders, front panel single stepping, light pens, and retyping lost ROMs from listings.
https://www.youtube.com/watch?v=G6h6r6MGWyI
Your point about core surviving power cycles is part of the game (19:44): "because the game has core memory which is nonvolatile, so when I turn off the machine it saves everything, all of the carcasses from the crash landers of all the failed attempts are scattered across the screen. And interestingly enough, if you leave the game running long enough the game will crash, because there's no more memory left for any more carcasses."
https://www.youtube.com/watch?v=G6h6r6MGWyI&t=1184s
It was also arguably the first Easter egg, in 1973 (20:17). Land next to the McDonald's and the astronaut walks over and says "I'll take two cheeseburgers and a Big Mac to go." At a show he crashed into it instead and got "You have destroyed the only McDonald's on the moon", and since core remembers everything, nobody else could find it after that (21:13).
https://www.youtube.com/watch?v=G6h6r6MGWyI&t=1273s
The GT40 came up in a bootloader and pulled programs down the serial line, so no toggling, but debugging it was pure front panel. Hitting line feed crashed the PDP-11, so he single-stepped through the bootloader with a diagnostic card, down to a byte compare of the high byte, which goes through a shift, and found a dead 74194 4-bit shifter (15:50).
A PROM on one of the boards had failed, and no binary of it survived anywhere, so they typed its 256 entries back in from the listings (13:46). His rule number one is "don't trust anybody": he double-checked his friend's careful transcription and found two transposed digits that "would have created a bug so subtle that it would have taken us months to find it" (14:31). The same rule caught the downloaded diagnostics, which had a stray "!" and a newline inserted that made the loader abort (17:15). And on Bitsavers: "we could not have restored it without it" (13:10).
https://www.youtube.com/watch?v=G6h6r6MGWyI&t=826s
Other highlights: Atari's 1979 Lunar Lander turns out to be a direct copy of the GT40's vector generator, binary rate multipliers and all, with a 6502, ROM and static RAM swapped in for the PDP-11 and its expensive core (5:11). At VCF Midwest the wall power sagged to 90 volts, so he ran it off his camping battery (23:39). And he showed it next to the PDP-11/45 that animated the Death Star trench briefing in Star Wars, with a dueling light pen battle between the two (24:46).
I've been doing the same kind of thing without the soldering iron: bringing Heinz Lemke's 1972 PIXIE/SYMELEC light pen system for the PDP-7 and Type 340 back to life in a browser emulator, from a scanned listing, since no tape survives. Then DEC's own 1964 370 Light Pen Diagnostic, transcribed from a scan that skips from page 5 to page 7, so page 6 had to be rebuilt from how the surviving pages use each of its symbols.
Scott's rule number one turned out to be mine too. Every bug falls into one of three kinds: ours (the emulator got it wrong), the transcription's (the listing was misread off the scan), and 1972's (the listing itself is wrong, and the emulator should faithfully reproduce the mistake). The first one was a truncated literal pool. The conversion stopped at word 11741, so every (JMP INT literal read as 0, and the machine initialized itself into a wall. So far, every bug had its answer on paper before anyone went looking. The emulator's job is to run the listing until it disagrees with itself, and then to show where.
Bug Journal:
https://github.com/SimHacker/WillWrightShowForFood/blob/main...
370 Light Pen Diagnostic (DEC-4-45-M, 7-78-M):
https://github.com/SimHacker/WillWrightShowForFood/blob/main...
1972 PIXIE PDP-7 Assembler Listings:
https://github.com/SimHacker/WillWrightShowForFood/tree/main...
In 1972 the PDP-7 was the small one. It hung off Cambridge's Titan (an Atlas 2 that filled a room and ran the university) as a satellite, phoning home over Neil Wiseman's custom link to store and retrieve drawings in the Titan filestore.
The emulator inverts that: tiny-titan is the whole of Titan, as much of it as PIXIE ever saw, in one TypeScript file, serving its emulated satellite from inside a browser tab. It implements only what the one surviving caller ever dialed, and SYMELEC's unmodified link code runs against it.
Tiny Titan:
https://github.com/SimHacker/WillWrightShowForFood/blob/main...
tiny-titan.ts:
https://github.com/SimHacker/WillWrightShowForFood/blob/main...
Flight of the PIXIE - Yuja Wang:
https://www.youtube.com/watch?v=jDrqR9XssJI
PIXIE Live in PDP-7 Emulator with 340 Vector Display Simulator:
https://hyperties.org/databases/pixie/pixie-live/
Press the "DEMO" button and it will make a goofy child's drawing with the virtual light pen. I plan to ask Claude to make a new demo by trying to draw a pelican riding a bicycle.
Enable the MEMORY panel's "SOURCE" + "FOLLOW PC" mode, then slow the emulator down with the slider, to see the PDP-7 assembly source code it's executing (from the OCR of the scan of 128 pages of line printer output).
You can also pick "LIGHT PEN TEST (1964)" from the menu and press "DEMO", or pick "DUEL (1968)" and play spacewar for two, DECUS 7-40, loaded from paper tape through the RIM loader, the PDP-7's version of your bootstrap.
And I made a non-graphical "HILO (2026)" number guessing game and a "LUNAR LANDER (2026)" game to test out the TTY simulator. The lander is in the spirit of the turn-based original Scott describes (1:52), before the GT40 made it real time: "YOU ARE 500 FEET UP, FALLING AT 50 FT/S, WITH 60 UNITS OF FUEL."
Lander README:
https://github.com/SimHacker/WillWrightShowForFood/blob/main...
lander.s:
https://github.com/SimHacker/WillWrightShowForFood/blob/main...
PDP-7 Unix is coming soon. Warren Toomey, Phil Budne, Tom Everett, Sebastian Rasmussen, Robert Swierczek and friends did this kind of restoration on a much bigger scale with the pdp7-unix project. Starting in 2016 they typed in Ken Thompson's 1969-70 PDP-7 Unix from Norman Wilson's scans of the only surviving printouts, wrote a cross-assembler (as7) and a user-mode simulator, and got the kernel booting to a shell with a working filesystem.
In 2019 a second notebook of missing sources turned up and was scanned and typed in too, and in January 2020 it ran on a real PDP-7 at the Living Computer Museum. It even has moo, the bulls-and-cows number guessing game, a 1970 cousin of my HILO.
PDP-7 Unix:
https://github.com/DoctorWkt/pdp7-unix
Recovered Unix documents:
http://www.tuhs.org/Archive/Distributions/Research/McIlroy_v...
Their as7 was the precedent for my own assembler, which can run in the browser and produce symbol tables and source maps, the way a TypeScript to JavaScript compiler does. That's what drives the Memory panel's Source + Follow PC mode, and it's the groundwork for live coding:
https://github.com/SimHacker/WillWrightShowForFood/blob/main...
To run Unix, the cabinet needs what its SIMH script asks for: 8K with EAE, the teletype, the clock, and the RB09 fixed-head disk. It loads boot.rim, and the bootstrap reads the system from disk. So the new part is porting SIMH's RB09.
B comes with it: the interpreter (bi.s) and loader (bl.s) survive in the scans, and Robert Swierczek rebuilt the missing compiler in 2016. There's no C on the PDP-7. C came later on the PDP-11, and B was Thompson's cut-down BCPL.
The plan is in the cabinet README:
https://github.com/SimHacker/WillWrightShowForFood/blob/main...
And a couple days ago Mitch Bradley wrote a PDP-7 FORTH for it, including a Turtle Graphics package, which I'll integrate soon too! That's the other half of live coding. My assembler is TypeScript running on the emulator host, but Forth will run on the PDP-7 itself: you type new definitions at the emulated teletype, and the turtle draws them on the 340, interactively, in a language living inside the machine.
B compiles to threaded code too, so the cabinet will have two threaded interpreters, 1970 and 2026, running side by side!
Fittingly for a thread about whether the ENIAC had a BIOS: Mitch is the one who wrote Open Firmware, the Forth-based boot firmware in Sun workstations, PowerPC Macs, and the OLPC XO. So the PDP-7 is getting its Forth from the same man who invented Open Firmware to put Forth in the BIOS.
Mitch Bradley's PDP-7 Forth:
https://github.com/MitchBradley/pdp7forth/tree/main
PDP-7 Forth \u2014 Design Notes:
https://github.com/MitchBradley/pdp7forth/blob/main/DESIGN.m...
turtle.fs: Turtle Graphics for 340 vector graphics processor in FORTH (which works by assembling 340 display IOT opcodes):
https://github.com/MitchBradley/pdp7forth/blob/main/lib/turt...
Mitch Bradley singing the Open Firmware Song
https://www.youtube.com/watch?v=b8Wyvb9GotM
Mitch Bradley shows and explains Open Firmware
https://www.youtube.com/watch?v=KvxxAeuhPp0
Mitch's threading technique is a new one, as far as we can tell, small fast and elegant on the PDP-7. NEXT is three instructions, and the core of it is XCT I 10: it bumps an auto-index register and executes the thread cell it points at, so every cell in a compiled definition is itself a PDP-7 instruction, and its opcode is its type. CAL enters a colon word, JMP runs a primitive, and LAC or LAW pushes a constant or variable.
That makes location 10 a second program counter, running a virtual machine whose instruction set is the PDP-7's own. It doesn't fit Anton Ertl's threading taxonomy. For publication, "XCT Threading". For the T-shirt, "Indirectly Direct Threading".
PDP-7 Forth XCT Threading:
https://github.com/SimHacker/WillWrightShowForFood/blob/main..."},"story_title":{"matchLevel":"none","matchedWords":[],"value":"Alan Kay's answer to \u201cDid the ENIAC have a BIOS\u201d?"},"story_url":{"matchLevel":"none","matchedWords":[],"value":"https://www.quora.com/Did-the-ENIAC-have-a-BIOS/answer/Alan-Kay-11"}},"_tags":["comment","author_DonHopkins","story_49870070"],"author":"DonHopkins","comment_text":"We had a GT40 at the University of Maryland Vax lab, which we would play Lunar Lander on when the Vax was down.
Scott Swazey gave a great talk at VCF West 2024 about restoring a GT40 and getting Lunar Lander running on it again, and it touches on everything in this thread: core memory, bootloaders, front panel single stepping, light pens, and retyping lost ROMs from listings.
https://www.youtube.com/watch?v=G6h6r6MGWyI
Your point about core surviving power cycles is part of the game (19:44): "because the game has core memory which is nonvolatile, so when I turn off the machine it saves everything, all of the carcasses from the crash landers of all the failed attempts are scattered across the screen. And interestingly enough, if you leave the game running long enough the game will crash, because there's no more memory left for any more carcasses."
https://www.youtube.com/watch?v=G6h6r6MGWyI&t=1184s
It was also arguably the first Easter egg, in 1973 (20:17). Land next to the McDonald's and the astronaut walks over and says "I'll take two cheeseburgers and a Big Mac to go." At a show he crashed into it instead and got "You have destroyed the only McDonald's on the moon", and since core remembers everything, nobody else could find it after that (21:13).
https://www.youtube.com/watch?v=G6h6r6MGWyI&t=1273s
The GT40 came up in a bootloader and pulled programs down the serial line, so no toggling, but debugging it was pure front panel. Hitting line feed crashed the PDP-11, so he single-stepped through the bootloader with a diagnostic card, down to a byte compare of the high byte, which goes through a shift, and found a dead 74194 4-bit shifter (15:50).
A PROM on one of the boards had failed, and no binary of it survived anywhere, so they typed its 256 entries back in from the listings (13:46). His rule number one is "don't trust anybody": he double-checked his friend's careful transcription and found two transposed digits that "would have created a bug so subtle that it would have taken us months to find it" (14:31). The same rule caught the downloaded diagnostics, which had a stray "!" and a newline inserted that made the loader abort (17:15). And on Bitsavers: "we could not have restored it without it" (13:10).
https://www.youtube.com/watch?v=G6h6r6MGWyI&t=826s
Other highlights: Atari's 1979 Lunar Lander turns out to be a direct copy of the GT40's vector generator, binary rate multipliers and all, with a 6502, ROM and static RAM swapped in for the PDP-11 and its expensive core (5:11). At VCF Midwest the wall power sagged to 90 volts, so he ran it off his camping battery (23:39). And he showed it next to the PDP-11/45 that animated the Death Star trench briefing in Star Wars, with a dueling light pen battle between the two (24:46).
I've been doing the same kind of thing without the soldering iron: bringing Heinz Lemke's 1972 PIXIE/SYMELEC light pen system for the PDP-7 and Type 340 back to life in a browser emulator, from a scanned listing, since no tape survives. Then DEC's own 1964 370 Light Pen Diagnostic, transcribed from a scan that skips from page 5 to page 7, so page 6 had to be rebuilt from how the surviving pages use each of its symbols.
Scott's rule number one turned out to be mine too. Every bug falls into one of three kinds: ours (the emulator got it wrong), the transcription's (the listing was misread off the scan), and 1972's (the listing itself is wrong, and the emulator should faithfully reproduce the mistake). The first one was a truncated literal pool. The conversion stopped at word 11741, so every (JMP INT literal read as 0, and the machine initialized itself into a wall. So far, every bug had its answer on paper before anyone went looking. The emulator's job is to run the listing until it disagrees with itself, and then to show where.
Bug Journal:
https://github.com/SimHacker/WillWrightShowForFood/blob/main...
370 Light Pen Diagnostic (DEC-4-45-M, 7-78-M):
https://github.com/SimHacker/WillWrightShowForFood/blob/main...
1972 PIXIE PDP-7 Assembler Listings:
https://github.com/SimHacker/WillWrightShowForFood/tree/main...
In 1972 the PDP-7 was the small one. It hung off Cambridge's Titan (an Atlas 2 that filled a room and ran the university) as a satellite, phoning home over Neil Wiseman's custom link to store and retrieve drawings in the Titan filestore.
The emulator inverts that: tiny-titan is the whole of Titan, as much of it as PIXIE ever saw, in one TypeScript file, serving its emulated satellite from inside a browser tab. It implements only what the one surviving caller ever dialed, and SYMELEC's unmodified link code runs against it.
Tiny Titan:
https://github.com/SimHacker/WillWrightShowForFood/blob/main...
tiny-titan.ts:
https://github.com/SimHacker/WillWrightShowForFood/blob/main...
Flight of the PIXIE - Yuja Wang:
https://www.youtube.com/watch?v=jDrqR9XssJI
PIXIE Live in PDP-7 Emulator with 340 Vector Display Simulator:
https://hyperties.org/databases/pixie/pixie-live/
Press the "DEMO" button and it will make a goofy child's drawing with the virtual light pen. I plan to ask Claude to make a new demo by trying to draw a pelican riding a bicycle.
Enable the MEMORY panel's "SOURCE" + "FOLLOW PC" mode, then slow the emulator down with the slider, to see the PDP-7 assembly source code it's executing (from the OCR of the scan of 128 pages of line printer output).
You can also pick "LIGHT PEN TEST (1964)" from the menu and press "DEMO", or pick "DUEL (1968)" and play spacewar for two, DECUS 7-40, loaded from paper tape through the RIM loader, the PDP-7's version of your bootstrap.
And I made a non-graphical "HILO (2026)" number guessing game and a "LUNAR LANDER (2026)" game to test out the TTY simulator. The lander is in the spirit of the turn-based original Scott describes (1:52), before the GT40 made it real time: "YOU ARE 500 FEET UP, FALLING AT 50 FT/S, WITH 60 UNITS OF FUEL."
Lander README:
https://github.com/SimHacker/WillWrightShowForFood/blob/main...
lander.s:
https://github.com/SimHacker/WillWrightShowForFood/blob/main...
PDP-7 Unix is coming soon. Warren Toomey, Phil Budne, Tom Everett, Sebastian Rasmussen, Robert Swierczek and friends did this kind of restoration on a much bigger scale with the pdp7-unix project. Starting in 2016 they typed in Ken Thompson's 1969-70 PDP-7 Unix from Norman Wilson's scans of the only surviving printouts, wrote a cross-assembler (as7) and a user-mode simulator, and got the kernel booting to a shell with a working filesystem.
In 2019 a second notebook of missing sources turned up and was scanned and typed in too, and in January 2020 it ran on a real PDP-7 at the Living Computer Museum. It even has moo, the bulls-and-cows number guessing game, a 1970 cousin of my HILO.
PDP-7 Unix:
https://github.com/DoctorWkt/pdp7-unix
Recovered Unix documents:
http://www.tuhs.org/Archive/Distributions/Research/McIlroy_v...
Their as7 was the precedent for my own assembler, which can run in the browser and produce symbol tables and source maps, the way a TypeScript to JavaScript compiler does. That's what drives the Memory panel's Source + Follow PC mode, and it's the groundwork for live coding:
https://github.com/SimHacker/WillWrightShowForFood/blob/main...
To run Unix, the cabinet needs what its SIMH script asks for: 8K with EAE, the teletype, the clock, and the RB09 fixed-head disk. It loads boot.rim, and the bootstrap reads the system from disk. So the new part is porting SIMH's RB09.
B comes with it: the interpreter (bi.s) and loader (bl.s) survive in the scans, and Robert Swierczek rebuilt the missing compiler in 2016. There's no C on the PDP-7. C came later on the PDP-11, and B was Thompson's cut-down BCPL.
The plan is in the cabinet README:
https://github.com/SimHacker/WillWrightShowForFood/blob/main...
And a couple days ago Mitch Bradley wrote a PDP-7 FORTH for it, including a Turtle Graphics package, which I'll integrate soon too! That's the other half of live coding. My assembler is TypeScript running on the emulator host, but Forth will run on the PDP-7 itself: you type new definitions at the emulated teletype, and the turtle draws them on the 340, interactively, in a language living inside the machine.
B compiles to threaded code too, so the cabinet will have two threaded interpreters, 1970 and 2026, running side by side!
Fittingly for a thread about whether the ENIAC had a BIOS: Mitch is the one who wrote Open Firmware, the Forth-based boot firmware in Sun workstations, PowerPC Macs, and the OLPC XO. So the PDP-7 is getting its Forth from the same man who invented Open Firmware to put Forth in the BIOS.
Mitch Bradley's PDP-7 Forth:
https://github.com/MitchBradley/pdp7forth/tree/main
PDP-7 Forth \u2014 Design Notes:
https://github.com/MitchBradley/pdp7forth/blob/main/DESIGN.m...
turtle.fs: Turtle Graphics for 340 vector graphics processor in FORTH (which works by assembling 340 display IOT opcodes):
https://github.com/MitchBradley/pdp7forth/blob/main/lib/turt...
Mitch Bradley singing the Open Firmware Song
https://www.youtube.com/watch?v=b8Wyvb9GotM
Mitch Bradley shows and explains Open Firmware
https://www.youtube.com/watch?v=KvxxAeuhPp0
Mitch's threading technique is a new one, as far as we can tell, small fast and elegant on the PDP-7. NEXT is three instructions, and the core of it is XCT I 10: it bumps an auto-index register and executes the thread cell it points at, so every cell in a compiled definition is itself a PDP-7 instruction, and its opcode is its type. CAL enters a colon word, JMP runs a primitive, and LAC or LAW pushes a constant or variable.
That makes location 10 a second program counter, running a virtual machine whose instruction set is the PDP-7's own. It doesn't fit Anton Ertl's threading taxonomy. For publication, "XCT Threading". For the T-shirt, "Indirectly Direct Threading".
PDP-7 Forth XCT Threading:
https://github.com/SimHacker/WillWrightShowForFood/blob/main...","created_at":"2026-09-28T09:10:27Z","created_at_i":1790586627,"objectID":"49875390","parent_id":49874328,"story_id":49870070,"story_title":"Alan Kay's answer to \u201cDid the ENIAC have a BIOS\u201d?","story_url":"https://www.quora.com/Did-the-ENIAC-have-a-BIOS/answer/Alan-Kay-11","updated_at":"2026-10-02T21:55:21Z"},{"_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":"Xyra"},"story_text":{"fullyHighlighted":false,"matchLevel":"full","matchedWords":["vector","database","2026"],"value":"Meet Scry, a 500 TB NVMe internet index in ClickHouse that you can run ~arbitrary readonly SQL and some of Datalog over, and I handle the problem of resource-contention with congestion-based micro-auction pricing. When there's capacity, the service is free for non-commercial use.
---
Hello. It's 2026, we're training simulated fruit fly brains to play Beat Saber, do we still have to be stuck with internet (re)search as fn: natural language -> black box we can't do anything about -> ranked_list/summary?
There is a long history of people trying to do very fancy things that end up being done in relational databases and a little SQL. There is a gravity to them, a bitter lesson, just like scaling of generalized ml training methods. I mean many, many information products can be built off essentially giant real-time OLAP databases and frontier LLMs writing brilliant SQL+Datalog+vector+Jev etc. queries.
Google Search, Tavily, Exa essentially have the problem of mapping your agents' context you are willing to provide, to a tiny subset of their index. You pay a fixed cost to an extremely hard problem that has a distribution of hardness, which means YOU eat the downsides when they are running out of budgeted compute to help you out.
Their algorithms are opaque to the caller, there's really not much user control, and there's not a serious opportunity to communally improve search recipes, like the lexical+Jev recipes you trust to select bleeding edge AI builders.
Furthermore, search companies aren't even pursuing text-to-SQL anymore (several have talked to me)... they made up their minds during the traumatic 2024 text-to-sql days. They were just too early.
I hope you enjoy. I'm intent on scaling this paradigm on differentiated hardware over much more data, so any compelling use cases or queries I could show off, would be much appreciated!"},"title":{"matchLevel":"none","matchedWords":[],"value":"Show HN: Scry, programmable internet search w/ congestion pricing"},"url":{"matchLevel":"none","matchedWords":[],"value":"https://scry.io/"}},"_tags":["story","author_Xyra","story_49748041","show_hn"],"author":"Xyra","children":[49757027,49757277,49758153,49758377,49758662,49759078,49759187,49759384,49759905,49759920,49760028,49761097,49762681,49787735],"created_at":"2026-09-17T23:15:57Z","created_at_i":1789686957,"num_comments":26,"objectID":"49748041","points":61,"story_id":49748041,"story_text":"Meet Scry, a 500 TB NVMe internet index in ClickHouse that you can run ~arbitrary readonly SQL and some of Datalog over, and I handle the problem of resource-contention with congestion-based micro-auction pricing. When there's capacity, the service is free for non-commercial use.
---
Hello. It's 2026, we're training simulated fruit fly brains to play Beat Saber, do we still have to be stuck with internet (re)search as fn: natural language -> black box we can't do anything about -> ranked_list/summary?
There is a long history of people trying to do very fancy things that end up being done in relational databases and a little SQL. There is a gravity to them, a bitter lesson, just like scaling of generalized ml training methods. I mean many, many information products can be built off essentially giant real-time OLAP databases and frontier LLMs writing brilliant SQL+Datalog+vector+Jev etc. queries.
Google Search, Tavily, Exa essentially have the problem of mapping your agents' context you are willing to provide, to a tiny subset of their index. You pay a fixed cost to an extremely hard problem that has a distribution of hardness, which means YOU eat the downsides when they are running out of budgeted compute to help you out.
Their algorithms are opaque to the caller, there's really not much user control, and there's not a serious opportunity to communally improve search recipes, like the lexical+Jev recipes you trust to select bleeding edge AI builders.
Furthermore, search companies aren't even pursuing text-to-SQL anymore (several have talked to me)... they made up their minds during the traumatic 2024 text-to-sql days. They were just too early.
I hope you enjoy. I'm intent on scaling this paradigm on differentiated hardware over much more data, so any compelling use cases or queries I could show off, would be much appreciated!","title":"Show HN: Scry, programmable internet search w/ congestion pricing","updated_at":"2026-09-24T09:58:37Z","url":"https://scry.io/"},{"_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-09-09T08:12:50Z"},{"_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/"}],"hitsPerPage":20,"nbHits":173,"nbPages":9,"page":0,"params":"query=vector+database+2026&advancedSyntax=true&analyticsTags=backend","processingTimeMS":33,"processingTimingsMS":{"_request":{"queue":269,"roundTrip":13},"afterFetch":{"format":{"highlighting":5,"total":6},"total":1},"fetch":{"query":12,"scanning":18,"total":31},"total":33},"query":"vector database 2026","serverTimeMS":309}