{
  "source_file": "0930",
  "source_platform": "Dev.to",
  "author": "Priyesh Dave",
  "title_listed": "Vector, Graph, or SQL? What Actually Works for Production AI Agent Memory",
  "keywords": "",
  "domain": "大模型算法",
  "content_type": "技术教程",
  "is_paid_flag": "否",
  "url": "https://dev.to/priyeshdave6/vector-graph-or-sql-what-actually-works-for-production-ai-agent-memory-5h6p",
  "publish_date": "2026-09-02",
  "corpus_stage": "",
  "notes": "",
  "id": "a5fa6c589e47",
  "collected_at": "2026-10-02T13:50:08",
  "title": "Vector, Graph, or SQL? What Actually Works for Production AI Agent Memory - DEV Community",
  "body_markdown": "Vector, Graph, or SQL? What Actually Works for Production AI Agent Memory\nScalable agent memory is no longer a side project. Below are direct, runnable benchmarks comparing vector store, graph, and SQL agent memory—where each fails, which one holds up under realistic loads, and numbers for latency, recall, and operational pain. At scale, the right call means the difference between a stable system and endless triage.\nAgent Memory Becomes the Bottleneck Before the LLM Fails\nMost AI agent demos end once the LLM spits out an answer from some context window. In production, that's not where systems break. Failures typically strike at the memory and query layers:\nLatency spikes the instant your index outgrows demo scale.\nEmbedding-only recall regurgitates \"semantically similar\" content that's factually wrong or structurally useless.\n\"Just swap in a bigger store\" becomes a trap: agents break when working set exceeds RAM or when relationships need tracking.\nSerious agent workloads—continuous learning, chaining, multi-user context—hit hard limits on memory performance and retrieval quality. The naive \"just use a vector DB\" strategy disintegrates at scale, with link-heavy context, or when it's time to debug.\nVector Stores: High Throughput, Bad at Structure\nVector databases (FAISS, Chroma, Pinecone, etc.) remain the obvious default for LLM memory. They deliver unbeatable raw embedding search for static text or code. That speed collapses once you need structure or linked context.\nReal-World FAISS Latency\nA 10,000-record FAISS in-memory store, basic retrieval:\nimport\nfaiss\nimport\nnumpy\nas\nnp\nimport\ntime\ndim\n=\n1536\n# OpenAI/text-embedding-ada-002\nnum_vectors\n=\n10_000\nnp\n.\nrandom\n.\nseed\n(\n42\n)\nvectors\n=\nnp\n.\nrandom\n.\nrandn\n(\nnum_vectors\n,\ndim\n).\nastype\n(\nnp\n.\nfloat32\n)\nindex\n=\nfaiss\n.\nIndexFlatL2\n(\ndim\n)\nindex\n.\nadd\n(\nvectors\n)\nquery\n=\nnp\n.\nrandom\n.\nrandn\n(\n1\n,\ndim\n).\nastype\n(\nnp\n.\nfloat32\n)\nstart\n=\ntime\n.\ntime\n()\nD\n,\nI\n=\nindex\n.\nsearch\n(\nquery\n,\nk\n=\n5\n)\nlatency\n=\n(\ntime\n.\ntime\n()\n-\nstart\n)\n*\n1000\nprint\n(\nf\n\"\nFAISS top-5 retrieval latency:\n{\nlatency\n:\n.\n2\nf\n}\nms\n\"\n)\nEnter fullscreen mode\nExit fullscreen mode\nObserved:\nsub-10ms per query for <100k vectors in-memory. Pure brute force similarity wins here.\nStructural Recall: Major Gaps\nNo sense of order or event sequence. You can't natively fetch \"what happened just before this?\" or \"all records tagged as X.\"\nMixed or repetitive context? Embeddings start returning lookalikes, not what's actually relevant—unless you bolt on clumsy metadata filtering.\nTrivial to one-hop recall, hopeless on context chains, dialogue threads, or anything resembling a dependency graph.\nWhy It Fails: Example\nSuppose the agent must recall a meeting summary\nand\nlink to prior related action items. Pure vector search drags in loosely related content, often missing explicit cross-document links that actually matter.\nStore both summaries and discrete action items as vectors.\nQuery for \"next steps from last week’s planning meeting.\"\nReturns lookalike text, with a strong chance of contaminating context across multiple meetings or omitting key items.\nGraph Databases: Explicit Relationships, Real Scalability Headaches\nGraph DBs (Neo4j, RedisGraph, Memgraph) encode relationships naturally. For context-chaining, they're far stronger than vectors. But writes and complex queries go nonlinear fast.\nNeo4j for Agent Memory: Insert and Query\nImagine agent events as nodes (\nEvent\n) with types and\nRELATED_TO\nedges.\nfrom\nneo4j\nimport\nGraphDatabase\nimport\ntime\nuri\n=\n\"\nbolt://localhost:7687\n\"\ndriver\n=\nGraphDatabase\n.\ndriver\n(\nuri\n,\nauth\n=\n(\n\"\nneo4j\n\"\n,\n\"\ntest\n\"\n))\ndef\nadd_event\n(\ntx\n,\nevent_id\n,\nevent_type\n,\ncontent\n,\ntimestamp\n):\ntx\n.\nrun\n(\n\"\nMERGE (e:Event {id: $event_id, type: $event_type, content: $content, ts: $timestamp})\n\"\n,\nevent_id\n=\nevent_id\n,\nevent_type\n=\nevent_type\n,\ncontent\n=\ncontent\n,\ntimestamp\n=\ntimestamp\n)\ndef\nlink_events\n(\ntx\n,\nfrom_id\n,\nto_id\n):\ntx\n.\nrun\n(\n\"\nMATCH (a:Event {id: $from_id}), (b:Event {id: $to_id})\n\"\n\"\nMERGE (a)-[:RELATED_TO]->(b)\n\"\n,\nfrom_id\n=\nfrom_id\n,\nto_id\n=\nto_id\n,\n)\nwith\ndriver\n.\nsession\n()\nas\nsession\n:\nstart\n=\ntime\n.\ntime\n()\nfor\ni\nin\nrange\n(\n5000\n):\nsession\n.\nwrite_transaction\n(\nadd_event\n,\nf\n\"\nevt_\n{\ni\n}\n\"\n,\n\"\nsummary\n\"\n,\nf\n\"\ncontent_\n{\ni\n}\n\"\n,\ni\n)\nfor\ni\nin\nrange\n(\n1\n,\n5000\n):\nsession\n.\nwrite_transaction\n(\nlink_events\n,\nf\n\"\nevt_\n{\ni\n-\n1\n}\n\"\n,\nf\n\"\nevt_\n{\ni\n}\n\"\n)\nlatency\n=\n(\ntime\n.\ntime\n()\n-\nstart\n)\n*\n1000\nprint\n(\nf\n\"\nNeo4j insert + link 5k events:\n{\nlatency\n:\n.\n2\nf\n}\nms\n\"\n)\nquery_start\n=\ntime\n.\ntime\n()\nres\n=\nsession\n.\nrun\n(\n\"\nMATCH (e:Event)-[:RELATED_TO*1..3]->(other) WHERE e.id=\n'\nevt_1000\n'\n\"\n\"\nRETURN other LIMIT 5\n\"\n)\nprint\n(\nf\n\"\n3-hop query latency:\n{\n(\ntime\n.\ntime\n()\n-\nquery_start\n)\n*\n1000\n:\n.\n2\nf\n}\nms\n\"\n)\nEnter fullscreen mode\nExit fullscreen mode\nWhere Graph DBs Lose\nInserts are at least 10x slower than vector DBs—tens of ms per 1,000 edge inserts.\nMulti-hop queries (\n*..n\nrelationship traversals) explode in cost as your schema gets deeper or more cyclic.\nCypher queries quickly get unreadable; any \"fuzzy\" or similarity-weighted search is a hack or plugin.\nHybrid semantic search requires nontrivial extension work.\nSchema tip:\nNodes for each event, typed with labels; edges for relationships.\nPitfall:\nDeep, cyclic, or cross-linked graphs crush traversal speed.\nSQL: The Overlooked Hybrid Memory That Holds Up\nSQL (Postgres, SQLite) has a bad rep among LLM agent tinkerers, but that’s a miss. With a competent schema and minimal vector support, SQL wins for compound recall and operational scaling.\nPython + SQLite: Real Hybrid Recall\nimport\nsqlite3\nimport\nnumpy\nas\nnp\nimport\ntime\nconn\n=\nsqlite3\n.\nconnect\n(\n\"\n:memory:\n\"\n)\nc\n=\nconn\n.\ncursor\n()\nc\n.\nexecute\n(\n'''\nCREATE TABLE memory (\n    id INTEGER PRIMARY KEY,\n    type TEXT,\n    content TEXT,\n    ts INTEGER,\n    embedding BLOB\n)\n'''\n)\ndef\nto_blob\n(\nx\n):\nreturn\nx\n.\nastype\n(\nnp\n.\nfloat32\n).\ntobytes\n()\nembeddings\n=\nnp\n.\nrandom\n.\nrandn\n(\n10000\n,\n1536\n)\nstart\n=\ntime\n.\ntime\n()\nfor\ni\nin\nrange\n(\n10000\n):\nc\n.\nexecute\n(\n\"\nINSERT INTO memory (type, content, ts, embedding) VALUES (?, ?, ?, ?)\n\"\n,\n(\n'\nsummary\n'\n,\nf\n\"\ncontent_\n{\ni\n}\n\"\n,\ni\n,\nto_blob\n(\nembeddings\n[\ni\n])))\nconn\n.\ncommit\n()\nprint\n(\nf\n\"\nSQLite 10k row insert:\n{\n(\ntime\n.\ntime\n()\n-\nstart\n)\n*\n1000\n:\n.\n2\nf\n}\nms\n\"\n)\ndef\nsearch\n(\nquery_embed\n,\nk\n=\n5\n):\nc\n.\nexecute\n(\n\"\nSELECT content, embedding FROM memory WHERE type=\n'\nsummary\n'\nAND ts BETWEEN 0 AND 5000\n\"\n)\nrows\n=\nc\n.\nfetchall\n()\nX\n=\nnp\n.\narray\n([\nnp\n.\nfrombuffer\n(\nrow\n[\n1\n],\ndtype\n=\nnp\n.\nfloat32\n)\nfor\nrow\nin\nrows\n])\ndists\n=\nnp\n.\nlinalg\n.\nnorm\n(\nX\n-\nquery_embed\n,\naxis\n=\n1\n)\ntopk\n=\nnp\n.\nargsort\n(\ndists\n)[:\nk\n]\nreturn\n[\nrows\n[\ni\n][\n0\n]\nfor\ni\nin\ntopk\n]\nqvec\n=\nnp\n.\nrandom\n.\nrandn\n(\n1\n,\n1536\n)\nstart\n=\ntime\n.\ntime\n()\nresults\n=\nsearch\n(\nqvec\n[\n0\n],\nk\n=\n5\n)\nprint\n(\nf\n\"\nSQLite hybrid filter + search latency:\n{\n(\ntime\n.\ntime\n()\n-\nstart\n)\n*\n1000\n:\n.\n2\nf\n}\nms\n\"\n)\nEnter fullscreen mode\nExit fullscreen mode\nWhere SQL Wins\nMulti-constraint queries (e.g., \"summaries between times X and Y, linked to project Z\") are trivial and performant on indexes.\nBasic vector search is fast enough for tens of thousands of rows, especially with Postgres extensions or Python glue.\nIntegrates metadata and semantic search in one query, no extra plumbing.\nSchema evolution and debugging are dramatically simpler than graph or vector DBs.\nA mature ops team can evolve SQL schemas, index smartly, and drop in vector tooling for flexible, high-precision recall. Unless you demand million-record fuzzy recall, SQL scales further than most assume.\nHead-to-Head: Actual Numbers and Pain Points\nBenchmarks from a Macbook Pro M2, 16GB RAM, Python 3.11. Vector: FAISS. Graph: Neo4j Desktop. SQL: SQLite in-memory.\nMemory Type\nInsert Latency (10k rows)\nTop-5 Retrieval\nMulti-Hop Recall\nSchema Flexibility\nDebuggability\nScaling Ceiling\nFAISS vstore\n~450 ms\n~7 ms\nManual, poor\nLow\nFair\nRAM-bound\nNeo4j graph\n~5,000 ms\n~120 ms (3-hop)\nNative, scalable\nMedium\nPoor (Cypher)\nNonlinear cost\nSQLite (SQL)\n~700 ms\n~25 ms\nManual, but simple\nHigh\nExcellent\nDisk/Index-bound\nEarly failure modes:\nVector: Chokes on multi-hop/metadata queries, or >1M vectors without sharding.\nGraph: Bogs down on deep traversals, cyclic schemas, or batch inserts.\nSQL: Bottlenecks without vector indexing at scale, but otherwise robust.\nRecall quality:\nVector: Excels at broad similarity, fails for nuanced, cross-linked context.\nGraph: Matches explicit relationships, weak for fuzzy similarity.\nSQL: Satisfies 80% of agent memory constraints—hybrid queries across structured and unstructured data.\nArchitecture Choice: What Survives and Where\nTradeoff diagram (in words):\nX Axis:\nRecall complexity (fuzzy on left, multi-hop/constraint on right)\nY Axis:\nOperational readiness (toy demos at bottom, production ops at top)\nLower-left:\nFAISS/Chroma—dominant for fuzzy, fast at toy and mid-scale, unusable for complex recall.\nCentral band:\nSQL with vector support—handles structured, hybrid recall; easy schema evolution.\nUpper-right:\nGraphs—needed only for deeply interlinked or provenance-anchored memory; expensive to scale and debug.\nSkip vector DB when:\nOrdered, tagged, or event-chained recall trumps raw similarity.\nYou need queries like \"all action items from meetings with X between Y and Z.\"\nHybrid (SQL+vector or Graph+vector) is required when:\nBoth structure and semantic similarity drive retrieval requirements.\nUse SQL for multi-constraint, fall back to vector for fuzzy matches.\nBottom line:\nVectors collapse under production agent memory needs. Graph is specialized, costly for most workloads. SQL outlasts both for operational, flexible, and multi-faceted recall. Choose memory architecture for what the agent actually does—not for \"demo simplicity.\"",
  "metadata": {
    "title": "Vector, Graph, or SQL? What Actually Works for Production AI Agent Memory - DEV Community",
    "description": "Vector, Graph, or SQL? What Actually Works for Production AI Agent Memory   Scalable agent... Tagged with ai, agenticai, machinelearning, llm.",
    "keywords": "ai, agenticai, machinelearning, llm, software, coding, development, engineering, inclusive, community",
    "author": null,
    "og:type": "article",
    "og:url": "https://dev.to/priyeshdave6/vector-graph-or-sql-what-actually-works-for-production-ai-agent-memory-5h6p",
    "og:title": "Vector, Graph, or SQL? What Actually Works for Production AI Agent Memory",
    "og:description": "Vector, Graph, or SQL? What Actually Works for Production AI Agent Memory   Scalable agent...",
    "og:site_name": "DEV Community",
    "og:image": "https://media2.dev.to/dynamic/image/width=1200,height=627,fit=cover,gravity=auto,format=auto/https%3A%2F%2Fdev-to-uploads.s3.us-east-2.amazonaws.com%2Fuploads%2Farticles%2Fzouumb8nk71otkleh5ck.png",
    "twitter:site": "@thepracticaldev",
    "twitter:creator": "@",
    "twitter:title": "Vector, Graph, or SQL? What Actually Works for Production AI Agent Memory",
    "twitter:description": "Vector, Graph, or SQL? What Actually Works for Production AI Agent Memory   Scalable agent...",
    "twitter:card": "summary_large_image",
    "twitter:widgets:new-embed-design": "on",
    "twitter:image:src": "https://media2.dev.to/dynamic/image/width=1200,height=627,fit=cover,gravity=auto,format=auto/https%3A%2F%2Fdev-to-uploads.s3.us-east-2.amazonaws.com%2Fuploads%2Farticles%2Fzouumb8nk71otkleh5ck.png"
  },
  "paywall": {
    "listed_paid": false,
    "detected": false,
    "marker": "",
    "public_only": false,
    "policy": "付费/会员内容只保留页面公开可见部分，不绕过付费墙"
  },
  "crawl": {
    "success": true,
    "status_code": 200,
    "error": ""
  },
  "code_blocks": [
    {
      "file": "attachments/a5fa6c589e47/code/body-000.txt",
      "chars": 446,
      "language": "text"
    },
    {
      "file": "attachments/a5fa6c589e47/code/body-001.txt",
      "chars": 1224,
      "language": "text"
    },
    {
      "file": "attachments/a5fa6c589e47/code/body-002.txt",
      "chars": 1138,
      "language": "text"
    }
  ],
  "images": [],
  "audio": [],
  "videos": [],
  "links": [],
  "repair_version": 2,
  "repaired_at": "2026-10-14T10:48:12Z",
  "source_url": "https://dev.to/priyeshdave6/vector-graph-or-sql-what-actually-works-for-production-ai-agent-memory-5h6p",
  "papers": [],
  "actual_video_files": [],
  "body_chars": 9688,
  "expected_body_images": 0,
  "discovery_status": "ok",
  "delivery_status": "ok",
  "missing_reason": "",
  "raw_html": "attachments/a5fa6c589e47/pages/source.html",
  "local_html": "attachments/a5fa6c589e47/pages/article.html",
  "body_base_path": "attachments/a5fa6c589e47/pages/",
  "body_markdown_path": "attachments/a5fa6c589e47/pages/article.md"
}