Por qué SQL/NoSQL no sirven para semantic search

Descripción de la cápsula

SQL y NoSQL son excelentes para lo que fueron diseñados: SQL para queries estructuradas (WHERE age > 30), NoSQL para documentos escalables. Pero ninguno fue diseñado para búsqueda de similitud geométrica en espacios de alta dimensión, que es lo que necesita RAG.

Esta cápsula explica por qué usar SQL/NoSQL para semantic search es como usar un martillo para atornillar: técnicamente posible (con extensiones), pero subóptimo. Entenderás las limitaciones arquitectónicas de SQL/NoSQL y por qué vector databases dedicadas existen.

---

SQL: Diseñado para tablas, no vectores

El problema fundamental

SQL fue diseñado para:

SELECT name, age FROM users WHERE age > 30 AND city = 'NYC';

Lo que necesitas para RAG:

SELECT doc_id FROM embeddings 
WHERE cosine_similarity(vector, query_vector) > 0.8 
ORDER BY similarity DESC LIMIT 5;

Problema: SQL no tiene operador cosine_similarity nativo. No entiende "geometría de vectores". Solo entiende comparaciones (>, <, =, LIKE).

---

Postgres con pgvector: Extensión útil pero limitada

¿Qué es pgvector?

pgvector es una extensión de Postgres que agrega soporte para vectores:

CREATE EXTENSION vector;

CREATE TABLE embeddings (
  id SERIAL PRIMARY KEY,
  doc_text TEXT,
  embedding vector(1536)  -- Tipo 'vector' agregado por pgvector
);

-- Búsqueda por similitud
SELECT doc_text 
FROM embeddings 
ORDER BY embedding <-> '[0.1, 0.2, ...]'::vector 
LIMIT 5;

Operadores soportados:

• <-> : L2 distance (euclidean)
• <#> : Negative inner product
• <=> : Cosine distance

---

Limitaciones de pgvector

1. Sin HNSW hasta versión reciente (2023)

pgvector pre-0.5.0 (mayo 2023) solo tenía IVFFlat (Inverted File Index):

• Latency: ~500ms para 1M vectores
• vs ChromaDB con HNSW: ~15ms
• 30x más lento

2. HNSW disponible desde v0.5.0 (mayo 2023)

Ahora pgvector soporta HNSW:

CREATE INDEX ON embeddings USING hnsw (embedding vector_cosine_ops);

Pero:

• Implementación HNSW de pgvector es más lenta que vector DBs dedicadas
• Postgres no está optimizado para operaciones vectoriales (overhead SQL)
• Múltiples queries concurrentes degradan performance

Benchmark (1M vectores, 1536D):

pgvector + HNSW:    50-80ms   (mejor caso)
ChromaDB + HNSW:    10-20ms
Pinecone:           5-15ms

Conclusión: pgvector es mejor que brute force, pero peor que vector DBs dedicadas.

---

Cuándo pgvector ES suficiente

Casos válidos:

• Ya usas Postgres para todo (no quieres agregar otra DB)
• <100K vectores (pgvector es suficiente)
• No necesitas <50ms latency (50-80ms es aceptable)
• Equipo tiene más experiencia con SQL que con nuevas DBs

Ejemplo: Startup con 20K docs, Postgres existente, equipo junior SQL-first.

• pgvector: 20-30ms retrieval ✅ Aceptable
• ChromaDB: 5-10ms ✅ Mejor pero requiere aprender nueva DB
• Trade-off válido: Simplicidad (pgvector) vs performance (ChromaDB)

---

NoSQL: Diseñado para documentos, no geometría

MongoDB con vector search

MongoDB Atlas (cloud) tiene Vector Search desde 2023:

db.collection.createIndex({
  embedding: "vectorSearch"
}, {
  vectorOptions: {
    dimensions: 1536,
    similarity: "cosine"
  }
});

db.collection.aggregate([
  {
    $vectorSearch: {
      queryVector: [0.1, 0.2, ...],
      path: "embedding",
      numCandidates: 100,
      limit: 5
    }
  }
]);

---

Limitaciones de MongoDB vector search

1. Solo en Atlas (cloud)

• No disponible en MongoDB self-hosted (Community Edition)
• Requiere Atlas (managed cloud) → Costo adicional

2. Implementación HNSW reciente (2023)

• Menos madura que ChromaDB/Pinecone (2020-2021)
• Menos benchmarks públicos

3. Overhead de MongoDB

• MongoDB optimizado para documents, no vectores
• Overhead de JSON serialization/deserialization
• Performance menor vs vector DBs dedicadas

Benchmark (100K vectores, 1536D - MongoDB Atlas):

MongoDB Vector Search:  80-120ms
ChromaDB:               10-20ms

Conclusión: MongoDB Vector Search es conveniente si ya usas MongoDB, pero no es óptimo para RAG puro.

---

Elasticsearch con dense vectors

Elasticsearch soporta dense vectors:

PUT /documents
{
  "mappings": {
    "properties": {
      "embedding": {
        "type": "dense_vector",
        "dims": 1536,
        "index": true,
        "similarity": "cosine"
      }
    }
  }
}

POST /documents/_search
{
  "knn": {
    "field": "embedding",
    "query_vector": [0.1, 0.2, ...],
    "k": 5,
    "num_candidates": 100
  }
}

---

Limitaciones de Elasticsearch

1. Híbrido, no dedicado

• Elasticsearch es search engine (keyword search primero, vectores segundo)
• Optimizado para texto, no geometría pura

2. HNSW desde v8.0 (2022)

• Implementación menos optimizada que vector DBs dedicadas
• Setup complejo (cluster, shards, replicas)

3. Overhead de Elasticsearch

• Índice invertido + vector index = mayor memoria
• Lucene overhead (designed for text, adapted for vectors)

Benchmark (500K vectores, 1536D):

Elasticsearch + HNSW:  100-200ms
ChromaDB:              15-30ms

Conclusión: Elasticsearch es excelente para hybrid search (keyword + semantic), pero no es óptimo si solo necesitas semantic search.

---

Comparación: SQL vs NoSQL vs Vector DB

Tabla comparativa (1M vectores, 1536D)

Característica	Postgres + pgvector	MongoDB Atlas	Elasticsearch	ChromaDB	Pinecone
Latency	50-80ms	80-120ms	100-200ms	10-20ms	5-15ms
Setup	Extension install	Cloud only	Cluster setup	pip install	API key
HNSW	Desde v0.5 (2023)	Sí (2023)	Desde v8 (2022)	Nativo	Nativo
Self-hosted	✅ Sí	❌ No	✅ Sí	✅ Sí	❌ No
Costo (self)	$0 (Postgres)	N/A	$0 (OSS)	$0 (OSS)	N/A
Costo (cloud)	$50-200/mes	$60-300/mes	$100-500/mes	$0 (self)	$70+/mes
Optimización	SQL-first	Docs-first	Text-first	Vector-first	Vector-first

---

¿Cuándo usar cada uno?

Usa Postgres + pgvector SI:

• ✅ Ya usas Postgres (no quieres otra DB)
• ✅ <100K vectores (pgvector suficiente)
• ✅ Equipo SQL-first (no quieren aprender nueva API)
• ✅ 50-80ms latency es aceptable

Usa MongoDB Vector Search SI:

• ✅ Ya usas MongoDB Atlas
• ✅ Necesitas documents + vectors en mismo lugar
• ✅ Costo Atlas ya justificado

Usa Elasticsearch SI:

• ✅ Necesitas hybrid search (keyword + semantic)
• ✅ Ya usas Elasticsearch para logs/text search
• ✅ 100-200ms latency es aceptable

Usa Vector DB dedicada (ChromaDB/Pinecone) SI:

• ✅ >100K vectores (escala)
• ✅ <50ms latency crítico (performance)
• ✅ Vector search es tu use case principal (no híbrido)
• ✅ Quieres mejor-in-class para vectores

---

Por qué vector databases dedicadas existen

La arquitectura importa

SQL/NoSQL adaptado para vectores:

[SQL Engine] → [Extension: pgvector] → [HNSW Index] → [Vectores]
     ↑
   Overhead (tablas, transacciones, ACID)

Vector DB dedicada:

[Vector Engine] → [HNSW Index] → [Vectores]
     ↑
   Zero overhead (diseñado solo para vectores)

Resultado:

• Vector DB: 3-5x más rápido que SQL/NoSQL con extensiones
• Vector DB: Menor memoria (no overhead de SQL)
• Vector DB: API más simple (operations vectoriales nativas)

---

Resumen

Lo que aprendiste:

1. ✅ SQL no entiende vectores: Diseñado para tablas, no geometría de alta dimensión
2. ✅ pgvector es útil pero limitado: 50-80ms vs 10-20ms de ChromaDB (3-4x más lento)
3. ✅ NoSQL (MongoDB, Elastic) son híbridos: Buenos para hybrid search, subóptimos para vector-only
4. ✅ Vector DBs dedicadas son 3-5x más rápidas: Arquitectura optimizada para vectores únicamente
5. ✅ Trade-off válido: Simplicidad (SQL/NoSQL existente) vs performance (vector DB dedicada)

Por qué importa:

• Si tu RAG tiene >100K docs y necesitas <50ms, SQL/NoSQL no son suficientes
• pgvector es compromiso razonable para proyectos pequeños (<100K vectors)
• Vector DBs dedicadas son óptimo para RAG production-ready (>100K docs, <50ms)

Siguiente cápsula: Ahora que entiendes por qué SQL/NoSQL no son óptimos, verás por qué numpy/pandas tampoco escalan a producción.

---

Recursos adicionales

1. pgvector Documentation - Extensión oficial Postgres
2. MongoDB Vector Search - Docs oficiales
3. Elasticsearch Dense Vectors - Docs oficiales
4. Why Vector Databases - Justificación arquitectónica
5. Postgres vs Pinecone Benchmark - Comparación detallada
6. SQL for Vector Search - Limitaciones explicadas

---

Tiempo de lectura: 8-10 minutos
Siguiente: 04-por-que-numpy-pandas-no-escalan.md