Nuestro interés es casi nulo y aun así merece declararse: somos Geonode y vendemos proxies, que no tienen nada que ver con bases de datos vectoriales. La única adyacencia es que un sistema de recuperación necesita algo sobre lo que recuperar, y si ese contenido viene de la web pública, alguien tiene que recogerlo — ese es nuestro extremo del pipeline y está del todo separado de la base. Nada de este artículo exige comprarnos nada, y la sección que argumenta contra una base vectorial gestionada está incluida porque a menudo es la respuesta correcta.
Qué hace una base vectorial
Las bases ordinarias coinciden de forma exacta. Una base vectorial coincide por similitud.
El mecanismo: un modelo de embedding convierte texto, imágenes u otro contenido en una lista de números — un vector — colocado de modo que lo similar quede cerca. Encontrar resultados relevantes se vuelve encontrar puntos cercanos, un problema de geometría y no de coincidencia de cadenas.
Pinecone se describe como "the vector database for AI agents and applications, built for semantic search, knowledge retrieval, and long-term memory at scale", con la capacidad planteada como buscar "through billions of items for similar matches to any object, in milliseconds".
Que esto se convirtiera en infraestructura y no en una biblioteca se debe a la escala. Comparar una consulta con un millón de vectores por fuerza bruta es sencillo y lento; hacerlo en milisegundos exige indexes de vecino más cercano aproximado, y operarlos con fiabilidad a escala es un problema de operaciones. Eso es lo que vende un servicio gestionado.
El caso de uso dominante es la generación aumentada por recuperación: dada la pregunta de un usuario, hallar los pasajes más relevantes de tus propios documentos y dárselos a un modelo de lenguaje como contexto. La base aporta el paso de "encontrar los pasajes relevantes".
Indexes, documentos y records
El modelo de datos de Pinecone ha cambiado de forma y conviene entenderlo tal como está ahora.
Un index es donde viven los datos. La documentación explica que "a serverless index holds your data as documents or records, depending on how the index was created: an index created with a document schema holds documents, while an index created with a dense or sparse vector type holds records".
Un schema de documento permite que un index haga varios trabajos. Según la documentación, "a single index with a document schema can mix multiple ranking field types: a dense_vector field for semantic search, a sparse_vector field for sparse-vector retrieval, and one or more string fields with full_text_search enabled for full-text search with BM25 and Lucene queries."
Los metadatos no necesitan declaración. "Any other fields you upsert are stored as metadata, automatically indexed for filtering — no schema declaration required."
La guía de diseño se enuncia con claridad: "One index per use case is the typical pattern. Because a document can combine vectors, text, and metadata in the same record, a single index often covers what previously required two — pick the ranking signal per query with score_by."
Ese último punto es el significativo. La búsqueda full-text está disponible junto a la vectorial en el mismo index — "BM25 token matching with Lucene query syntax over text fields in your schema", y Pinecone se ocupa de "tokenization, IDF, and length normalization at index time and BM25 scoring at query time". Sin motor de búsqueda aparte, y sin modelo para la mitad de palabras clave.
La consecuencia práctica es que la búsqueda híbrida — combinar similitud semántica con coincidencia exacta de palabras clave — es una elección en tiempo de consulta, no de arquitectura. Importa porque la búsqueda puramente vectorial es notoriamente débil con identificadores exactos, códigos de producto y nombres propios raros, y BM25 es excelente exactamente en eso.
Namespaces
La función que más afecta a cómo diseñas una aplicación multi-tenant.
La documentación: "Within an index, records are partitioned into namespaces, and all upserts, queries, and other data read and write operations always target one namespace."
Se nombran dos beneficios. Multitenancy — "when you need to isolate data between customers, you can use one namespace per customer and target each customer's writes and queries to their dedicated namespace." Y consultas más rápidas — "when you divide records into namespaces in a logical way, you speed up queries by ensuring only relevant records are scanned."
Tres notas operativas.
Se crean de forma implícita. "Namespaces are created automatically during upsert. If a namespace doesn't exist, it is created implicitly." Cómodo, y significa que un error tipográfico en el nombre de un namespace produce una búsqueda silenciosamente vacía en vez de un error.
El límite depende del plan. "Namespaces per serverless index vary by plan. On the Standard and Enterprise plans, Pinecone can accommodate million-scale namespaces and beyond for specific use cases. If your application requires more than 100,000 namespaces, contact Support."
El aislamiento es el punto. Para cualquier cosa que guarde datos de varios clientes, un namespace por cliente es el patrón, y convierte la filtración entre tenants en acertar un parámetro, no un filtro.
Embeddings: los tuyos o los suyos
Dos enfoques, y la elección tiene consecuencias reales.
Embedding integrado. La documentación lo describe en cuatro pasos: "Create an index that is integrated with one of Pinecone's hosted embedding models. Upsert your source text. Pinecone uses the integrated model to convert the text to vectors automatically. Search with a query text. Again, Pinecone uses the integrated model to convert the text to a vector automatically."
Más simple: envías texto y recibes resultados, sin un pipeline de embedding propio. Una restricción documentada: "Indexes with integrated embedding do not support updating or importing with text."
Trae tus propios vectores. Ejecutas el modelo de embedding, creas un index que coincida con sus características y haces upsert de vectores directamente, usando "the same external embedding model to convert a query to a vector".
Más trabajo y más control. Te permite usar un modelo que Pinecone no aloje, ejecutar el embedding en local por privacidad o coste y — de forma crucial — cambiar de modelo a tu ritmo.
La consideración que lo decide para mucha gente: cambiar de modelo de embedding significa volver a embeder todo. Los vectores de modelos distintos no son comparables, así que el cambio es un reindex completo. El embedding integrado facilita la construcción inicial y ata la decisión al catálogo de modelos del proveedor; traer los tuyos endurece la construcción y deja la elección en tus manos. Ninguno está mal, y conviene decidirlo a propósito y no por el primer tutorial que seguiste.
Cargar datos a escala
Una nota de coste fácil de pasar por alto y cara de descubrir.
La documentación es concreta: "To control costs when ingesting large datasets (10,000,000+ records), use import instead of upsert."
Hay dos rutas de ingesta. Upsert envía records por la API. Import lee archivos Parquet del object storage, y la documentación lo llama "the most efficient and cost-effective way to load large numbers of records into an index".
Dado que las escrituras se facturan por millón de write units, la diferencia entre estas dos vías en una carga inicial grande es un número real, no un error de redondeo. Si estás construyendo un index sobre millones de records, planifica la vía de import desde el principio: adaptar después de una primera carga cara es una lección que nadie necesita pagar dos veces.
Empezar en la práctica
La forma de una primera implementación, y las decisiones embebidas en ella.
Crea un index y haz upsert. Con embedding integrado el flujo es corto: nunca tocas un vector:
from pinecone import Pinecone
pc = Pinecone(api_key=API_KEY)
index = pc.Index(host=INDEX_HOST)
index.upsert_records(
namespace="customer-42",
records=[
{"_id": "doc-1", "chunk_text": "Refunds are processed within 14 days.",
"source": "policy.pdf", "page": 3},
{"_id": "doc-2", "chunk_text": "Shipping to the EU takes 3-5 working days.",
"source": "shipping.pdf", "page": 1},
],
)
Observa que source y page nunca se declararon. Cualquier cosa más allá de los campos de ranking se guarda como metadato y se indexa para filtrar automáticamente, así que puedes añadir campos después sin una migración.
Consulta con un filtro:
results = index.search(
namespace="customer-42",
query={"inputs": {"text": "how long do refunds take?"}, "top_k": 5,
"filter": {"source": {"$eq": "policy.pdf"}}},
)
Tres decisiones de ese fragmento merecen tomarse a propósito.
Tamaño del chunk. El texto que envías en el upsert es la unidad que vuelve, así que el chunking determina lo que ve tu modelo. Chunks demasiado pequeños pierden el contexto que los hace significativos; demasiado grandes y recuperas texto irrelevante junto a la frase relevante. No hay respuesta universal: unos cientos de palabras con algo de solapamiento es un punto de partida razonable, y medir gana a adivinar.
Los metadatos son tu superficie de filtro. Guarda cualquier cosa por la que más tarde quieras acotar: documento de origen, fecha, sección, idioma, nivel de acceso. Añadirlo en el upsert no cuesta nada; añadirlo después implica volver a hacer upsert.
Namespace por tenant, siempre, desde el principio. Encajar aislamiento después en un index de un solo namespace significa reenviar todo con el destino correcto. Empezar con namespaces cuesta un parámetro y elimina toda una categoría de incidente futuro.
Y conserva el texto fuente. Guarda los documentos originales en un sitio que controles, junto al código de chunking. Si cambias el modelo de embedding, el tamaño del chunk o la estrategia de chunking — y lo harás — reconstruir el index es una reejecución, no un ejercicio de arqueología.
Precios, verificados
De la propia página de precios de Pinecone, comprobada en septiembre de 2026. Verifica antes de presupuestar.
| Plan | Cost | Storage | Write units | Read units | Egress |
|---|---|---|---|---|---|
| Starter | Free | Up to 2 GB | Up to 2M/month | Up to 1M/month | Up to 1 GB/month |
| Builder | $20/month flat | Up to 10 GB | Up to 5M/month | Up to 2M/month | Up to 10 GB/month |
| Standard | $50/month min. usage | Unlimited, $0.33/GB/mo | $4–$4.50 per million | $16–$18 per million | $0.10/GB, 100 GB included |
| Enterprise | $500/month min. usage | Same rates as Standard | Same | Same | Same |
Cuatro observaciones que importan para planificar.
El plan gratuito es realmente usable para evaluar. Dos gigabytes de almacenamiento y un millón de read units al mes bastan para construir un prototipo real sobre un conjunto sustancial de documentos.
Builder es tarifa plana, no un mínimo. A 20 $/mes con techos fijos, es predecible de un modo que los planes por uso no lo son: útil para una aplicación de producción pequeña en la que prefieres una factura que puedas prever.
Standard y Enterprise son mínimos con excedente. Los 50 $ y 500 $ son suelos, no techos. Tu coste real es por uso por encima de ellos.
Las lecturas cuestan unas cuatro veces las escrituras por millón de units. A 16–18 $ por millón de read units frente a 4–4,50 $ en escrituras, una aplicación pesada en lectura — que lo son la mayoría de sistemas de recuperación — verá las consultas dominar la factura. Cachear consultas frecuentes es, por tanto, una palanca directa de coste, no solo de latencia.
Enterprise añade un SLA de 99,95 % de uptime, despliegue bring-your-own-cloud, private endpoints y registros de auditoría: el conjunto habitual de cosas que importan a un proceso de compras y nada a un prototipo.
Cuándo no necesitas una base vectorial gestionada
La sección que un proveedor no escribiría, incluida porque a menudo es la respuesta.
Cuando tu corpus es pequeño. Por debajo de unos cien mil vectores, la búsqueda de similitud por fuerza bruta en memoria es suficientemente rápida en hardware ordinario. Un array de NumPy y un producto escalar responden en milisegundos, no cuestan nada y quitan una dependencia externa de tu arquitectura. El umbral en el que la indexación aproximada se vuelve necesaria es más alto de lo que la mayoría asume.
Cuando ya ejecutas Postgres. La extensión pgvector añade búsqueda por similitud vectorial a una base que ya operas y de la que ya haces copias. Para muchas aplicaciones esa es la respuesta correcta: un sistema menos, consistencia transaccional con el resto de tus datos y ninguna factura aparte.
Cuando basta una biblioteca embebida. Bibliotecas como FAISS o un vector store local manejan millones de vectores en un solo proceso. Si tus datos caben en una máquina y el volumen de consultas es modesto, un servicio gestionado está resolviendo un problema de operaciones que no tienes.
Cuando funcionaría la búsqueda por palabras clave. Una parte significativa de "necesitamos búsqueda semántica" acaba bien servida por BM25, que es más barato, más rápido, del todo explicable y mejor con identificadores exactos. Pruébalo primero — y nota que si acabas en Pinecone, su búsqueda full-text cubre esto en el mismo index.
Cuando no has medido la calidad de la recuperación. La base no suele ser el factor limitante de un sistema de recuperación. La estrategia de chunking, la elección del modelo de embedding y la formulación de la consulta importan mucho más, y las tres se pueden probar con cien líneas de código local antes de cualquier decisión de infraestructura.
El caso a favor de un servicio gestionado es real y concreto: muchos millones de vectores, volumen de consultas que exige baja latencia constante, aislamiento multi-tenant y un equipo que prefiere no operar un index distribuido. Si se aplican dos o más, merece su coste.
Preguntas frecuentes
¿Para qué se usa Pinecone?
Búsqueda semántica, recuperación de conocimiento y memoria a largo plazo para aplicaciones de IA. El patrón dominante es la generación aumentada por recuperación: encontrar los pasajes de tus propios documentos más relevantes para una pregunta y suministrarlos a un modelo de lenguaje como contexto.
¿Pinecone es gratis?
Hay un plan Starter gratuito con hasta 2 GB de almacenamiento, 2M de write units y 1M de read units al mes, y 1 GB de egress. Es realmente suficiente para construir y evaluar un prototipo real antes de comprometerte con un plan de pago.
¿Cuánto cuesta Pinecone?
Starter es gratis; Builder son 20 $/mes fijos con techos fijos; Standard tiene un mínimo de uso de 50 $/mes y Enterprise 500 $/mes; ambos facturan almacenamiento a 0,33 $/GB/mes, escrituras a 4–4,50 $ por millón de units y lecturas a 16–18 $ por millón, con egress a 0,10 $/GB después de 100 GB.
¿Qué es un namespace en Pinecone?
Una partición dentro de un index. Toda lectura y escritura apunta exactamente a un namespace, lo que lo convierte en el mecanismo estándar de aislamiento multi-tenant — un namespace por cliente — y en una optimización de rendimiento, ya que las consultas solo recorren la partición relevante.
¿Debo usar embedding integrado o mis propios vectores?
El embedding integrado es más simple: envía texto, Pinecone lo convierte. Traer los tuyos te da elección de modelo y portabilidad, lo que importa porque cambiar de modelo de embedding exige volver a embeder todo. Los indexes integrados tampoco admiten actualizar ni importar con texto.
¿Puede Pinecone hacer búsqueda por palabras clave además de vectorial?
Sí. Los campos string con full_text_search habilitado admiten ranking BM25 con sintaxis de consulta Lucene, en el mismo index que vectores densos y dispersos, con el método de puntuación elegido por consulta. Importa porque la búsqueda puramente vectorial maneja mal identificadores exactos y términos raros.
¿Cómo cargo millones de records con eficiencia?
Usa import desde object storage en lugar de upsert. La documentación lo recomienda de forma explícita para conjuntos de más de diez millones de records y lo describe como la vía más económica, lo que importa dado que las escrituras se facturan por millón de units.
¿Necesito una base vectorial en absoluto?
A menudo no. Por debajo de unos cien mil vectores, la fuerza bruta en memoria es suficientemente rápida y gratuita. Si ya ejecutas Postgres, pgvector evita un sistema aparte. Y una parte justa de los requisitos de "búsqueda semántica" se cubre bien con búsqueda por palabras clave, más barata y más explicable.
Cierre
Pinecone es una base de datos vectorial gestionada que ha crecido hacia algo más amplio: un index puede ahora guardar juntos vectores densos, vectores dispersos y campos full-text, con el método de ranking elegido por consulta. Esa consolidación es el cambio reciente más útil, porque la recuperación híbrida deja de ser una decisión de arquitectura y se vuelve un parámetro.
Tres cosas condicionan cómo debes diseñar sobre ella. Los namespaces son el mecanismo de aislamiento y rendimiento, y se crean de forma implícita: un namespace mal escrito devuelve un resultado vacío en vez de un error. La elección de embedding es más pegajosa de lo que parece, porque cambiar de modelo implica volver a embeder todo el corpus. Y las lecturas cuestan varias veces lo que las escrituras, lo que convierte la caché de consultas en una palanca directa de coste en un sistema pesado en lectura.
Los precios son transparentes y el plan gratuito es lo bastante grande para responder a la pregunta real: si la calidad de la recuperación es suficiente para tu caso. Esa pregunta no va de la base — el chunking, la elección de embedding y la formulación de la consulta la dominan — y se puede responder en local antes de que exista infraestructura.
Ese es el cierre honesto. Una base vectorial gestionada gana su sitio a escala, con multi-tenancy, o cuando prefieres no operar un index distribuido. Por debajo, un array en memoria o una extensión en el Postgres que ya ejecutas hará el trabajo por nada, y conviene establecer en qué situación estás antes de firmar por cualquiera de las dos.