DEV Community: Giorgi

How to Make Your Catalog Searchable by AI Agents

Giorgi — Wed, 03 Jun 2026 11:08:02 +0000

A new kind of shopper showed up in 2026, and it isn't human. AI agents (the shopping modes in ChatGPT, Perplexity, and a growing list of assistants) now research products, compare options across stores, and in some cases complete the purchase, all without the person ever opening your website.

This changes what "being findable" means. For years the goal was to rank in Google and convert a human browsing your site. Now there's a second audience: software that reads your catalog programmatically and decides whether your product makes the shortlist. If an agent can't read and search your catalog, your products are invisible to it, no matter how good your SEO is.

This guide covers what AI agents actually need from your catalog, and how to expose it: structured product data they can read, and a search endpoint they can query.

How an AI Shopping Agent Finds Products

Picture a shopper who tells their assistant: "find me a waterproof barrel duffel under $120 for a kayaking trip." The agent doesn't browse. It does something closer to this:

Reads product data from stores it can access, as structured machine-readable records (attributes, price, availability), not rendered HTML.
Searches for products matching the intent, by meaning and increasingly by image, not by exact keyword.
Ranks and shortlists based on how well each product fits the request and how complete the data is.
Acts, either handing the shortlist back to the person or completing the purchase through an API.

Two of those steps depend entirely on your infrastructure: the agent has to be able to read your catalog, and it has to be able to search it. Get those two right and you're in the consideration set. Miss either and you're out.

Requirement 1: Structured Data the Agent Can Read

Agents don't want your product page. They want the facts behind it in a predictable format. That means structured data.

At minimum, expose for each product:

A stable product ID or SKU
Title and a real description (not marketing fluff, the actual attributes)
Price and currency
Availability and stock status
Key attributes: material, dimensions, color, category, and anything specific to your vertical
Image URLs

There are two common ways to surface this:

Schema.org markup on your pages. Add Product structured data (JSON-LD) so any agent crawling your site can parse it. This is table stakes and most ecommerce platforms support it.

A clean product feed or API. A JSON endpoint that returns your catalog as structured records. This is what agents prefer, because it's fast and unambiguous. If you already have a product feed for ads, you're most of the way there.

The principle is simple: anything an agent has to guess about your product is a reason to skip it in favor of a competitor whose data is explicit.

Requirement 2: A Search Endpoint the Agent Can Query

Structured data lets an agent read your catalog. But for an agent to find the right product out of thousands, it needs to search it the way it thinks: by intent and by image, not by exact keyword.

This is where most catalogs fall short. Default store search is keyword-based. An agent's query ("waterproof barrel duffel for kayaking") won't match a product titled "Voyager 60L Roll-Top Bag" through keywords, even though it's a perfect fit. Semantic search closes that gap because it matches meaning. Visual search closes the other half, because agents increasingly pass images ("find products like this photo") rather than text.

The practical move is to put your catalog behind a search API that handles both. Here's what that looks like with Vecstore.

Index each product once, carrying both its text and its image so it's findable either way:

await fetch(`${BASE_URL}/databases/${DB_ID}/documents`, {
  method: 'POST',
  headers: {
    'X-API-Key': API_KEY,
    'Content-Type': 'application/json',
  },
  body: JSON.stringify({
    image_url: 'https://store.com/products/voyager-duffel.jpg',
    text: 'Voyager 60L roll-top duffel, waterproof, marine-grade zipper',
    metadata: {
      sku: 'BAG-60L',
      price: 109,
      in_stock: true,
      category: 'bags',
    },
  }),
});

Now expose a single search endpoint an agent can call with a natural-language query:

app.post('/agent/search', async (req, res) => {
  const { query, top_k = 10 } = req.body;

  const result = await fetch(`${BASE_URL}/databases/${DB_ID}/search`, {
    method: 'POST',
    headers: {
      'X-API-Key': API_KEY,
      'Content-Type': 'application/json',
    },
    body: JSON.stringify({ text: query, top_k }),
  });

  const { results } = await result.json();

  // Return clean, structured records the agent can act on
  res.json(results.map((r) => ({
    sku: r.metadata.sku,
    price: r.metadata.price,
    in_stock: r.metadata.in_stock,
    score: r.score,
  })));
});

That's the whole interface an agent needs: send intent, get back structured, ranked products with the metadata required to make a decision. Because the same index also holds image embeddings, the agent can pass an image instead of text and the endpoint works the same way.

For a deeper walkthrough of the search side, see Ecommerce Search API: Add Visual and Semantic Search and How to Add a "Find Similar Products" Feature.

Make the Search Itself Agent-Friendly

A few details matter more for agents than for humans:

Return scores, not just results. Agents use the similarity score to decide confidence. A human eyeballs a grid; an agent needs the number.

Keep metadata complete and honest. Price, stock, and category in every record. An agent that finds a great match with no price will drop it for one that has it.

Return structured fields, not HTML. The endpoint above returns plain JSON, not a rendered card. That's what an agent can parse and act on.

Keep latency low. Agents often run many queries to fulfill one request. A slow endpoint gets timed out and skipped.

Why This Is Worth Doing Now

Agentic commerce is early, which is exactly why it's worth getting ahead of. The stores that are readable and searchable by agents today get included in shortlists while competitors are still serving keyword search and unstructured pages. The work also pays off immediately for your human shoppers, because semantic and visual search convert better than keyword search regardless of who (or what) is searching.

You don't need to rebuild your store. You need two things: structured product data exposed cleanly, and a search endpoint that understands meaning and images. The first is mostly configuration. The second is an API call.

The Bottom Line

The next wave of shoppers includes software that reads your catalog and decides whether your products qualify. Making your catalog agent-ready comes down to being readable (structured data) and searchable (semantic and visual search behind a clean API). Do both, and you're in the consideration set for human and agent shoppers alike.

Try Vecstore for free. 100 credits on signup, no credit card. Index a sample of your catalog and build an agent-ready search endpoint in an afternoon.

Ecommerce Search API: Add Visual and Semantic Search

Giorgi — Sat, 30 May 2026 20:50:51 +0000

Most online stores ship with search that matches keywords. A shopper types "navy linen shirt," and if your product titles say "indigo cotton-blend henley," they get zero results and leave. The product was right there. The search just didn't understand them.

An ecommerce search API fixes that. Instead of matching exact words, it understands meaning and visual similarity, so shoppers find products whether they describe them, misspell them, or upload a photo. This guide covers what an ecommerce search API actually does, what to look for when choosing one, and how to add visual and semantic search to your store.

Why Default Store Search Loses Sales

Search is one of the highest-intent actions a shopper takes. People who use site search convert at a much higher rate than people who only browse, because they already know what they want. Which means a bad search bar is leaking your best customers.

The default search on most platforms (Shopify, WooCommerce, Magento) is keyword-based. It has three predictable failure modes:

Vocabulary mismatch. The shopper's words don't match your product copy. "Couch" versus "sofa," "sneakers" versus "trainers," "winter coat" versus "insulated parka." Keyword search returns nothing.

No visual understanding. A shopper sees a dress on Instagram and wants something similar. They can't type their way to it. Without image search, that intent is lost.

Typos and natural language. "Wireless noise canceling headphons under 100" breaks most built-in search bars. A modern search API handles the typo, the price filter, and the natural phrasing.

Every one of those is a shopper who was ready to buy and couldn't find the product. An ecommerce search API closes that gap.

What an Ecommerce Search API Does

There are two capabilities that matter most for stores, and the best APIs offer both:

Semantic (text) search. The shopper describes what they want in natural language and the API returns products that match the meaning, not just the keywords. "Affordable laptop for school" surfaces budget student notebooks even if none of them literally say "affordable for school."

Visual (image) search. The shopper uploads or points to a photo and the API returns visually similar products from your catalog. This powers "find similar products," "shop the look," and reverse image lookup. No tagging required: the model understands what the product looks like.

Underneath, both work the same way. The API converts your products (their text and their images) into vector embeddings, stores them in an index, and at search time finds the closest matches. You don't have to build any of that. You insert products and call a search endpoint.

For a deeper look at the customer-facing side, see Visual Search for Ecommerce.

What to Look For When Choosing One

Multimodal in one API. You want text search and image search from the same product index, not two separate systems. If adding visual search means standing up a second service, the integration cost doubles.

Automatic embedding. The API should embed your products for you when you insert them. If you have to generate your own embeddings, you're back to running ML infrastructure.

Latency under 200ms. Search has to feel instant. Anything slower and shoppers abandon the box.

Pricing that fits a store. Pay-as-you-go per operation is friendly for stores with seasonal or uneven traffic. Watch for APIs that charge per stored vector, which punishes you for having a big catalog even on slow days.

Platform fit. If you're on Shopify or WooCommerce, check whether there's a clear integration path. The closer it is to a few API calls, the faster you ship.

A real free tier. You should be able to index a sample of your catalog and test relevance on real queries before paying.

How to Add It to Your Store

The pattern is the same regardless of platform: index your products, then call search. Here is what it looks like with Vecstore's API.

First, push your catalog into a searchable index. Each product can carry both its image and its text, so the same record is findable by description or by photo:

await fetch(`${BASE_URL}/databases/${DB_ID}/documents`, {
  method: 'POST',
  headers: {
    'X-API-Key': API_KEY,
    'Content-Type': 'application/json',
  },
  body: JSON.stringify({
    image_url: 'https://store.com/products/navy-henley.jpg',
    text: 'Navy cotton-blend henley, slim fit, long sleeve',
    metadata: { product_id: 'SKU-1024', price: 39 },
  }),
});

Then handle a text search from your store's search bar:

const res = await fetch(`${BASE_URL}/databases/${DB_ID}/search`, {
  method: 'POST',
  headers: {
    'X-API-Key': API_KEY,
    'Content-Type': 'application/json',
  },
  body: JSON.stringify({ text: 'navy linen shirt', top_k: 12 }),
});

const { results } = await res.json();

To add "find similar products," send a product image instead of text. Same endpoint, same index:

body: JSON.stringify({
  image_url: 'https://store.com/uploads/shopper-photo.jpg',
  top_k: 12,
}),

Each result returns the product's metadata (your SKU, price, anything you stored) and a similarity score, so you can render them straight into your product grid.

For platform-specific walkthroughs, see How to Add Image Search to Shopify and How to Add a "Find Similar Products" Feature.

Build vs Buy

You can build this yourself. It means choosing an embedding model, running inference on every product image and title, standing up a vector database, building an ingestion pipeline that re-embeds products when they change, and keeping it all running through your traffic peaks.

That's the right call if search is your core product or you have an ML team with spare capacity. For a store that needs better search as a feature, not as a second product, an API is faster and cheaper to operate. You skip the GPU bills, the vector database ops, and the weeks of pipeline work, and you get a search bar that converts.

The Bottom Line

Default store search costs you sales every day from shoppers who described a product slightly differently than you did. An ecommerce search API closes that gap with semantic and visual search, and modern ones do it behind a single HTTP call.

If you also want content moderation on user-uploaded images, or face search, the same API can cover those without a second integration.

Try Vecstore for free. 100 credits on signup, no credit card. Index a sample of your catalog and test relevance on your own products in an afternoon.

Reverse Image Search API: The Developer's Guide for 2026

Giorgi — Thu, 28 May 2026 04:45:23 +0000

If you've ever tried to add "find visually similar images" to an app, you've probably hit the same wall: the tutorials assume you want to spend a month training a CLIP model and standing up a vector database. Most teams don't. They want an HTTP endpoint they can POST an image to and get matches back.

That's what a reverse image search API is. This guide covers what it actually does under the hood, what to look for when choosing one, how the main options compare in 2026, and how to wire it into your app with a few lines of code.

What a Reverse Image Search API Does

You send an image. You get back a ranked list of visually similar images from your own catalog (or a public index, depending on the provider). No keywords, no tags, no manual feature extraction.

Under the hood, every API doing this in 2026 follows the same three steps:

Embed the query image using a vision model (usually a CLIP-family or SigLIP-style encoder). The output is a high-dimensional vector that captures what the image looks like.
Search that vector against an index of previously embedded images using approximate nearest neighbor (ANN) algorithms like HNSW or IVF.
Rank the closest matches by cosine similarity and return them with a score.

The trick is that you don't have to care about any of those steps. A good API hides all of it behind a single HTTP call.

Two Different Kinds of Reverse Image Search API

This category gets confused a lot, so it's worth being precise. There are two very different things people call a "reverse image search API":

Public web search APIs. You send an image, the service searches the public internet for visually similar pages and matches. Examples: TinEye, Google Lens (no official public API), Bing Visual Search, ImageRaider. Useful for copyright enforcement, brand monitoring, and finding the source of an image.

Private catalog APIs. You upload your own images to an index, then search against that index. The service never looks at the public web. Examples: Vecstore, Algolia Recommend, Imagga, plus self-hosted stacks built on Pinecone or Weaviate. This is what powers "find similar products" in e-commerce, duplicate detection in marketplaces, and "more like this" in stock photo sites.

Most developers Googling "reverse image search API" actually want the second one. They have a product catalog or a media library and they want users to search inside it visually. If that's you, the rest of this guide is aimed at you.

What to Look For When Picking One

Not all reverse image search APIs are built the same. Here's what actually matters in production:

Indexing model. Does the API embed the image for you, or do you have to provide your own embeddings? The first is far simpler. The second gives you control but means you're back to running inference yourself.

Latency. A typical search call should return in well under 200ms for catalogs up to a few million images. Anything above 500ms will start to feel broken in a real product.

Pricing model. Per-operation pricing scales with usage and is friendly when you're small. Per-vector storage pricing punishes you for having a big catalog even if traffic is low. Some APIs charge for both, which gets expensive fast.

Multimodal search. Can the same index also handle text-to-image search, OCR search, or face search? If yes, you avoid running multiple systems for related features.

Free tier. You should be able to test the API end-to-end on real images without entering a credit card. If the free tier is too small to load a real catalog into, the vendor is hiding the experience from you.

Self-host option. Most teams don't need it, but if your data can't leave your VPC, it matters. Few hosted APIs offer a self-hosted tier; most of the cheaper "self-host" options are really do-it-yourself stacks (pgvector, Qdrant, Weaviate) where you build the API yourself.

How the Main Options Compare in 2026

Quick rundown of the reverse image search APIs developers actually evaluate this year. Pricing is from each vendor's public page at the time of writing.

Vecstore. Single REST API for reverse image search, text-to-image search, OCR search, face search, and NSFW detection. Embedding is automatic on insert. Free tier with 100 credits, no credit card. Pay-as-you-go from $1.60 per 1K operations. Good fit for product teams that want one API for all visual search features.

Imagga. Image recognition platform with a similar-images endpoint as one piece of a broader catalog. Strong on tagging and color analysis. Pricing starts at a fixed monthly plan, which can be cheaper at higher volume but worse at low volume.

Algolia (Recommend / Visual Search). Mature search platform with visual similarity built as part of their broader product. Strong on relevance tuning. Pricing starts to add up fast once you cross their free tier; aimed at larger teams.

TinEye / ImageRaider. Public-web reverse search. If you want to find where an image appears across the internet (copyright, brand protection), this is the category. Not the right tool for searching your own catalog.

Pinecone / Weaviate / Qdrant + CLIP. Not an API in the same sense. You provide the embeddings (run a CLIP model yourself), they provide the vector index. Maximum control, maximum operational work. Reasonable choice if you have an ML team. Overkill if you just want similar-product search on a Shopify store.

For a deeper side-by-side on the vector database options, see pgvector vs Pinecone vs Qdrant benchmarks.

A Working Example in 12 Lines

Here's what calling a reverse image search API looks like in practice. This is Vecstore's API; most modern APIs in this category look similar.

First, insert images into your catalog. Each one is automatically embedded:

await fetch(`${BASE_URL}/databases/${DB_ID}/documents`, {
  method: 'POST',
  headers: {
    'X-API-Key': API_KEY,
    'Content-Type': 'application/json',
  },
  body: JSON.stringify({ image_url: 'https://example.com/product-001.jpg' }),
});

Then search by sending a query image:

const res = await fetch(`${BASE_URL}/databases/${DB_ID}/search`, {
  method: 'POST',
  headers: {
    'X-API-Key': API_KEY,
    'Content-Type': 'application/json',
  },
  body: JSON.stringify({ image_url: 'https://example.com/query.jpg', top_k: 10 }),
});

const { results } = await res.json();

Each result includes the matching image's ID and a similarity score between 0 and 1. Scores above 0.9 are near-duplicates; 0.7 to 0.9 is "clearly related"; below 0.5 starts to get noisy. Pick a threshold that fits your use case.

For a full walkthrough including an Express server with image uploads, see How to Build a Reverse Image Search Engine with JavaScript.

Is There a Free Reverse Image Search API?

Sort of. A few things people mean when they search this:

Free tier on a paid API. Most hosted providers (Vecstore included) give you a free quota every month so you can build, test, and run small projects without paying. This is the path most developers actually want.

Open-source self-hosted. You can build your own reverse image search using CLIP and pgvector or Qdrant for $0 in software cost. You'll pay in server time, GPU bills for inference, and engineering hours. It's "free" the way running your own database is "free."

Truly free hosted APIs. A few academic and demo APIs exist (mostly built on top of CLIP and a tiny index). They tend to be rate-limited, unreliable, and not built for production. Fine for a hackathon. Don't ship on them.

If you just want to try the API category without committing, a free tier on a production-grade API is the realistic path. Vecstore's free tier gives you 100 credits with no credit card.

When You Don't Need an API at All

A reverse image search API solves a specific class of problems well: visual similarity at scale, with low latency, across a catalog of thousands to millions of images. If your problem is smaller than that, you have simpler options.

Under 1,000 images. A perceptual hash (pHash) library plus a SQL LIKE query on hash strings can be enough for duplicate detection or near-duplicate matching. No API needed.

Exact-match only. If you just need to know when the exact same file has been uploaded twice, SHA-256 of the file bytes does it for free.

Tag-based search. If your "visual search" is really "find products tagged as red shoes," that's a normal database query plus a tagging step. You don't need vectors at all.

The API category earns its keep when you need to match images that are similar but not identical (rotated, cropped, recolored, different angle of the same object) and your catalog is too big to compare every pair manually.

The Bottom Line

A reverse image search API in 2026 is a commodity in the same way that "send an email API" is. The interesting question isn't whether to build the embedding pipeline yourself (you shouldn't, unless you're a search vendor). It's which provider fits your stack, your pricing model, and the rest of your visual search needs.

If you also want text-to-image search, OCR, face search, or NSFW detection in the same product, picking one API that does all of them saves you from running several services.

Try Vecstore for free. 100 credits on signup, no credit card. Build a working reverse image search in an afternoon.

Fashion Visual Search: A Practical Guide for E-Commerce Teams

Giorgi — Sat, 23 May 2026 10:43:50 +0000

Fashion is the worst category for text search. Shoppers don't know the right words. "That kind of dress my friend wore last summer" isn't a query you can index. "Floral midi with puff sleeves" assumes the shopper knows the vocabulary, and most don't.

Visual search fixes this. A shopper uploads a photo, screenshots a TikTok, or points their camera at a friend's outfit, and your store returns the closest matches from your catalog. No keywords. No filters. Just "show me this."

This is not a futuristic feature anymore. It's standard in major fashion apps and a clear differentiator for everyone else. This post walks through what visual search actually does, where it works, where it doesn't, and how to ship it without hiring an ML team.

Why Text Search Loses in Fashion

Fashion is visual by nature. A "blue cotton shirt" can mean a hundred different products, and most shoppers don't have the words to narrow it down. They know what it looks like. They don't know what it's called.

The result is the worst session pattern in e-commerce: shopper searches, gets 200 unrelated results, scrolls, gives up. The product was in the catalog. The shopper was ready to buy. The search failed.

Filters don't fix this. You can offer color, fit, neckline, sleeve length, occasion, season, brand. Shoppers don't know they want a "boatneck" until they see one. Filters work for shoppers who already know what they want. The high-value shoppers in fashion are the ones who don't.

Visual search bypasses the entire language problem. Pixels in, products out.

What Visual Search Actually Does

There are a few distinct features that all get called "visual search." Worth separating them:

Reverse image search. Shopper uploads a photo, you return the closest products in your catalog. The classic use case. Works for finding a specific item or anything that looks like it.

Camera search. Same idea, but live from the phone camera. Shopper points at a real-world item and your app shows similar products in your store. Heavy in mobile apps.

Shop the look. Shopper uploads an outfit photo, you detect each item (shirt, pants, shoes) and return matches for each one separately. Higher complexity, higher conversion.

Visual similarity on PDPs. "Similar to this product." A 6-item carousel of visually close products on every product page. Lifts AOV without changing the rest of the site.

Text-to-image search. Shopper types a description, you return visually matching products even when the description doesn't match any titles. "Red dress with thin straps" returns the right red dresses even if none have those exact words.

For most fashion stores, the lowest-effort highest-impact starting point is visual similarity on PDPs. It runs on every product page, lifts session depth, and doesn't change the rest of the site UX.

What Visual Search Doesn't Do

A reality check before anyone builds this.

It's not magic on bad photos. Phone screenshots, dark lighting, busy backgrounds. Quality degrades. The good systems handle most of this, but extreme cases still fail.

It doesn't read intent. A shopper might upload a yellow dress and want any dress shape, not specifically yellow. Or want any color, not that specific yellow. Visual systems return the closest visual match. Without explicit filters, intent is ambiguous.

It doesn't replace search, it adds to it. Visual search wins on discovery and "shop the look" use cases. Text search still wins for direct queries ("nike air force 1 size 9"). Most fashion stores need both.

Catalog quality is everything. Bad product photos in your catalog mean bad results. Multiple background colors, inconsistent crop, missing angles. Visual search amplifies whatever you have. Clean catalogs win.

How Visual Search Actually Works

Behind the buzzword, it's straightforward.

Every product image is converted to an embedding (a list of numbers that represents the visual content).
All embeddings are stored in a database optimized for similarity search.
A shopper's uploaded image is converted to the same kind of embedding.
The system finds the closest stored embeddings and returns the matching products.

The math is "find nearest neighbors in high-dimensional space." The model doing the embedding is usually CLIP or a CLIP variant, trained to understand both images and text in the same space (which is why text-to-image search works too).

If you're building this from scratch, you need: a CLIP-style model running on GPU, an inference pipeline for new product uploads, a vector database for storage and search, and the glue code to keep your catalog and embeddings in sync.

If you're using a managed search API, you upload product images and call the search endpoint. The model, the pipeline, the database, and the sync are all hidden.

The Build Decision: From Scratch vs Managed API

The honest cost breakdown.

Building from scratch.

You'll need an ML engineer (or a backend engineer who can pretend to be one). You'll need GPU inference (either self-hosted with serving infra, or via a hosted model API). You'll need a vector database. You'll need an embedding pipeline that processes new products on upload, re-processes when images change, and handles failures cleanly.

Realistic timeline for a small team: 4-8 weeks to a working version, then ongoing maintenance forever. Cost: GPU compute, vector DB hosting, engineering time, and the opportunity cost of not shipping other things.

Managed search API.

You insert product images into the API. You call the search endpoint with a query image. You get matching product IDs back. That's the integration.

With Vecstore, that looks like this:

// Upload a product
await fetch(`https://api.vecstore.app/databases/${dbId}/records`, {
  method: 'POST',
  headers: {
    'Authorization': `Bearer ${apiKey}`,
    'Content-Type': 'application/json',
  },
  body: JSON.stringify({
    id: product.id,
    text: `${product.title} ${product.description}`,
    image_url: product.imageUrl,
    metadata: {
      price: product.price,
      brand: product.brand,
      category: product.category,
      in_stock: product.inStock,
    },
  }),
});

// Visual search by image
const response = await fetch(`https://api.vecstore.app/databases/${dbId}/search`, {
  method: 'POST',
  headers: {
    'Authorization': `Bearer ${apiKey}`,
    'Content-Type': 'application/json',
  },
  body: JSON.stringify({
    image_url: uploadedImageUrl,
    limit: 24,
    filter: { in_stock: true },
  }),
});

const { results } = await response.json();

Timeline for a small team: a weekend. Maintenance: none.

The from-scratch route makes sense if you're at scale and have an ML team. For everyone else, the managed route is the obvious pick.

What to Track to Make Visual Search Better

Don't ship and forget. The metrics that matter:

CTR on visual search results. Of users who run a visual search, what percentage click a result? Below 30% means the model isn't finding their intent. Look at query examples.

Conversion from visual search sessions. Sessions that include a visual search query convert at higher rates than text-only sessions. Track this and report it. It's how you justify continued investment.

Catalog coverage. What percentage of your catalog has appeared in visual search results in the last 30 days? Low coverage means visual search is recirculating the same hits and missing your long tail.

Stock-out rate in results. If 20% of results are out of stock, you're killing trust. Filter at query time.

Bounce rate by query type. Uploaded images vs camera vs text-to-image. If one query type bounces hard, the UX or the model is failing for that flow.

UX Patterns That Work

Some patterns that consistently outperform.

Camera icon in the search bar. Don't bury it. Camera icon in the main search input on mobile drives 5-10x more visual searches than a separate page.

Drag and drop on desktop. Shoppers screenshot Instagram. Make it dead simple to drop that into your search.

"Shop this" on user-generated content. If you have customer photos, lookbooks, or social embeds, make every image searchable. Highest-converting visual searches start from inspiration content.

Visual similarity on every PDP. A "Similar styles" carousel below the fold lifts AOV and recovers shoppers who don't love the current product.

Outfit completion. Shopper looks at a top, you suggest visually-matching bottoms and shoes. The shop-the-look concept on a single product.

What's Next for Visual Search

Two patterns are coming fast in fashion:

Style transfer queries. "Show me this dress but in a different cut." The shopper uploads one item and modifies the query in natural language. Mixed visual + text queries are increasingly common.

Outfit-as-query. Upload a full outfit photo, get a basket of products that recreate the look. Going from "find one item" to "find an outfit" is the next frontier.

You don't need to ship these to get value from visual search today. The basics (reverse image search, visual similarity on PDPs, text-to-image search) are enough to materially change discovery and conversion in fashion. Start there.

The Bottom Line

Fashion shoppers describe what they want in pictures. Your search needs to accept that input or you're losing the high-intent half of your traffic.

Visual search used to be a multi-month engineering project. It isn't anymore. A managed search API gives you reverse image search, text-to-image search, and visual similarity from one endpoint, with no model to train and no pipeline to maintain.

If your store sells fashion and you're still text-only, you're leaving conversion on the table. Visual search is the lowest-effort, highest-impact upgrade in the category.

Try Vecstore free or explore the API docs.

The Hidden Costs of Self-Hosting Your Vector Database

Giorgi — Wed, 22 Apr 2026 14:12:14 +0000

The pricing page for self-hosted Qdrant says $0. Milvus says $0. pgvector says $0. That's the advertised cost. Then you actually run it in production and the bills start showing up in places you didn't expect.

This post prices out the real TCO of self-hosting a vector database. Not the compute cost, which everyone already knows. The stuff that shows up on month three when you realize "open source" doesn't mean "free to operate."

The Quoted Cost

Every self-hosted vector database pitch starts the same way. "Skip the $500/month Pinecone bill. Self-host for $100 on a single VM." The math looks obvious.

For a 10M vector workload:

Option	Monthly Cost
Pinecone (managed)	$500-1,500
Qdrant self-hosted (1 node)	$100-300
Milvus self-hosted (1 node)	$150-400
pgvector on existing Postgres	$0 (marginal)

Those self-hosted numbers are correct. They're also incomplete. What they measure is the VM rental cost. Not the cost of running a vector database on that VM.

Hidden Cost #1: High Availability

A single-node setup is fine until it's not. When that node reboots, your search is down. When the disk fills up, your search is down. When the Linux kernel pushes a security patch, your search is down.

The fix is a three-node cluster. Which means the $100 VM becomes three $100 VMs, plus a load balancer, plus whatever you use to coordinate them. Suddenly your $100 pricing-page number is $350-500/month.

And that's before you've thought about:

Multi-AZ deployment for cloud-provider availability zone failures
Backups that actually restore (not just snapshot, but tested)
Read replicas if your query volume saturates a single node

Pinecone does all of this invisibly. You pay $500/month and you get HA. Self-hosting, you pay for the VMs and do the HA engineering yourself.

Hidden Cost #2: Engineering Time

This is the big one. And it's the one the pricing comparisons always skip.

Setting up a production vector database cluster is not a one-weekend job. It includes:

Choosing the right VM types, storage tiers, and network config
Configuring replication, sharding, and consistency settings
Writing Terraform or Pulumi for reproducible deployments
Setting up backup/restore (and testing it)
Monitoring, alerting, and dashboards
Load testing to find breakpoints before production does
Documentation so the next engineer can maintain it

Realistic timeline: 3-6 weeks for an engineer with prior Kubernetes/infra experience. Longer if they're learning as they go.

At a $150K/year total comp (a conservative US figure), that's $9,000-$18,000 in upfront engineering cost before a single query runs. Even at EU rates, you're in the $5K-$10K range.

This isn't the argument to not self-host. It's the argument that "free software" isn't free software plus hardware. It's free software plus hardware plus the labor to operate it.

Hidden Cost #3: The On-Call Tax

Once your vector database is in production, it's part of your oncall rotation. Every alert, every 3am page, every "search is slow" ticket — somebody has to debug it. And that somebody needs to understand:

How HNSW indexing works when it's slow
Why p99 latency spiked when p50 is fine
Whether the memory pressure is from the index, the cache, or a leak
How to safely resize a cluster without downtime
What to do when a node's disk fills up and the service crashes

None of this is in the Qdrant docs. You learn it in production, usually at the worst time.

Budget: 0.25 FTE for ongoing operations of a small cluster. 0.5-1 FTE for a big one. That's $30K-$150K/year of engineering time, depending on headcount and comp.

Hidden Cost #4: Upgrades

Vector databases are young. New versions come out every month. Every version has:

New features you want
Performance improvements you want
Bug fixes you need
Breaking changes you don't want

Upgrading is not apt-get update. You need to test the new version against your workload, schedule a maintenance window (or do a rolling upgrade, which is more complex), and watch for regressions in the days after.

If you skip upgrades, you fall behind. Eventually you're 10 versions back and the upgrade path is a migration project. Teams that don't plan for upgrades end up doing a painful rewrite every 18 months.

Hidden Cost #5: Re-Indexing

At some point you're going to want to change something. A new embedding model. A different vector dimension. A better index type. A new distance metric.

Any of these means re-embedding and re-indexing your entire dataset. For 10M vectors:

Compute to re-embed: GPU cost to run every document through the new model. See our 1M image cost breakdown — roughly $30-100 for 10M items on a spot g6.xlarge.
Double-capacity window: you need the old and new indexes online simultaneously during cutover
Engineering time: a couple weeks to build the pipeline, test, and migrate

Managed services handle some of this for you. If Pinecone upgrades its underlying index, you don't notice. If you self-host, you're the one scheduling the re-indexing job and watching it run for three days.

Hidden Cost #6: Observability

A production vector database needs metrics. Not just "is the server up" metrics. The kind of metrics that tell you:

p50/p95/p99 query latency
Index memory pressure
Queue depths for inserts
Cache hit rates
Replication lag

The vector database itself exports some of these. Hooking them into Prometheus/Grafana, setting up alerts, and tuning the alert thresholds so you get paged for real problems and not noise — that's a project. A week of engineering time minimum, with ongoing tuning.

Plus the infra cost. A dedicated monitoring stack runs $50-200/month depending on retention. Datadog or a managed equivalent runs $300-1,000/month for a modest workload.

Hidden Cost #7: Security and Compliance

"We self-host because of compliance" is a common reason. Fair. But self-hosting doesn't automatically make you compliant. You still need:

Encryption at rest (configured correctly)
Encryption in transit (with proper cert rotation)
Network isolation (VPCs, security groups, no public access)
Access controls (who can query, who can insert, who can drop the collection)
Audit logs that someone actually reviews
Regular vulnerability scans and patching

Most managed vector databases are SOC 2 certified, so your compliance story piggybacks on theirs. Self-hosted, you own the entire compliance perimeter. That's weeks of work for initial compliance and ongoing effort to keep it.

The Real TCO

Let's add it up for a 10M vector workload running on self-hosted Qdrant with HA:

Cost Category	Monthly	Annual
3-node cluster VMs	$350	$4,200
Load balancer + networking	$30	$360
Monitoring stack	$100	$1,200
Backups + storage	$50	$600
Infrastructure subtotal	$530	$6,360
Initial build (amortized over 2 yrs)	$500	$6,000
Ongoing ops (0.25 FTE)	$2,500	$30,000
True TCO	$3,530	$42,360

The infrastructure is $530/month. The real cost is $3,530/month. That's what the pricing comparisons miss.

Compare to Pinecone at $500-1,500/month for the same workload. It's 2-7x cheaper when you include engineering time.

When Self-Hosting Actually Wins

Self-hosting isn't always a bad choice. It wins in specific scenarios:

Very large workloads. Past 100M vectors, the managed pricing gets steep. Self-hosted Qdrant or Milvus at that scale can be 3-5x cheaper, and the engineering overhead amortizes over a bigger bill.

Existing platform team. If you already have a platform team running Kubernetes and databases, adding a vector database is marginal. The engineering tax is already paid.

Hard compliance or data residency. Some regulated environments require data to never leave your VPC. Self-hosting might be the only option, and the engineering cost is just the cost of doing business.

Research or experimentation. For non-production workloads where uptime doesn't matter, self-hosting is fine. Spin up a single Qdrant node, don't worry about HA, move on.

For everyone else — small teams, startups, internal tools, prototypes — managed wins. The math on engineering time is brutal.

The Alternative

There's a third option that doesn't show up in "self-hosted vs managed" comparisons: not running a vector database at all.

For a lot of use cases, you don't need to manage a vector database. You need search that works. Vecstore is one option in this category — a search API that handles embedding, vector storage, and query serving in one thing. No cluster to run, no index to tune, no engineering team to maintain.

This is the real question to ask before choosing a vector database: do I need a vector database, or do I need search? If the answer is search, the vector database is just infrastructure overhead.

We covered this in more detail in You Don't Need a Vector Database.

Wrapping Up

The quoted cost of self-hosting a vector database is real. It's also the smallest line item on the actual bill. Engineering time, on-call burden, upgrades, and operations dwarf the compute cost in almost every scenario.

Before picking self-hosted based on the pricing page, run the real TCO numbers. Include engineering time at your team's actual rate. Include the on-call tax. Include the re-indexing you'll do in 12 months when you switch embedding models.

If the math still works, self-host. If not, the managed option was probably cheaper all along.

See how Vecstore compares or sign up for the free tier to skip the infra conversation entirely.

How to Build Pinterest-Style Visual Discovery

Giorgi — Wed, 22 Apr 2026 14:12:04 +0000

Most image search tutorials build a search bar. Type "red sneaker", get red sneakers. That's search.

Pinterest isn't search. Pinterest is discovery. You open the app, scroll a masonry grid of images, tap one that catches your eye, and suddenly your whole feed shifts toward that taste. No keywords typed. No search button pressed. The system figures out what you like from what you click and serves more of it.

This tutorial builds that. A Pinterest-style discovery feed where the grid reacts in real-time to what the user engages with, using visual similarity under the hood.

What We're Building

A masonry grid feed with infinite scroll
A React component that loads images from your backend
A backend that tracks clicks and biases future results toward what the user engaged with
Visual similarity search powered by Vecstore

The key difference from a normal search: the feed has no query box. It just learns.

Prerequisites

Node.js 18+
A Vecstore account (free tier works)
An image database seeded with a few hundred images
Basic React knowledge

How the Discovery Loop Works

Before the code, the mental model. Pinterest's "related pins" isn't magic. It's three things stacked together:

Visual embeddings — every image is a vector in a shared space
User signal — when a user taps an image, that's a signal they like that style
Feed bias — the next batch of images is weighted toward things similar to what they tapped

So the loop is: show images → track which ones get tapped → use tapped images as "query" for the next batch → repeat.

The more the user interacts, the more the feed converges on their taste. No explicit search, no categories, no tags.

Step 1: Build the Backend

Create server.js. This handles initial feed, related images, and tap tracking.

import express from 'express';
import cors from 'cors';

const app = express();
app.use(cors());
app.use(express.json());

const API_KEY = process.env.VECSTORE_API_KEY;
const DB_ID = process.env.VECSTORE_DB_ID;
const BASE = 'https://api.vecstore.app/api';
const HEADERS = {
  'X-API-Key': API_KEY,
  'Content-Type': 'application/json',
};

// naive in-memory session store. use Redis in production.
const sessions = new Map();

// GET /feed?session=xxx&cursor=0 - return next batch
app.get('/feed', async (req, res) => {
  const { session, cursor = 0 } = req.query;
  const state = sessions.get(session) || { tapped: [], seen: new Set() };

  let results = [];

  if (state.tapped.length === 0) {
    // cold start - random popular items
    results = await getColdStart(parseInt(cursor));
  } else {
    // bias toward recently tapped images
    results = await getBiasedFeed(state.tapped, state.seen);
  }

  // mark as seen so we don't show again
  results.forEach(r => state.seen.add(r.vector_id));
  sessions.set(session, state);

  res.json({
    results,
    nextCursor: parseInt(cursor) + results.length,
  });
});

// POST /tap - user interacted with an image
app.post('/tap', (req, res) => {
  const { session, vector_id, image_url } = req.body;
  const state = sessions.get(session) || { tapped: [], seen: new Set() };

  // keep last 5 taps as query signal
  state.tapped = [{ vector_id, image_url }, ...state.tapped].slice(0, 5);
  sessions.set(session, state);

  res.json({ ok: true });
});

// GET /similar/:id - full-page "related" view
app.get('/similar/:id', async (req, res) => {
  const result = await fetch(`${BASE}/databases/${DB_ID}/search`, {
    method: 'POST',
    headers: HEADERS,
    body: JSON.stringify({ vector_id: req.params.id, top_k: 30 }),
  });
  res.json(await result.json());
});

app.listen(3001, () => console.log('Running on 3001'));

Step 2: Cold Start and Biased Feed Logic

Two helper functions do the real work.

// Cold start - no user signal yet. Use random seed queries
// to surface variety. In production, replace with your
// trending/popular items.
const COLD_START_QUERIES = [
  'minimalist home decor',
  'vintage fashion',
  'modern architecture',
  'nature photography',
  'food styling',
  'street art',
];

async function getColdStart(cursor) {
  const query = COLD_START_QUERIES[
    Math.floor(Math.random() * COLD_START_QUERIES.length)
  ];

  const result = await fetch(`${BASE}/databases/${DB_ID}/search`, {
    method: 'POST',
    headers: HEADERS,
    body: JSON.stringify({ query, top_k: 20 }),
  });

  const data = await result.json();
  return data.results || [];
}

// Biased feed - take last few tapped images and search
// for similar ones. Mix results so feed doesn't converge too fast.
async function getBiasedFeed(tapped, seen) {
  // pick one tapped image at random, weighted toward recent
  const weighted = tapped.flatMap((t, i) =>
    Array(tapped.length - i).fill(t)
  );
  const pick = weighted[Math.floor(Math.random() * weighted.length)];

  const result = await fetch(`${BASE}/databases/${DB_ID}/search`, {
    method: 'POST',
    headers: HEADERS,
    body: JSON.stringify({
      image_url: pick.image_url,
      top_k: 30,
    }),
  });

  const data = await result.json();

  // filter out already-seen items and cap to 20
  return (data.results || [])
    .filter(r => !seen.has(r.vector_id))
    .slice(0, 20);
}

Two things worth noting:

Weighted recency. Recent taps matter more than old ones. The weighted array duplicates newer items so random picks lean toward recent interactions.

Seen filtering. Without this, the feed loops. User taps a blue chair, sees similar chairs, taps one, sees the same chairs again. Tracking seen IDs per session keeps the feed fresh.

Step 3: Build the Masonry Grid

Install the frontend dependencies:

npm install masonic

masonic handles the tricky part — virtualized masonry layout with variable heights. It renders tens of thousands of cells without lag.

Create DiscoveryFeed.jsx:

import { useState, useEffect, useCallback } from 'react';
import { Masonry } from 'masonic';

const API = 'http://localhost:3001';

// persistent session id - simple random string in localStorage
function getSessionId() {
  let id = localStorage.getItem('vs-session');
  if (!id) {
    id = Math.random().toString(36).slice(2);
    localStorage.setItem('vs-session', id);
  }
  return id;
}

export default function DiscoveryFeed() {
  const [items, setItems] = useState([]);
  const [cursor, setCursor] = useState(0);
  const [loading, setLoading] = useState(false);
  const session = getSessionId();

  const loadMore = useCallback(async () => {
    if (loading) return;
    setLoading(true);

    const res = await fetch(
      `${API}/feed?session=${session}&cursor=${cursor}`
    );
    const data = await res.json();

    setItems(prev => [...prev, ...data.results]);
    setCursor(data.nextCursor);
    setLoading(false);
  }, [cursor, loading, session]);

  useEffect(() => {
    loadMore();
  }, []);

  const handleTap = async (item) => {
    await fetch(`${API}/tap`, {
      method: 'POST',
      headers: { 'Content-Type': 'application/json' },
      body: JSON.stringify({
        session,
        vector_id: item.vector_id,
        image_url: item.metadata.image_url,
      }),
    });

    // after tap, prepend fresh batch to feed
    const res = await fetch(
      `${API}/feed?session=${session}&cursor=${cursor}`
    );
    const data = await res.json();
    setItems(prev => [...data.results, ...prev]);
    setCursor(data.nextCursor);
  };

  return (
    <Masonry
      items={items}
      columnGutter={12}
      columnWidth={240}
      overscanBy={5}
      onRender={(startIdx, stopIdx, items) => {
        // trigger load when near bottom
        if (stopIdx >= items.length - 10) loadMore();
      }}
      render={({ data }) => (
        <div onClick={() => handleTap(data)}
             style={{ cursor: 'pointer' }}>
          <img
            src={data.metadata.image_url}
            alt=""
            style={{
              width: '100%',
              display: 'block',
              borderRadius: 8,
            }}
            loading="lazy"
          />
        </div>
      )}
    />
  );
}

Three things happening:

Masonry handles layout and virtualization. Columns auto-size to columnWidth={240}.
onRender fires as rows mount. When user is within 10 items of the bottom, load the next batch.
handleTap sends the tap to the backend, then refetches so the feed reacts immediately.

That last part is the magic. The user taps an image → backend records it → next fetch biases toward similar images → feed shifts in real-time.

Step 4: Add the Related Modal

Pinterest also has a "related" view when you click into a pin. Full-page view of the pin with similar images below. Here's a minimal version.

import { useState } from 'react';

export function PinModal({ item, onClose }) {
  const [related, setRelated] = useState([]);

  useEffect(() => {
    if (!item) return;
    fetch(`${API}/similar/${item.vector_id}`)
      .then(r => r.json())
      .then(data => setRelated(data.results || []));
  }, [item]);

  if (!item) return null;

  return (
    <div onClick={onClose}
         style={{
           position: 'fixed', inset: 0,
           background: 'rgba(0,0,0,0.85)',
           overflow: 'auto', padding: 24, zIndex: 1000,
         }}>
      <div onClick={e => e.stopPropagation()}
           style={{ maxWidth: 900, margin: '0 auto' }}>
        <img src={item.metadata.image_url}
          style={{ width: '100%', borderRadius: 12 }} />
        <h3 style={{ color: 'white', marginTop: 24 }}>More like this</h3>
        <div style={{
          display: 'grid',
          gridTemplateColumns: 'repeat(auto-fill,minmax(180px,1fr))',
          gap: 12,
        }}>
          {related.map(r => (
            <img key={r.vector_id}
              src={r.metadata.image_url}
              style={{ width: '100%',
                       aspectRatio: 1,
                       objectFit: 'cover',
                       borderRadius: 8 }} />
          ))}
        </div>
      </div>
    </div>
  );
}

Wire it into DiscoveryFeed by setting a selectedItem state on tap and rendering <PinModal item={selectedItem} onClose={...} /> at the bottom.

Tuning the Discovery Loop

The basic version works. But a few knobs matter for the feel of the feed.

Tap window. Right now the backend keeps the last 5 taps as signal. Too few and the feed over-reacts to any single tap. Too many and it never adapts. 5-10 is a good range.

Recency weight. The weighted picker biases toward recent taps. You can strengthen this by using exponential weights (Math.pow(2, tapped.length - i - 1)) instead of linear.

Variety injection. Pure similarity makes the feed claustrophobic. Every 5th or 6th item, inject something random from cold-start queries. Breaks the filter bubble and surfaces new things the user might like.

async function getBiasedFeed(tapped, seen) {
  const similar = await fetchSimilar(tapped, seen, 16);
  const variety = await getColdStart(0);

  // interleave - similar, similar, similar, variety, repeat
  const mixed = [];
  let vi = 0;
  for (let i = 0; i < similar.length; i++) {
    mixed.push(similar[i]);
    if ((i + 1) % 4 === 0 && variety[vi]) {
      mixed.push(variety[vi++]);
    }
  }
  return mixed;
}

Negative signal. Pinterest uses "not interested" buttons. You can track skipped items (scrolled past without tapping) and down-weight similar images. This requires more instrumentation but drastically improves feed quality over time.

Things to Keep in Mind

Session state in production. The in-memory Map works for a demo. For real users, use Redis or a persistent store keyed to user ID. Taps should survive across devices.

Image loading performance. Masonry grids are image-heavy. Use loading="lazy" on every image. Serve multiple sizes and let the browser pick with srcSet. For production, put images on a CDN with automatic format conversion (WebP, AVIF).

Vecstore vector_id search. The /similar/:id endpoint uses vector_id instead of image_url. This is faster because Vecstore doesn't need to re-embed — it already has the vector. Use this whenever you have the ID.

Cost management. Every scroll triggers API calls. For a popular feed, that's a lot of queries. Cache the first few cold-start batches (they're the same for new users). Cache related results per vector ID. The traffic goes from "one API call per scroll" to "one API call per tap" fast.

Cold start is a design problem. The six cold-start queries above are placeholders. For a real product, replace them with trending items, editorial picks, or a curated onboarding set. The first 30 seconds of a new user's session determine whether they stick.

What Else You Can Do

The same discovery pattern works for:

Product discovery on an e-commerce store (what we covered in find similar products but as a whole feed instead of a sidebar)
Dating apps where "taps" are swipe rights and the feed learns your type
Real estate browsing where clicking a property biases toward similar listings
Recipe discovery where engagement shapes the next batch toward your taste

It's the same loop. Images in, visual embeddings out, engagement signal drives the next batch.

Wrapping Up

Full setup: an Express backend with three routes, a React component with a masonry grid, and session-based tap tracking. The discovery loop is fewer than 200 lines of code.

The thing that makes this feel like Pinterest isn't the layout. It's the feedback loop. Every tap reshapes the next batch. Users don't realize they're training the feed — they just feel like the app "gets them." That's what keeps them scrolling.

Get started with Vecstore - free tier includes enough credits to build and test a discovery feed.

How to Add Image Search to a Shopify Store

Giorgi — Thu, 16 Apr 2026 06:04:54 +0000

Most Shopify search bars only understand keywords. A customer looking for "that kind of minimalist wooden shelf" gets a page full of irrelevant results or nothing at all. They had a clear picture in their head, but the search bar couldn't understand it.

Image search fixes this. A customer uploads a photo or screenshot and your store finds visually similar products from your catalog. No tags, no keywords, no hoping the customer describes the product the same way you did.

This tutorial walks through the full setup: syncing your Shopify product catalog into a searchable image database, building the search backend, and adding it to your storefront.

What We're Building

A script that pulls all products from your Shopify store and indexes their images
A backend that handles text-to-image and image-to-image search
A search widget for your Shopify storefront
A "similar products" section on product pages

Prerequisites

A Shopify store with products
A Shopify custom app with read_products scope
A Vecstore account (free tier works)
An image database created in the Vecstore dashboard
Node.js 18+

Step 1: Sync Your Shopify Catalog

First, pull your products from Shopify and insert their images into Vecstore. Create sync-catalog.js:

const SHOPIFY_STORE = 'your-store.myshopify.com';
const SHOPIFY_TOKEN = process.env.SHOPIFY_ACCESS_TOKEN;
const VECSTORE_KEY = process.env.VECSTORE_API_KEY;
const VECSTORE_DB = process.env.VECSTORE_DB_ID;

async function fetchProducts(cursor = null) {
  const query = `{
    products(first: 50${cursor ? `, after: "${cursor}"` : ''}) {
      edges {
        cursor
        node {
          id
          title
          handle
          priceRangeV2 {
            minVariantPrice { amount currencyCode }
          }
          featuredImage { url }
          images(first: 1) {
            edges {
              node { url }
            }
          }
        }
      }
      pageInfo { hasNextPage }
    }
  }`;

  const res = await fetch(
    `https://${SHOPIFY_STORE}/admin/api/2026-04/graphql.json`,
    {
      method: 'POST',
      headers: {
        'X-Shopify-Access-Token': SHOPIFY_TOKEN,
        'Content-Type': 'application/json',
      },
      body: JSON.stringify({ query }),
    }
  );

  return res.json();
}

async function insertImage(imageUrl, metadata) {
  const res = await fetch(
    `https://api.vecstore.app/api/databases/${VECSTORE_DB}/documents`,
    {
      method: 'POST',
      headers: {
        'X-API-Key': VECSTORE_KEY,
        'Content-Type': 'application/json',
      },
      body: JSON.stringify({ image_url: imageUrl, metadata }),
    }
  );

  return res.json();
}

async function syncAll() {
  let cursor = null;
  let count = 0;

  while (true) {
    const data = await fetchProducts(cursor);
    const edges = data.data.products.edges;

    for (const { node, cursor: c } of edges) {
      const imageUrl = node.featuredImage?.url
        || node.images.edges[0]?.node.url;

      if (!imageUrl) continue;

      await insertImage(imageUrl, {
        shopify_id: node.id,
        title: node.title,
        handle: node.handle,
        price: node.priceRangeV2.minVariantPrice.amount,
        currency: node.priceRangeV2.minVariantPrice.currencyCode,
        url: `https://${SHOPIFY_STORE}/products/${node.handle}`,
        image_url: imageUrl,
      });

      count++;
      console.log(`[${count}] ${node.title}`);
      cursor = c;
    }

    if (!data.data.products.pageInfo.hasNextPage) break;
  }

  console.log(`Done. Synced ${count} products.`);
}

syncAll();

Run it:

SHOPIFY_ACCESS_TOKEN=shpat_xxx VECSTORE_API_KEY=your_key VECSTORE_DB_ID=your_db node sync-catalog.js

This pages through your entire Shopify catalog using GraphQL cursor pagination, grabs the primary image for each product, and inserts it into Vecstore with metadata attached. The metadata is important because it comes back with every search result, so you can render product cards without a second Shopify API call.

We're inserting one image per product (the featured image). If you insert all variant images, your "similar products" results will be flooded with color variants of the same item. One image per product keeps results useful.

Step 2: Build the Search Backend

You need a small backend to sit between your storefront and the Vecstore API. This keeps your API key off the client.

Create server.js:

import express from 'express';
import cors from 'cors';
import multer from 'multer';
import fs from 'fs';

const app = express();
app.use(cors());
app.use(express.json());

const upload = multer({ dest: 'uploads/' });

const API_KEY = process.env.VECSTORE_API_KEY;
const DB_ID = process.env.VECSTORE_DB_ID;
const BASE = 'https://api.vecstore.app/api';
const HEADERS = {
  'X-API-Key': API_KEY,
  'Content-Type': 'application/json',
};

// Text search - "red leather bag", "minimalist desk lamp"
app.post('/api/search/text', async (req, res) => {
  const { query, top_k = 12 } = req.body;

  const result = await fetch(`${BASE}/databases/${DB_ID}/search`, {
    method: 'POST',
    headers: HEADERS,
    body: JSON.stringify({ query, top_k }),
  });

  res.json(await result.json());
});

// Image search - upload a photo, find similar products
app.post('/api/search/image', upload.single('image'), async (req, res) => {
  const base64 = fs.readFileSync(req.file.path, { encoding: 'base64' });

  const result = await fetch(`${BASE}/databases/${DB_ID}/search`, {
    method: 'POST',
    headers: HEADERS,
    body: JSON.stringify({ image: base64, top_k: 12 }),
  });

  fs.unlinkSync(req.file.path);
  res.json(await result.json());
});

// Similar products - given a product image URL, find lookalikes
app.post('/api/similar', async (req, res) => {
  const { image_url, exclude_handle, top_k = 6 } = req.body;

  const result = await fetch(`${BASE}/databases/${DB_ID}/search`, {
    method: 'POST',
    headers: HEADERS,
    body: JSON.stringify({ image_url, top_k: top_k + 1 }),
  });

  const data = await result.json();

  // filter out the current product
  data.results = (data.results || [])
    .filter(r => r.metadata?.handle !== exclude_handle)
    .slice(0, top_k);

  res.json(data);
});

app.listen(3001, () => console.log('Running on 3001'));

Three routes: text search for the search bar, image search for photo uploads, and a similar products endpoint that filters out the current product. The similar products endpoint takes the current product's handle so it can exclude it from results.

Step 3: Add Search to Your Storefront

Now the frontend. There are two ways to get this onto your Shopify store: a theme app extension (the proper way) or a script tag (the quick way). We'll use a script tag because it works on any Shopify theme without building a full Shopify app.

Create a JavaScript file and host it somewhere accessible (your backend, a CDN, wherever). This gets injected into your Shopify theme.

// shopify-search-widget.js

const API_BASE = 'https://your-backend.com';

function createSearchWidget() {
  const container = document.createElement('div');
  container.id = 'vs-search';
  container.innerHTML = `
    <div id="vs-overlay" style="display:none; position:fixed; inset:0;
         background:rgba(0,0,0,0.5); z-index:9999;
         display:none; align-items:center; justify-content:center;">
      <div style="background:white; border-radius:12px; padding:24px;
           width:90%; max-width:640px; max-height:80vh; overflow-y:auto;">
        <div style="display:flex; gap:8px; margin-bottom:16px;">
          <input id="vs-input" type="text"
            placeholder="Describe what you're looking for..."
            style="flex:1; padding:10px 14px; border:1px solid #ddd;
                   border-radius:8px; font-size:15px;" />
          <label style="padding:10px 16px; border:1px solid #ddd;
                 border-radius:8px; cursor:pointer; font-size:14px;">
            Upload photo
            <input id="vs-file" type="file" accept="image/*"
                   style="display:none;" />
          </label>
        </div>
        <div id="vs-results" style="display:grid;
             grid-template-columns:repeat(auto-fill,minmax(140px,1fr));
             gap:12px;"></div>
      </div>
    </div>
  `;

  document.body.appendChild(container);

  const overlay = document.getElementById('vs-overlay');
  const input = document.getElementById('vs-input');
  const fileInput = document.getElementById('vs-file');
  const resultsDiv = document.getElementById('vs-results');

  // close on overlay click
  overlay.addEventListener('click', (e) => {
    if (e.target === overlay) overlay.style.display = 'none';
  });

  // text search on Enter
  let timer;
  input.addEventListener('keyup', (e) => {
    clearTimeout(timer);
    if (e.key === 'Enter') {
      searchByText(input.value);
    }
  });

  // image search on file upload
  fileInput.addEventListener('change', (e) => {
    const file = e.target.files[0];
    if (file) searchByImage(file);
  });

  async function searchByText(query) {
    if (!query.trim()) return;
    resultsDiv.innerHTML = '<p>Searching...</p>';
    const res = await fetch(`${API_BASE}/api/search/text`, {
      method: 'POST',
      headers: { 'Content-Type': 'application/json' },
      body: JSON.stringify({ query }),
    });
    renderResults(await res.json());
  }

  async function searchByImage(file) {
    resultsDiv.innerHTML = '<p>Searching...</p>';
    const formData = new FormData();
    formData.append('image', file);
    const res = await fetch(`${API_BASE}/api/search/image`, {
      method: 'POST',
      body: formData,
    });
    renderResults(await res.json());
  }

  function renderResults(data) {
    const results = data.results || [];
    if (!results.length) {
      resultsDiv.innerHTML = '<p>No results found.</p>';
      return;
    }
    resultsDiv.innerHTML = results.map(r => `
      <a href="${r.metadata.url}" style="text-decoration:none; color:inherit;">
        <img src="${r.metadata.image_url}" alt="${r.metadata.title}"
          style="width:100%; aspect-ratio:1; object-fit:cover;
                 border-radius:8px;" />
        <p style="font-size:13px; margin:6px 0 2px;">${r.metadata.title}</p>
        <p style="font-size:13px; font-weight:600;">
          ${r.metadata.currency} ${r.metadata.price}
        </p>
      </a>
    `).join('');
  }

  return { open: () => { overlay.style.display = 'flex'; input.focus(); } };
}

// Initialize
const searchWidget = createSearchWidget();

// Hook into existing search icon/button on your theme
document.querySelectorAll('[data-vs-trigger]').forEach(el => {
  el.addEventListener('click', (e) => {
    e.preventDefault();
    searchWidget.open();
  });
});

To wire this up, add a data-vs-trigger attribute to any element in your Shopify theme that should open the search modal. Could be the existing search icon, a new button, whatever. When clicked, the modal opens with text input and photo upload.

In your Shopify theme, load the script by adding this to your theme.liquid before </body>:

<script src="https://your-backend.com/shopify-search-widget.js"></script>

Step 4: Add Similar Products to Product Pages

This is where the real money is. A "similar products" section on every product page that actually shows products that look alike, not just products from the same collection.

Add this script to your product page template (or theme.liquid if you want it everywhere):

// similar-products.js

const API_BASE = 'https://your-backend.com';

async function loadSimilarProducts() {
  const container = document.getElementById('vs-similar');
  if (!container) return;

  const imageUrl = container.dataset.image;
  const handle = container.dataset.handle;

  if (!imageUrl || !handle) return;

  const res = await fetch(`${API_BASE}/api/similar`, {
    method: 'POST',
    headers: { 'Content-Type': 'application/json' },
    body: JSON.stringify({
      image_url: imageUrl,
      exclude_handle: handle,
    }),
  });

  const data = await res.json();
  const results = data.results || [];

  if (!results.length) return;

  container.innerHTML = `
    <h3 style="margin-bottom:16px;">You might also like</h3>
    <div style="display:grid;
         grid-template-columns:repeat(auto-fill,minmax(160px,1fr));
         gap:16px;">
      ${results.map(r => `
        <a href="${r.metadata.url}"
           style="text-decoration:none; color:inherit;">
          <img src="${r.metadata.image_url}" alt="${r.metadata.title}"
            style="width:100%; aspect-ratio:1; object-fit:cover;
                   border-radius:8px;" />
          <p style="font-size:13px; margin:8px 0 2px;">
            ${r.metadata.title}
          </p>
          <p style="font-size:13px; font-weight:600;">
            ${r.metadata.currency} ${r.metadata.price}
          </p>
        </a>
      `).join('')}
    </div>
  `;
}

loadSimilarProducts();

In your Shopify product template, add a container where you want the similar products to appear:

<div id="vs-similar"
  data-image="{{ product.featured_image | image_url: width: 800 }}"
  data-handle="{{ product.handle }}">
</div>
<script src="https://your-backend.com/similar-products.js"></script>

Shopify's Liquid template passes the product image URL and handle as data attributes. The script picks them up, calls your backend, and renders the results. If no similar products are found, nothing shows up. No empty sections.

Keeping Your Catalog in Sync

Your Vecstore database needs to stay up to date when you add, update, or remove products in Shopify. Two approaches:

Webhook-based (recommended). Register Shopify webhooks for products/create, products/update, and products/delete. When a product changes, your backend inserts, updates, or removes it from Vecstore automatically.

// handle product create/update webhook
app.post('/webhooks/products', async (req, res) => {
  const product = req.body;
  const imageUrl = product.image?.src;

  if (!imageUrl) return res.sendStatus(200);

  await fetch(`${BASE}/databases/${DB_ID}/documents`, {
    method: 'POST',
    headers: HEADERS,
    body: JSON.stringify({
      image_url: imageUrl,
      metadata: {
        shopify_id: `gid://shopify/Product/${product.id}`,
        title: product.title,
        handle: product.handle,
        price: product.variants[0]?.price,
        url: `https://${SHOPIFY_STORE}/products/${product.handle}`,
        image_url: imageUrl,
      },
    }),
  });

  res.sendStatus(200);
});

Cron-based. Run the sync script from Step 1 on a schedule (daily, hourly, whatever fits your update frequency). Simpler to set up, but there's a lag between product changes and search results updating.

For most stores, webhooks are worth the extra setup. A customer shouldn't search for a product you added an hour ago and get nothing back.

Things to Keep in Mind

Cache similar products. The similar products for a given item don't change unless your catalog changes. Cache the results (even in a simple JSON file or Redis) so you're not hitting the API on every product page view. Refresh when your catalog syncs.

Theme compatibility. The script tag approach works on any Shopify theme. If you want tighter integration (custom blocks in the theme editor, settings panels), build a proper theme app extension instead. More work upfront, better experience for store owners.

Image quality. Shopify's image URLs support size parameters. Use width: 800 or similar when passing image URLs to Vecstore. Bigger doesn't improve search quality, it just slows things down.

Variants. Only index one image per product, not one per variant. If you sell a shirt in 5 colors and index all 5, searching for a blue shirt returns 4 other color variants of the same shirt. Not useful.

Costs. A store with 5,000 products and 30,000 daily product page views: the initial sync costs 5,000 credits, and each similar products query costs 1 credit. With caching, you're looking at the sync cost plus a fraction of the page views. At $1.60 per 1,000 credits, the math works out to a few dollars per month after caching.

What Else You Can Do

Same database, same API key:

Text search that understands meaning, not just keywords. "Cozy winter sweater" matches chunky knits even if none are tagged that way.
NSFW detection if you accept user-uploaded images. Check them before they appear on your site.
Customer photo search for stores with user-generated content. A customer uploads a photo from their home and finds similar products in your catalog.

Wrapping Up

The full setup: a catalog sync script, an Express backend with three routes, and two frontend scripts. One for search, one for similar products. No ML models, no GPU servers, no vector database to manage.

The hardest part is the initial catalog sync. After that, everything runs off a single API call per search query. And the similar products section is the kind of feature that directly moves revenue without requiring any ongoing manual work.

Get started with Vecstore - free tier includes enough credits to sync a small catalog and test search.

Vecstore vs Elasticsearch: Managed Search API vs DIY Search Infrastructure

Giorgi — Mon, 13 Apr 2026 17:27:26 +0000

Elasticsearch gets recommended for almost everything that looks vaguely like search.

Need site search? Elasticsearch. Need semantic search? Elasticsearch has vector search. Need hybrid search? Elasticsearch can do that too. Need something scalable? Also Elasticsearch.

None of that is wrong. Elasticsearch is one of the most capable search engines ever built.

But that recommendation usually skips the part that matters most: Elasticsearch is a search engine you build on top of. Vecstore is a search product you call.

That difference sounds small until you're three weeks into mappings, analyzers, indexing pipelines, shard sizing, and relevance tuning. At that point you're no longer deciding between two APIs. You're deciding whether search is a feature in your product or a system your team now owns.

What Elasticsearch Actually Is

Elasticsearch is infrastructure.

It's a distributed search engine and analytics system. It gives you indexes, mappings, analyzers, BM25 ranking, aggregations, filters, vector fields, kNN search, hybrid retrieval, ingest pipelines, and a huge amount of control over how search behaves.

That flexibility is exactly why so many teams use it. If you want to control tokenization, ranking logic, field boosts, synonym handling, language analyzers, aggregations, and deployment shape, Elasticsearch gives you all of that.

It also means you are assembling the search experience yourself.

Even on Elastic Cloud, where the cluster management burden is lower, you're still making search-engine-level decisions:

How documents are indexed
Which fields get keyword search versus semantic search
How lexical and vector results get combined
Which analyzers and filters you need
How mappings evolve when your schema changes

That is excellent if you want control. It is expensive if you just want search to work.

What Vecstore Actually Is

Vecstore is a managed search API.

You create a database, send in your text or images, and search them. Embeddings, indexing, multimodal retrieval, OCR search, face search, and NSFW detection are handled for you. You are not stitching together a search engine, a model provider, a queue, and a second storage layer just to return one search result.

That changes the whole shape of the project.

With Vecstore, search is an API integration. With Elasticsearch, search is usually a subsystem.

That doesn't make Elasticsearch worse. It makes it a different category of tool.

Where Teams Underestimate Elasticsearch

Most teams don't underestimate Elasticsearch because they think it is weak. They underestimate it because they think they are buying search, when they are really buying control plus responsibility.

Index design becomes product work. Before search feels good to users, you have to decide what gets indexed, how fields are mapped, which analyzers are used, what should be boosted, what should be filterable, and how query parsing should behave. None of this is fake complexity. It is real work that somebody has to own.

Schema changes are not casual. In a normal application database, adding a field is usually boring. In Elasticsearch, changes to mappings can force reindexing. On a large corpus, that is not a small detail. It affects rollout plans, backfills, and operational risk.

Relevance tuning never really ends. Search quality in Elasticsearch is rarely bad because the engine is incapable. It is bad because ranking requires iteration. You tune boosts, analyzers, synonyms, typo behavior, field weights, filters, and sometimes custom scoring. This is where a lot of time goes.

Semantic search adds another layer, not less work. Elasticsearch absolutely supports vector search and hybrid search. But once you move beyond classic keyword search, the number of decisions increases. You now care about chunking, embeddings, vector fields, retrieval strategy, score blending, latency tradeoffs, and model quality.

Someone becomes the Elasticsearch person. It might be a backend engineer, a platform engineer, or the founder at midnight. But once Elasticsearch matters to the product, somebody owns cluster health, indexing performance, search regressions, and operational surprises.

This is normal for infrastructure. It is just very different from consuming a finished API.

Semantic Search in Elasticsearch Is Real. It Is Still Elasticsearch.

This is where comparison posts often get sloppy, so it's worth being precise.

Elasticsearch is not "just keyword search" anymore. Elastic supports dense vectors, kNN retrieval, hybrid search, and semantic features. If you want to build modern retrieval on Elastic, you can.

The question is not whether it can be done. The question is how much of the system you want to own.

If your team likes controlling every layer, Elasticsearch is compelling. You can shape the ranking stack exactly how you want. You can combine lexical signals, metadata filters, behavioral features, recency, vector scores, and business logic into one retrieval pipeline.

If your team does not want that job, the same flexibility becomes drag.

Vecstore takes the opposite position. You do not manage embeddings. You do not design vector schemas. You do not wire together lexical and semantic retrieval manually. You do not spend time deciding which model should be attached to which field. You send the data in and search it.

That tradeoff is the whole product.

The Image Search Gap Is Bigger Than It Looks

This is the part where the difference between the two products becomes obvious.

Elasticsearch can store vectors for images if you generate those vectors yourself. That means image search is possible. But nothing about the workflow is native. You need the model, the embedding pipeline, the indexing logic, the metadata strategy, and the query flow.

If you need reverse image search, text-to-image search, OCR search, face search, or content moderation, Elasticsearch is not giving you a finished feature. It is giving you a place to store and query whatever representation you build.

Vecstore already behaves like an image search product. Upload an image, search by image, search by text, search the text inside the image, moderate the image, or find matching faces. The infrastructure question is already answered.

For teams building visual search, that difference is not academic. It is months of engineering.

Where Elasticsearch Is the Right Choice

Elasticsearch is the right choice more often than some comparison pages admit.

You already run Elastic. If your team already has Elastic in production for logs, observability, or existing site search, extending that investment may be rational. You already understand the operational model, and adding one more index is not the same as introducing a brand new system.

You need heavy filtering and aggregations. Elasticsearch is excellent when search is tightly tied to faceting, nested filters, aggregations, and structured exploration. Product catalogs, analytics-heavy UIs, and enterprise search interfaces often need this level of control.

You want maximum ranking control. If you care deeply about analyzers, tokenization, field-level relevance, custom scoring scripts, and ranking experimentation, Elasticsearch gives you room to build exactly what you want.

Your primary use case is not just product search. Elastic shines in observability, security analytics, log search, and other workloads that Vecstore is not trying to replace. If search is only one part of a broader Elastic footprint, the decision changes.

Elasticsearch is powerful because it is broad. That breadth is real value.

Where Vecstore Is the Better Fit

Vecstore is the better fit when you do not want search to become a platform project.

You need semantic search without building the stack around it. Users should be able to type what they mean and get useful results back. Not after a month of tuning. Immediately.

You need image search as an actual feature, not a research project. Reverse image search, text-to-image search, OCR search, face search, and moderation are all things teams ask for once they start handling media. On Elasticsearch, each of those starts with "first, let's build a pipeline." On Vecstore, they start with an API call.

You do not have a dedicated search team. Most startups and product teams do not have spare engineering capacity for search infrastructure. They have product work to ship. In that environment, "finished API" is not a luxury. It is the practical choice.

You want one system, not a chain of systems. Elasticsearch-based semantic search often means combining your application database, Elastic, and one or more model or ingestion services. Vecstore collapses that stack.

The value proposition is not philosophical. It is less surface area, fewer moving parts, and faster time to a working feature.

Side-by-Side

	Vecstore	Elasticsearch
What it is	Managed search API	Search engine and analytics platform
Main experience	Send data, search it	Design, tune, and run a search system
Keyword search	Built in as part of hybrid search	Excellent
Semantic search	Built in	Supported, but configurable and infrastructure-heavy
Hybrid search	Built in	Supported, but you decide how to combine signals
Image search	Native workflows	Possible with your own models and pipelines
OCR search	Built in	Build it yourself
Face search	Built in	Build it yourself
Content moderation	Built in	Separate service required
Multilingual	Works out of the box	Depends on analyzers, models, and setup
Relevance tuning	Minimal	Ongoing responsibility
Infrastructure overhead	Low	Medium to high, depending on setup
Best for	Teams that want search shipped fast	Teams that want control and already know Elastic

The Real Decision

The easiest way to think about this is not "which one is more powerful?"

Elasticsearch is more powerful in the raw sense. It gives you more knobs, more architecture choices, more ways to shape retrieval, and more ways to integrate search into a larger infrastructure stack.

The more useful question is this: do you want control badly enough to own the consequences of that control?

If the answer is yes, Elasticsearch is a serious option.

If the answer is no, and what you actually need is semantic search, image search, multilingual retrieval, or moderation to work inside your product without turning into a platform effort, Vecstore is the better fit.

One is a search engine.

The other is search, already turned into a product.

See the full comparison or try Vecstore free.

You Don't Need a Vector Database

Giorgi — Sun, 12 Apr 2026 15:17:55 +0000

Somewhere in the last two years, "we need a vector database" became the default answer to every search problem. Team wants better product search? Vector database. Building a recommendation engine? Vector database. Need to search images? Vector database.

The reasoning usually goes like this: traditional keyword search isn't good enough, semantic search uses vectors, therefore we need a vector database. It sounds logical. But it skips a pretty important question.

Do you actually need a database, or do you just need search that understands what your users mean?

What a Vector Database Actually Is

A vector database stores and indexes vectors (arrays of numbers that represent the meaning of text, images, or other data). You give it vectors, it stores them, and when you query it with another vector, it finds the most similar ones.

That's it. That's the whole product.

It doesn't generate those vectors for you. It doesn't understand your data. It doesn't know what "affordable hiking boots" means. It just stores numbers and does math to find which stored numbers are closest to your query numbers.

To make a vector database useful, you need to build everything around it:

An embedding pipeline that converts your data into vectors
A way to keep vectors in sync when your source data changes
A separate database for your actual data (a vector database stores vectors and limited metadata, not your full records)
Query resolution logic that takes vector IDs back to your primary database
Model selection, tuning, and eventual migration when better models come out

A vector database is a storage layer. It's an important component in certain architectures. But it's a component, not a solution.

The Problem With Starting From Infrastructure

When you start with "we need a vector database," you're starting from infrastructure and working backwards toward the product. That's backwards.

Here's what usually happens. A team decides they need better search. They research vector databases. They pick one. They spend two weeks setting it up, choosing an embedding model, building the ingestion pipeline, and writing the sync logic. They get a prototype working. The results are okay but not great. They realize they need to try a different embedding model. They re-embed everything. The results are better. Then they discover their sync pipeline has a bug and 15% of their vectors are stale. They fix it. A month has passed and they have... search that mostly works.

Compare that to: call a search API, get results. Done in an afternoon.

The vector database approach isn't wrong. It's just overkill for what most teams actually need. The majority of developers searching for "vector database" don't want to operate a vector database. They want their search to understand natural language. Those are very different things.

Who Actually Needs a Vector Database

There are legitimate use cases where a raw vector database is the right call. They all share a common pattern: the team needs control over the vector layer specifically.

ML teams building custom retrieval systems. If you have ML engineers who need to experiment with different embedding models, fine-tune them on your domain data, and control how vectors are generated and stored, a vector database is the right component. You're building a custom system and you need a storage layer that fits into it.

RAG pipelines with specific requirements. If you're building retrieval-augmented generation for an LLM and you need control over chunking strategies, embedding dimensions, retrieval scoring, and re-ranking, the flexibility of a raw vector index matters. You have opinions about every layer of the stack and you want to control each one.

Research and experimentation. If you're benchmarking embedding models, testing different similarity metrics, or building something novel, you want direct access to the vector operations. You're not building a product. You're building the thing that goes inside a product.

The common thread: these teams have ML expertise and they want a component, not a finished product.

Who Doesn't Need One (Most People)

If you're building any of the following, you almost certainly don't need a vector database:

Product search. Your users type "warm jacket for camping" and you want to show insulated outdoor jackets even if no product has those exact words. You need semantic search, not a vector database. The difference: semantic search is the result you want. A vector database is one possible way to build it, and the most complicated one.

Content discovery. Your blog, documentation, or knowledge base needs search that understands questions, not just keywords. "How do I reset my password" should match a help article titled "Account recovery steps." Again, this is a search quality problem, not an infrastructure problem.

Image search. Your users want to search by uploading a photo, describing what they're looking for, or finding text inside images. Building this on a vector database means bringing your own CLIP model, running inference, building an ingestion pipeline, and maintaining it all. Or you could use a search API that handles images natively.

Multilingual search. Your users search in Japanese, Arabic, German, Spanish. With a vector database, the quality of multilingual search depends entirely on which embedding model you chose and how well it handles each language. That's a bet you're making without easy visibility into the results. With a purpose-built search API, multilingual support is handled internally and tested across languages.

Any search feature where you just need it to work. If search is a feature in your product rather than the core product itself, spending weeks on vector infrastructure is time that doesn't go toward your actual product.

The Build Trap

There's a specific trap that developer teams fall into with vector databases, and it's worth calling out directly.

Vector databases feel like building. You're setting up infrastructure, writing pipelines, choosing models, tuning parameters. It feels productive. It feels like engineering. And developers like building things.

But the question isn't "can we build this?" It's "should we?"

Building a search stack from a vector database is like building a car from an engine. Yes, the engine is the hard part. But you still need the transmission, the frame, the wheels, the steering, and a few thousand other things before anyone can drive it. The engine alone doesn't get you anywhere.

A vector database is the engine. The embedding pipeline, sync layer, query resolution, model management, and operational monitoring are everything else. Some teams enjoy building all of that. Most teams would rather just have a car.

What the Alternative Looks Like

Instead of assembling search from components, you can use a search API that handles the entire stack.

With Vecstore, the workflow is:

Create a database
Insert your data (text, images, or both)
Call the search endpoint

There's no embedding model to choose. No vectors to generate or sync. No separate database for your source data. No pipeline to build or maintain. You send in your data and search it. Vecstore handles embedding generation, indexing, retrieval, and ranking internally.

This also means you're not locked to a specific embedding model. When better models come out, Vecstore upgrades internally. You don't re-embed millions of records. You don't even know it happened. Your search just gets better.

And because everything runs through one API, you get text search, image search (reverse image, text-to-image, face search, OCR), multilingual search across 100+ languages, and NSFW detection across 52 categories. All from the same endpoint, the same database, the same API key.

Try getting all of that from a vector database. You'd need a vector DB, an embedding API, a CLIP model, an OCR service, an NSFW detection service, and a primary database to hold your actual data. Six services, six bills, six things that can break.

"But What About Vendor Lock-in?"

Fair concern. Using any managed service means depending on that service. But consider what lock-in actually looks like with each approach.

With a vector database, your lock-in is deep. Your data lives in your primary database, your vectors live in the vector DB, and your embedding pipeline glues them together. If you want to switch vector databases, you need to re-embed everything and rebuild the integration. If you want to switch embedding models, you need to re-embed everything. Your architecture is coupled to three different services.

With a search API like Vecstore, your data and search live in one place. If you ever want to leave, you export your data and point your API calls at a different service. One integration to replace, not three.

Neither option is as portable as self-hosted open source. If zero vendor dependency is your top priority, look at Qdrant or Milvus and be prepared to operate them. But if you're choosing between managed services, the simpler architecture is actually easier to migrate away from.

Making the Decision

Here's a simple framework.

Choose a vector database if:

You have ML engineers who need control over embedding models
You're building a custom retrieval pipeline for an LLM
You need to experiment with different models and similarity metrics
Vector operations are a core part of your product's value

Choose a search API if:

You need search to work in your product, but search isn't the product
You don't have ML engineers (or your ML engineers have better things to do)
You want text, image, and multilingual search without managing separate systems
Time to launch matters more than customization of the vector layer

Most teams fall into the second category. They don't need a vector database. They need search that works.

Try Vecstore free or explore the API docs.

What It Costs to Search 1M Images in Production

Giorgi — Sun, 12 Apr 2026 15:17:18 +0000

Image search looks simple until you start building it. It's actually five or six separate infrastructure problems, each with its own monthly bill. This post prices out every piece for a real production workload: 1M images, thousands of users, enterprise-level traffic. One person can build it, but you should know what the bill looks like first.

How Image Search Works

At insert time: your backend receives an image, stores it in S3, runs it through a vision model (CLIP, OpenCLIP, SigLIP) to get a vector (an array of 768-1024 numbers representing what the image "means"), and stores that vector in a vector database alongside metadata.

At search time: the user's query (text or image) gets embedded by the same model, sent to the vector database, which returns the closest matching vector IDs. Your backend resolves those IDs to actual image URLs and returns results.

That's the pipeline.

Part 1: GPU Inference

This is where most of the money goes. You need a GPU running a vision model to convert images into vectors, both at insert time and search time.

Choosing a Model

The main options are CLIP ViT-B/32 (fast, lower quality), CLIP ViT-L/14 (solid middle ground), OpenCLIP ViT-H/14 (best open-source quality), and SigLIP SO400M (newest, highest accuracy, slower).

Most people go with OpenCLIP ViT-H/14: 1024-dimensional vectors, 50-100 img/s on an A10G GPU. We'll use that for all calculations.

GPU Instances (AWS)

Instance	GPU	Hourly	Monthly
g6.xlarge	1x L4 (24GB)	$0.81	$588
g5.xlarge	1x A10G (24GB)	$1.01	$734
g5.2xlarge	1x A10G (24GB)	$1.21	$885
p3.2xlarge	1x V100 (16GB)	$3.06	$2,234

The g6.xlarge is the best value. Runs OpenCLIP ViT-H/14 at 50-100 images per second.

CPU? No.

OpenCLIP ViT-H/14 on CPU: 0.2-0.5 images per second. One image every 2-5 seconds. With 10 concurrent searches, users wait 20-50 seconds each. Embedding 1M images would take 23-58 days on CPU vs 3-6 hours on GPU.

Spot Instances

Spot cuts GPU costs by 60-70% (g6.xlarge drops to ~$175-235/month). Great for batch embedding. Risky for live search since AWS can terminate with 2 minutes notice.

Concurrency and Enterprise Traffic

50-100 img/s on a single GPU sounds like plenty if you're thinking about a side project. It's not plenty at enterprise scale.

Say your app has 50,000 daily active users, each doing a few searches. That's maybe 200,000-500,000 searches per day. Spread evenly, that's 3-6 queries per second. One GPU handles that fine.

But traffic is never spread evenly. During peak hours (maybe 2-3 hours per day), you might see 20-50 queries per second. If you also have sellers or users uploading new images during those same hours, uploads and searches compete for the same GPU. A spike in uploads tanks your search latency.

At this scale, you realistically need 2 GPU instances: one dedicated to serving search queries, one for processing new uploads and batch work. During peak traffic, you might even want a third.

And this is just 1M images. Enterprise catalogs at 10M+ images with global traffic need even more. The GPU bill scales linearly with query volume.

Scenario	Setup	Monthly Cost
Low traffic	1x g6.xlarge	$588
Medium traffic	2x g6.xlarge	$1,176
High traffic	3x g6.xlarge	$1,764
Batch processing (spot)	1x g6.xlarge spot	+$175-235

Part 2: Vector Storage

1M vectors x 1024 dimensions x 4 bytes = 4.1 GB raw. With metadata and indexes, roughly 5-10 GB.

These prices are for 1M vectors. At 10M vectors, the storage costs go up but the real pain is query latency. HNSW indexes get slower as they grow, and you'll likely need to bump your instance sizes or shard across multiple databases. That's when Pinecone and Qdrant start earning their price because they handle that scaling for you.

Part 3: Image Storage and Delivery

1M images at ~500KB each = 500 GB.

Service	Monthly Cost
S3 (500 GB)	$11.50
CloudFront CDN	$0-15 (1 TB free tier is permanent)
Total	$11.50-26.50

S3 is cheap. This isn't the part of the bill that surprises you. Though at enterprise scale with heavy traffic, CloudFront costs can climb. If you're serving 5 TB/month in images, that's ~$425/month in CDN transfer alone.

Part 4: Backend

The backend mostly routes requests between the GPU and the vector database. It doesn't need to be beefy.

We went with Rust for ours because the memory efficiency and concurrency model means fewer instances. A single Rust server saturates its network before it runs out of CPU. The tradeoff is development speed, but for a service that's mostly routing requests, it's worth it. Most people use Python with FastAPI here, which works fine too. One developer can set either of these up in a day or two.

A t3.small ($15/month) with auto scaling handles this. Set minimum 2 instances behind an ALB so you're never down during deployments, and let it scale up during traffic spikes.

For enterprise traffic (thousands of concurrent users), you'll see the auto scaling group regularly running 4-6 instances during peak. Budget accordingly.

Scenario	Instances	Monthly Cost
Low traffic	2x t3.small + ALB	$57
Medium traffic	4x avg + ALB	$90
Enterprise	6x avg + ALB	$120

Part 5: Embedding 1M Images

Before search works, you embed every image. 1M images through OpenCLIP ViT-H/14 on a g6.xlarge:

Time: ~3.7 hours
Cost: ~$3.00 (under $1 on spot)

The compute is cheap. The bottleneck is I/O. If you process images one at a time, the GPU sits idle waiting for downloads between each inference.

Python with asyncio and aiohttp solves this. Download images in batches of 100-200 concurrently, feed each batch to the GPU, batch-insert vectors into your database. This keeps the GPU busy. Without async batching, the same 3.7-hour job takes 12+ hours.

Good weekend project. Set up the async pipeline, kick off the batch, go do something else while it runs. Just don't run it through your production backend. Spin up a dedicated instance for the initial load.

The Full Bill

Two scenarios: a moderate-traffic app and an enterprise workload.

$740/month for moderate traffic (~100K searches/day). One GPU instance, Pinecone for vectors, small auto-scaling backend. The GPU eats 80% of the budget.

At enterprise scale (~500K+ searches/day), the bill jumps to $1,845/month. The GPU cost more than doubles (you need 2 instances plus a spot instance for batch work), and you're adding monitoring, more CDN bandwidth, and a beefier backend.

What's Not Included

Your time. This is totally buildable by one developer. The pipeline, the GPU setup, the vector database, the backend, all of it. Expect 2-4 weeks for the initial build if you're doing it solo. The ongoing maintenance is the real time sink: model upgrades mean re-embedding everything, traffic spikes mean debugging capacity issues, and things will break at inconvenient times.

Scaling beyond 1M. At 10M images, you're looking at roughly 3-5x these costs. GPU inference scales linearly, vector database costs go up, and the backend needs more capacity. The architecture stays the same but everything gets bigger.

Is It Worth It?

$740/month for moderate traffic is very doable, even for a solo developer. You can build this over a few weekends, it's well-documented technology, and the architecture is straightforward.

At enterprise scale ($1,845/month and up), it's still reasonable if image search is a core part of your product. That's less than the cost of one engineer's monthly salary, and you're getting a real production system.

Where it starts to hurt is the time. Not the building, the maintaining. Every CLIP model update, every scaling event, every outage. That's the ongoing tax. Whether you're fine paying that tax depends on how central image search is to what you're building.

Either way, now you know what the bill looks like.

What Is a Vector Database (And Do You Actually Need One)?

Giorgi — Sun, 12 Apr 2026 15:16:42 +0000

Every few years, a new type of database shows up and suddenly it's "the answer" to everything. Graph databases had their moment. Time-series databases had theirs. Right now, vector databases are in the spotlight—and unlike some hype cycles, this one is grounded in a real shift in how applications handle data.

But "what is a vector database" is a surprisingly loaded question. The short answer: it's a database optimized for storing and searching high-dimensional vectors. The longer answer involves understanding what vectors are, why traditional databases can't handle them well, and—critically—whether you actually need one for your use case.

Vectors and Embeddings: What They Actually Are

A vector embedding is a list of numbers that represents the meaning of a piece of data. Text, images, audio—any unstructured data can be converted into an embedding using a neural network (an embedding model).

Take the sentence "how to train a puppy." An embedding model might convert that into a vector of 768 floating-point numbers. The sentence "tips for teaching a young dog" would produce a different list of numbers, but one that's geometrically close to the first—because the meanings are similar.

This is the key insight: similar meanings produce similar vectors. The distance between two vectors in this high-dimensional space reflects how related their source data is. A sentence about puppy training and a sentence about dog obedience land near each other. A sentence about tax law lands far away.

The same principle applies to images. A photo of a golden retriever and a photo of a labrador produce embeddings that are close together. A photo of a skyscraper does not.

These vectors typically have 256 to 1,536 dimensions, depending on the model. That's where things get computationally interesting.

What a Vector Database Does Differently

A traditional relational database is built for exact matches. You query for rows where a column equals a value, falls within a range, or matches a pattern. The data structures behind this—B-trees, hash indexes—are optimized for precise lookups.

Vector databases solve a fundamentally different problem: vector similarity search. Given a query vector, find the most similar vectors in a collection of millions or billions. This isn't an exact match—it's a nearest-neighbor search in high-dimensional space.

Why can't you just use PostgreSQL with a vector column and calculate cosine similarity? You can, for small datasets. But brute-force comparison against every vector in a table scales linearly. At 10 million vectors with 768 dimensions each, you're comparing against ~7.6 billion floating-point numbers per query. That's seconds, not milliseconds.

Vector databases use approximate nearest neighbor (ANN) algorithms to make this tractable. They trade a small amount of accuracy—maybe returning the 95th-percentile best match instead of the absolute best—for orders-of-magnitude speed improvements. A well-tuned ANN index can search through 100 million vectors in under 10 milliseconds.

How Vector Search Works, Step by Step

Here's the full pipeline, with a vector database explained as a sequence of operations:

1. Embed your data. Run each document, image, or data point through an embedding model. This produces a vector for each item. For a catalog of 1 million products, you'd generate 1 million vectors.

2. Index the vectors. The vector database ingests these vectors and builds an index—a data structure that organizes them for fast similarity lookup. This is the expensive step. Depending on the algorithm, indexing 1 million 768-dimensional vectors might take minutes to hours.

3. Query. When a user searches, their query is embedded using the same model, producing a query vector. The database searches its index for the nearest neighbors to that query vector.

4. Rank and return. The database returns the top-K most similar vectors, along with their similarity scores and any metadata you stored alongside them. Your application uses these results to show search results, recommendations, or whatever the use case requires.

How Indexing Algorithms Make It Fast

The indexing layer is where vector databases earn their keep. Three families of algorithms dominate:

HNSW (Hierarchical Navigable Small World) builds a multi-layered graph where each node connects to its nearest neighbors. Searching is like navigating a skip list—you start at the top layer with long-range connections and drill down to finer layers. HNSW offers excellent query speed (sub-millisecond for millions of vectors) and high recall, but it requires the entire index to fit in memory. For 100 million 768-dimensional vectors stored as float32, that's roughly 300 GB of RAM.

IVF (Inverted File Index) partitions the vector space into clusters using k-means. At query time, it only searches the clusters closest to the query vector, skipping the rest. IVF uses less memory than HNSW and works well with disk-based storage, but recall degrades if you search too few clusters.

PQ (Product Quantization) compresses vectors by splitting them into sub-vectors and quantizing each sub-vector to its nearest centroid in a learned codebook. This dramatically reduces memory—a 768-dimensional float32 vector (3,072 bytes) can be compressed to 96 bytes. The trade-off is lower accuracy, especially for fine-grained similarity.

In practice, production systems often combine these. IVF+PQ is common for billion-scale datasets where memory is a constraint. HNSW alone works well up to tens of millions of vectors if you have the RAM.

Real Use Cases

The reason vector databases have gotten so much attention is that semantic search and related workloads are showing up everywhere:

Semantic search — Search by meaning instead of keywords. A query for "affordable flights to warm destinations" finds results about "cheap tickets to tropical locations." This is the most common use case and the one driving most adoption.
RAG (Retrieval-Augmented Generation) — LLM applications retrieve relevant context from a vector database before generating a response. This is how most production chatbots and AI assistants ground their answers in real data instead of hallucinating.
Recommendation engines — Embed users and items into the same vector space, then recommend items whose vectors are closest to a user's vector. Spotify and YouTube use variations of this approach at massive scale.
Image search — Embed images and text into a shared space (using models like CLIP) so users can search photos with natural language or find visually similar images.
Anomaly detection — In fraud detection or security monitoring, normal behavior forms clusters in vector space. Data points far from any cluster are flagged as anomalies.

When You DON'T Need a Vector Database

Here's where the industry conversation often goes sideways. Not every application needs a dedicated vector database. Consider skipping one if:

Your data is small. If you have fewer than 100,000 vectors, brute-force search with a library like FAISS or even NumPy is fast enough. You can keep everything in memory on a single machine and get sub-50ms query times without any indexing at all.

You need exact keyword matching. Vector search is fuzzy by nature. If your users search for SKUs, error codes, or legal citations, you need traditional full-text search (Elasticsearch, PostgreSQL), not approximate nearest neighbors.

You don't want to manage embeddings. Running embedding models, building ingestion pipelines, choosing indexing parameters, tuning recall vs. latency—this is real operational overhead. If search is a feature of your product (not the product), that overhead may not be worth it.

pgvector is enough for your scale. PostgreSQL's pgvector extension supports HNSW indexing and handles millions of vectors reasonably well. If you're already running Postgres and your dataset is under 5–10 million vectors, adding a vector column might be all you need. No new infrastructure required.

The Options Landscape

When you do need vector search, you have a spectrum of options:

Self-hosted databases like Milvus, Qdrant, and Weaviate give you full control. You manage deployment, scaling, backups, and tuning. This makes sense when you have strict data residency requirements, need to customize the indexing pipeline, or have a team comfortable with infrastructure operations.

Managed vector databases like Pinecone, managed Weaviate, or Zilliz Cloud handle the infrastructure for you. You get an API, they manage the clusters. Pricing is typically based on storage and queries—expect $70–300/month for a moderately sized workload.

Skip the database entirely. If what you actually need is semantic search or image search in your application, you don't necessarily need to manage vectors at all. Search APIs like Vecstore handle embedding generation, vector storage, and retrieval behind a single REST API—three endpoints, sub-200ms responses, 100+ languages. You send text or images, you get ranked results back. No models to run, no indexes to tune.

This last option is worth considering honestly. A vector database is a means to an end. If the end is "my users need good search," the question isn't "which vector database should I use" but "what's the simplest way to ship this."

Choosing the Right Approach

The decision comes down to how central vector search is to your product:

Scenario	Recommended approach
Search is a feature, not the product	Managed search API
5M+ vectors, need full control	Self-hosted vector DB
Already on Postgres, moderate scale	pgvector extension
Building a RAG pipeline for an LLM app	Managed vector DB or search API
Research or prototyping	FAISS or in-memory brute force

When to use a vector database is ultimately a question of scale, control, and how much infrastructure you're willing to own. For a lot of teams, the answer is less infrastructure than they think.

The Bottom Line

Vector databases are a genuinely useful technology solving a real problem: fast similarity search over high-dimensional data. They're not magic, and they're not always necessary. Understanding the mechanics—embeddings, ANN algorithms, indexing trade-offs—helps you make a clear-eyed decision about whether you need one, and if so, which kind.

Start with the problem, not the technology. If your problem is "users need to search by meaning," you have options ranging from a Postgres extension to a fully managed search API. Pick the one that matches your team's capacity and your application's actual requirements.

Vecstore vs Pinecone: When You Don't Need a Raw Vector Database

Giorgi — Sun, 12 Apr 2026 15:16:06 +0000

Pinecone is usually the first name that comes up when someone starts looking into vector search. It raised $100M, it has a big brand, and for a while it was the only real managed option in the space. If you needed to store and query vectors, Pinecone was the answer.

But here's the thing most teams figure out three months in: storing and querying vectors is not the same as having search that works.

Pinecone is a vector index. You bring your own embeddings, push them in, and query by similarity. That's it. Everything else, the embedding pipeline, the data syncing, the actual search experience, is on you.

Vecstore takes a different approach. You send in your data (text, images, whatever) and get working search back. No embedding step, no pipeline, no second database to keep in sync.

These are fundamentally different products solving different problems. And picking the wrong one costs you months.

What Pinecone Actually Is

Pinecone is a managed vector index. That sounds simple, but it's worth understanding what it means in practice.

When you use Pinecone, your workflow looks like this:

You store your actual data somewhere else (Postgres, DynamoDB, wherever)
You generate embeddings for that data using a separate service (OpenAI, Cohere, a self-hosted model)
You push those embeddings into Pinecone along with some metadata (capped at 40KB per vector)
At query time, you generate an embedding for the search query using the same model
Pinecone returns the closest vector IDs
You take those IDs back to your primary database to fetch the actual records

That's a minimum of three services for one search query: your database, your embedding API, and Pinecone. And you're responsible for keeping all three in sync.

If your source data changes, you need to re-embed and re-upsert into Pinecone yourself. There's no built-in sync mechanism. If your embedding model gets updated, you need to re-embed everything. If Pinecone's metadata limit doesn't cover your use case, you're making extra round-trips to your primary database on every single query.

This is fine if you're building something custom where you need full control over every layer. Some teams genuinely need that. But most teams building product search, content discovery, or recommendation features don't.

What Vecstore Actually Is

Vecstore is a search API. You send in your data and search it. That's the whole workflow.

There's no embedding step you manage. No second database. No pipeline to build. You create a database, insert your records (text, images, or both), and call the search endpoint. Vecstore handles embedding generation, indexing, and retrieval internally.

A search query hits one endpoint and returns results. Not vector IDs that you then resolve against another database. Actual results.

This also means you're not locked into a specific embedding model or responsible for migrating when better models come out. That's handled on Vecstore's side.

The Hidden Cost of "Just a Vector Index"

The pitch for Pinecone sounds lean: "We'll store your vectors and make them searchable." But in practice, the surrounding infrastructure adds up fast.

Here's what a typical Pinecone-based search stack actually requires:

Embedding generation. You need an API or a self-hosted model to convert your data into vectors. OpenAI's embedding API charges per token. Running your own model means GPU instances. Either way, it's an additional cost and an additional point of failure.

A primary database. Pinecone doesn't replace your database. It sits alongside it. You're still paying for and maintaining your primary data store. And you're building the glue code that keeps them in sync.

Sync infrastructure. When a record is created, updated, or deleted in your primary database, you need a process that re-embeds and upserts into Pinecone. This is usually a queue, a worker, and a monitoring setup. It's not complicated, but it's one more thing that can break at 2 AM.

Query resolution. Pinecone returns vector IDs with limited metadata. For most use cases, that means a second database query on every search to fetch the actual content. This adds latency and complexity.

Teams that start with Pinecone often estimate integration at a few days. The embedding pipeline, sync layer, and query resolution layer tend to push that into weeks. And ongoing maintenance is a permanent tax on engineering time.

With Vecstore, you skip all of this. One API, one data store, one bill. Insert your data, call the search endpoint. The infrastructure question is answered.

Where Pinecone Makes Sense

Pinecone isn't the wrong choice for every project. There are legitimate use cases where a raw vector index is what you want.

Custom ML pipelines. If you're a team with ML engineers who need control over embedding models, fine-tuning, and vector operations, a raw index makes sense. You probably have opinions about which model to use and want to swap them freely.

RAG for LLMs. If you're building a retrieval-augmented generation pipeline where you need tight control over chunking strategies, embedding dimensions, and retrieval scoring, Pinecone gives you that control.

Research and experimentation. If you're testing different embedding models or building a novel retrieval system, the flexibility of a raw vector index is useful. You're not looking for a finished product. You're building one.

The common thread is that these teams already have ML infrastructure and expertise. Pinecone is a component they plug into a larger system they own.

Where Vecstore Makes Sense

Vecstore is built for teams that need search to work, not teams that want to build search infrastructure.

Product search. Your e-commerce app needs users to find products by describing what they want. "Warm jacket for hiking" should return insulated outdoor jackets even if no product is titled that way. You need this to work out of the box, not after building an embedding pipeline.

Image search. You need reverse image search, text-to-image search, OCR search, or face search. Pinecone has no image understanding. You'd need to bring your own CLIP model, run inference, and push those vectors in. With Vecstore, you upload the image and search it.

Multilingual search. Your users search in Japanese, Korean, German, Spanish. Vecstore handles 100+ languages natively from a single index. With Pinecone, multilingual quality depends entirely on whichever embedding model you chose, and you're responsible for evaluating that.

Content moderation. Your platform accepts user-uploaded images and you need NSFW detection. Vecstore includes this across 52 categories. With Pinecone, content moderation is a completely separate problem you solve with a completely separate service.

Small to mid-size teams. If you don't have ML engineers on staff, building and maintaining an embedding pipeline is a distraction from your actual product. Vecstore removes that entire category of work.

Side-by-Side Comparison

	Vecstore	Pinecone
What it is	Search API	Vector index
Embedding generation	Handled for you	Bring your own
Data storage	Built-in	Requires separate database
Image search	Native (reverse, text-to-image, face, OCR)	Not available (BYO model)
Text search	Semantic + hybrid	Vector similarity only
Multilingual	100+ languages, one index	Depends on your embedding model
NSFW detection	52 categories built-in	Not available
Data sync	Not needed (single source)	Your responsibility
Metadata limit	None	40KB per vector
Query result	Full records	Vector IDs + limited metadata
Minimum cost	Free tier available	$50/month (Standard)
Setup time	Minutes	Days to weeks (with pipeline)

The Pricing Reality

Pinecone's free tier is limited to 2GB of storage and restricted to US regions. After that, the Standard plan starts at $50/month with read units at $16 per million and storage at $0.33/GB. But that's just the Pinecone bill. You also pay for your embedding API, your primary database, and whatever compute runs your sync pipeline.

Vecstore starts with free credits on signup. After that, it's $1.60 per 1K operations. One bill, one service. No separate embedding costs, no second database to provision.

For a team running a million searches a month, the total cost difference between a Pinecone-based stack (Pinecone + embedding API + primary database + sync infrastructure) and Vecstore tends to be significant. Not because Pinecone itself is expensive, but because everything around it adds up.

The Vendor Lock-In Question

This is worth addressing directly because it comes up a lot.

Pinecone is closed-source. There is no self-hosted production option. "Pinecone Local" exists for testing, but it's an in-memory emulator, not a production deployment. You're fully dependent on Pinecone's infrastructure, pricing decisions, and roadmap.

Vecstore is also a managed service. You're trusting a vendor either way. The difference is that with Vecstore, your data and your search live in one place. With Pinecone, your data lives in your database and your vectors live in Pinecone. If you ever want to move off Pinecone, you need to re-architect your entire search pipeline. With Vecstore, you swap one API for another.

Neither option gives you the portability of self-hosted open source. If that's your priority, look at Qdrant or Milvus. But if you're choosing between managed services, the migration path matters.

The Bottom Line

Pinecone is a solid vector index for teams that are building custom ML systems and want a managed place to store and query their vectors. It's a component, not a finished product.

Vecstore is a finished search product for teams that need search to work today. Text search, image search, multilingual, content moderation, all from one API. No embedding pipelines, no sync layers, no second database.

The question to ask isn't "which vector database should I use?" It's "do I need a vector database at all, or do I just need search that works?"

For most teams, it's the second one.

Try Vecstore free or explore the API docs.