How do you detect a company's vector store?

Best move: look at what the front end loads and calls, not at what the marketing page says.

Why it works: a vector store is backend infrastructure. To use one, an application has to load its client and hit its API, and those signatures survive minification. A homepage can claim anything. A running vector client cannot hide the library it imports.

Key takeaways

• Vector-store detection is signature matching on client libraries and API hostnames, not a keyword scan of the homepage.
• The five common targets (Pinecone, Weaviate, Qdrant, Chroma, Milvus) each carry a distinct fingerprint you can match from the outside.
• Server-rendered SDK imports appear in static HTML. Client-only initialization needs JavaScript rendering to surface.
• A detected vector store is one of the strongest signals that a company ships real AI rather than talks about it.
• Bassethound returns the vector store alongside the model provider and orchestration framework in one correlated dossier, so you read the whole stack at once.

What signatures give a vector store away?

Three kinds of evidence. First, package and client names in the loaded scripts: the Pinecone client, the Weaviate client, qdrant-client, chromadb, and the Milvus SDK all name themselves. Second, API hostnames in network calls: a managed store answers at its own domain, so a request to a Pinecone index endpoint is hard to mistake for anything else. Third, initialization patterns: the specific way each client opens a connection or names an index.

Any one of these is a lead. Two together is a confident match. Bassethound treats detection the way a scent hound treats a trail: one trace points to the next, and the goal is a confident identification, not a guess.

Which vector stores can you detect from the outside?

Managed stores are the easiest, because the client calls a hosted API you can name. Pinecone and hosted Weaviate fall here. Self-hosted and embedded stores are harder in proportion to how much of the work happens on the server. Chroma running embedded inside a Python backend, or a Qdrant instance behind a company’s own API, may expose nothing to a client-side crawl.

This is the honest limit of external detection, and it is worth stating plainly: you detect the stores that touch the browser or leave a named call. Bassethound reports the ones it can see and lists what it could not reach, rather than implying full coverage it does not have.

Why can’t a homepage scan find a vector store?

Because a vector store is not a marketing claim. It is a piece of the retrieval pipeline, and it lives in the application layer, not the copy. A site can put “AI-powered” in its hero and run nothing behind it, and a site can run Pinecone in production and never mention it. A homepage scan reads the first kind and misses the second. Signature matching on the actual stack reads the second kind, which is the one that matters.

This is why shallow AI-readiness checks disagree with reality so often. They read what a company says about AI. Detecting the vector store reads what a company built.

What does JavaScript rendering change?

A lot, for client-heavy sites. When a vector-store connection is set up only after the page hydrates in the browser, the signature is absent from the raw HTML and present only in the rendered runtime. A static crawl misses it. Rendering the page catches it, at the cost of time.

Bassethound decides whether to render based on what the first pass finds, and it records rendering gaps in the dossier. A static-only result that says “no vector store” means “none visible without rendering,” not “none exists,” and the output says so.

What does a detected vector store tell you about a company?

That it is probably running retrieval in production. Nobody stands up a vector database to look current. They stand one up because they are storing embeddings and querying them, which means real AI features with real data behind them. Combined with a model provider and an orchestration framework, a detected vector store moves a company from “experimenting” toward “shipping” on the AI-readiness verdict, and that verdict is a buying signal you can act on.

Bassethound perspective

Most tools that claim to measure AI-readiness read the homepage. They check whether a company mentions AI and whether it has an llms.txt, and they call that a score. That is the shallow end, and it rewards marketing over engineering.

A vector store is a better tell than any headline, because it is expensive to fake and pointless to fake. A company running Pinecone is running retrieval, full stop. Reading that signal is how you separate the companies shipping AI from the companies describing it, and it is exactly the axis most detection skips. Bassethound is built to read the stack, not the story. That is the difference between fan-out across five shallow tools and one correlated dossier that tells you what a company runs.

Sources

• Pinecone documentation, client libraries and API reference: https://docs.pinecone.io
• Weaviate developer documentation, client libraries: https://weaviate.io/developers/weaviate
• Qdrant documentation, client SDKs: https://qdrant.tech/documentation
• Chroma documentation: https://docs.trychroma.com
• Milvus documentation: https://milvus.io/docs