Build1 distinct publisher2 min readUpdated
A dev.to writeup drops vector stores for a SQLite table with tag and timestamp columns. Its own numbers put the practical ceiling at a million rows, not a hundred million.
The Engineer · Build desk
Compiled by The EngineerSomething wrong?How this is made
A hundred thousand rows of 384-dimension float32 embeddings, the size the post's own example generates [8], is 153.6 MB of vectors that a brute-force scan has to read on every query [13]. The quoted 5 to 20 milliseconds per query [7] therefore implies read bandwidth somewhere between 7.7 and 31 GB/s [14]. The slow end of that is an unremarkable single-threaded numpy pass over an in-memory buffer. The fast end is not, unless the table sits well below the stated ceiling or the scan is spread across cores. The post ships working code but no hardware, dataset or timing method behind the number [18], so treat it as an order of magnitude rather than a result: a few thousand memories are free, a hundred thousand cost real milliseconds. Even the slow end stays inside a network round trip, which is the author's basis for saying networked vector stores rarely win on individual queries [c7b].
Latency is not the strongest part of the case. The WHERE clause is. A predicate on tag and timestamp returns every row that satisfies both and nothing else, one row out of three in the worked example [4], with no approximation step and no hybrid postfilter to reason about [16]. The equivalent against a vector store is top-k with filtering bolted on before or after the ANN lookup, or a query-and-filter loop you maintain yourself [6], and what comes back depends on k and on how the index handles the predicate. According to the author, that recall also moves when embeddings drift or the embedding model is upgraded [5]. A timestamp comparison does not move. When an agent misbehaves, the gap between those two properties is the gap between reconstructing the context it had and estimating it.
What the SQL route actually charges you is a schema decision taken at insert time. The author's model of agent memory has a recent cache, a working or episodic slice, and a long-term archive rather than one flat event log [17], which in the proposed table becomes a `level` column on `memory_event` alongside `agent_id`, `tag` and `embedding` [11]. Something has to classify each memory as it is written, and the compound index on `(agent_id, level, timestamp)` [11] only earns its keep if queries name all three. Determinism has a price and that is where it is paid: the shape of recall is fixed in advance, in code you can read, instead of by tuning k until the answers look reasonable. The author is explicit that this trade only applies to layered episodic memory, and that pure semantic retrieval is what vector stores are for [10].
Follow any of these and your For You feed starts watching them — no settings page required.
Ranked by verification strength, evidence, and original report placement.
The post claims classic SQL wins where you need precise, scoped recall, such as what facts are in recent working memory for topic X since 10 minutes ago, in a single query.
The worked example creates a SQLite table memory(id, text, ts REAL, tag, embedding BLOB), inserts three rows, and a SELECT with WHERE tag = 'alpha' AND ts > now - 120 returns only 'Fix bug in alpha repo'.
The post's example embedding function returns 384-dimension float32 vectors, stored as BLOBs via tobytes().
The post says vector DBs are for pure semantic retrieval, not layered or episodic memory, and that SQL handles structured, temporal and filtered recall directly.
The proposed schema is memory_event with id, timestamp, agent_id, level (cache/working/long_term), text, tag and embedding, plus a memory_index table for aggregated contexts, multi-agent links and session chains, and compound indexes including (agent_id, level, timestamp).
The post describes the SQL approach as deterministic, explainable and instantly extensible, with no ANN approximation and no hybrid postfilter.
Evidence-backed comparisons of source perspectives and observed adoption signals. Read the methodology
Which Builder, Operator, and Investor concerns the observed source mix emphasized—not a truth score.
Evidence, demonstrated adoption, hype gap, incentives, and confidence are assessed independently, each on its own current evidence. How these are measured.
Runnable snippets, no measurements
The cluster is one opinion post. Its schema, filter query and 384-dimension embedding handling are fully reproduced and verifiable in-source, which is real but narrow evidence. Every performance and comparative claim - the 5-20 ms figure, the networked-vector-DB comparison, the ops-overhead and ANN-instability assertions, the 4k-token threshold - arrives without a timing harness, hardware description, dataset or corroborating publisher.
No adoption signal supplied
The cluster contains no release, deployment, usage disclosure, benchmark run or named user of the pattern. The post describes an approach the author says they adopted, with no scale figures, production context or third-party uptake, so adoption cannot be scored without inventing facts.
Claims outrun the demonstrated work
The framing ('SQL is the real fast path', vector DBs unnecessary below hundred-million-vector scale) is considerably broader than what the article demonstrates: a three-row SQLite filter and an unfiltered Chroma top-1 query. The one hard number is unbenchmarked, and simple arithmetic on the post's own parameters puts the 5 ms end of its range near 31 GB/s of read bandwidth. The post's own concession that SQL breaks at 1M rows undercuts its 100M-vector headline, so the gap is overstatement rather than fabrication - it does concede real limits, graph workloads and the faiss migration path.
No disclosed interests
The supplied material gives no vendor affiliation, employer, product, sponsorship or commercial relationship for the author, and names no paying party on either side of the SQL-versus-vector-DB argument. Any incentive score would be inference rather than observation.
Single unverified practitioner account
Confidence is limited by one publisher, no replication, no benchmark methodology and an internal inconsistency in the article's own scale thresholds. What can be trusted is narrow and structural: the code, the schema, the tiering design and the fact that the post concedes SQL's limits. The performance and vendor-comparison claims should be treated as untested hypotheses pending a local benchmark.
build
DuckDB's vss extension removes a database from your RAG stack, then names the price1 distinct publisher
build
Six pragmas and a context manager: the vector store that fits in 2GB of RAM1 distinct publisher
build
Fabricated SQLite CVEs cleared NVD, CISA ADP and Red Hat before anyone ran the code1 distinct publisher
build
796 pages of semantic search with no vector database, and what it cost to skip one1 distinct publisher
Distinct publishers with included, body-backed reporting in this cluster.
dev.to
1 article · August 23, 2026