标签：#vectorsearch

This week shipped one of the more consequential infrastructure changes in a while: DynamoDB absorbed vector search, collapsing a common two-database architecture into one. Meanwhile, a CMU study put hard numbers on something senior engineers have suspected about AI coding tools, and a 3B parameter model posted reasoning scores that have no business coming from a model that size. DynamoDB adds native vector search without a separate database AWS added a SearchVectors API to DynamoDB, letting you store embeddings alongside your application data and query them directly—no Pinecone, no Weaviate, no synchronization layer between your transactional store and your vector index. This matters because the dual-database pattern is genuinely painful at scale. You write to DynamoDB, you write to your vector DB, you manage consistency between them, you pay for two systems, and you debug failures in both. For RAG pipelines and semantic search on data that already lives in DynamoDB, that overhead exists purely because vector search wasn't available where your data was. Now it is. Setup requires picking an embedding model (Bedrock, Cohere, or OpenAI), configuring a vector index with dimensions and distance function, and rewriting retrieval queries to SearchVectors . Vector operations are billed separately per GB across writes, reads, and storage—so run the math before assuming this is cheaper than your current setup. Verdict: Ship if you're already on DynamoDB and maintaining a separate vector DB. The architectural simplification is real. Start with a proof-of-concept on a non-critical workload to validate cost and latency before migrating production RAG infrastructure. AI coding speed spike vanishes in three months Carnegie Mellon tracked 806 repositories after Cursor adoption and found that the velocity boost disappears by month three. What doesn't disappear: a 30% increase in warnings and 41% higher code complexity that persists indefinitely and cuts future velocity by 50–64%. Th

I was on a call last month with a startup CTO who had just gotten their AWS bill. They had built a beautiful RAG application: semantic search, conversational AI, the works. Their vector index was humming along with about 50 million embeddings. Then they hit product-market fit. Within six weeks, they scaled to 500 million vectors. Their monthly infrastructure costs went from $2,000 to $20,000. The real kicker? When we looked at the access patterns, over 80% of those vectors were queried less than once a week. They were paying hot-storage prices for data that was, by any honest measure, cold. The standard advice here is "just use a cheaper vector database." The more interesting question is: why are you storing all your vectors at the same temperature in the first place? The Cost-Recall-Latency Triangle Vector search forces a three-way tradeoff. You can optimize for cost, recall, and latency, but you only get to pick two. Want high recall and low latency? That costs money (in-memory HNSW graphs with full-precision vectors eating RAM). Want high recall at low cost? Latency goes up. Want cheap and fast? Recall suffers. Most teams pick a single point on this triangle and apply it uniformly to every vector in their index. That decision made sense when vector databases offered a single storage tier. It makes the same amount of sense as storing your entire filesystem on NVMe SSDs because some files need fast access. The conventional wisdom says you pick your point on the triangle and live with it. But the conventional wisdom was written before vector storage got interesting. The better approach: tier your vectors the same way you already tier your storage. Different access patterns deserve different economics. The same embedding that costs $0.12/month in RAM might cost $0.004/month on disk and $0.0002/month in object storage. When you have 500 million of them, those decimals matter. The Hot Tier: In-Memory HNSW and Exact k-NN For vectors that get hit constantly (your user-fa

Every system that does "semantic" anything — RAG pipelines, recommendation engines, image search, dedup — boils down to one operation: given this vector, find the closest ones out of millions. The vectors are embeddings, a few hundred to a couple thousand numbers each, and "closest" means closest in meaning. You'd assume the database either scans all of them (slow but correct) or uses some clever tree to jump straight to the answer. It does neither. Instead it deliberately settles for the approximately closest vectors — and that compromise is the entire reason vector search is fast enough to exist. Two algorithms do almost all the heavy lifting in practice, in pgvector, Qdrant, FAISS, and the rest: IVF and HNSW . Here's what they're actually doing under the hood, and how to choose between them. Why "exact" is off the table The natural objection is: why approximate? Just find the real nearest neighbor. In two or three dimensions you could — a k-d tree or similar structure prunes away big regions of space and finds the true closest point quickly. The trouble is that embeddings live in hundreds of dimensions, and high-dimensional space is deeply weird. It's called the curse of dimensionality . As dimensions grow, the distance to your nearest point and the distance to your farthest point drift toward being almost the same. Formally, the contrast (d_max − d_min) / d_min shrinks toward zero. When everything is roughly equidistant from everything else, a tree can't confidently say "skip this whole branch, it's too far" — the bounding regions all overlap, every branch looks plausible, and the search degrades into checking nearly everything. Exact indexes quietly collapse back into brute force. So we change the question. Instead of "prove you found the nearest," we ask "quickly find something very probably among the nearest." That's approximate nearest neighbor (ANN) search, and it swaps a guarantee for speed. The quality knob becomes recall : of the true top-k neighbors, wh

EDRSR — the Unified State Register of Court Decisions — is effectively all of Ukraine's judicial practice in open access. Today Qdrant holds **44M+ vectors : criminal (19M), civil (14.3M), commercial (5.1M), misdemeanors (5.6M). Vectorization of civil cases (CPC, justice_kind=1) — the largest cohort at 33.7M documents — runs on a dedicated EC2 instance (r6a.xlarge, 32 GB RAM, 2 TB gp3). Here's what's under the hood: models, pipeline, cost, rakes, and current status. Why Vectorize Courts When a lawyer searches "is there case law on recovering bank prepayment fees" — they don't want to open 40 decisions and read them through. They want the system to surface the top 5 most relevant ones, pull out key paragraphs, and show how courts reasoned. Full-text search (FTS) over keywords doesn't give that — it returns every document containing the word "fee", and there are thousands. For this semantic task you need vector representations of text. The model turns a paragraph from a decision into a point in a 1024-dimensional space; semantically similar paragraphs sit near each other. A kNN search in Qdrant returns the top K nearest, and an LLM composes the answer from exactly those relevant fragments. The only problem: the register is big. Very big. Scale Our prod database holds full texts of decisions starting from 2006. Breakdown by procedural type: Civil (CPC) — 33.7M documents. The largest category. Consumer, housing, labor, family. Criminal (CrPC) — 12M+ Administrative (CAS) — 14M+ Commercial (CC) — 6M+ Misdemeanors (CUaP) — 6M+ The Qdrant collection edrsr_decisions on a dedicated EC2 currently holds 44M+ vectors (122 segments, on_disk=true): | Proceeding type | justice_kind | Vectors | |—|—|—| | Criminal (CrPC) | 2 | 19,036,347 | | Civil (CPC) | 1 | 14,328,427 | | Misdemeanors (CUaP) | 5 | 5,579,432 | | Commercial (CC) | 3 | 5,098,662 | | Total | | 44,042,868 | Civil cases processed: 14.3M out of 33.7M — that's 42%. After CPC completes there will be roughly 63M+ vectors in