DEV Community: Giorgi

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.

Vecstore vs Imagga: We Tested Both Image Search APIs

Giorgi — Sun, 12 Apr 2026 15:15:30 +0000

I wanted to understand how Imagga's visual search compares to ours, so I signed up, got API keys, and tested both APIs against the same images. The two products turned out to be more different than I expected.

TL;DR: Imagga's "visual search" is built on image categorization and tag matching. Vecstore uses vector embeddings for actual visual similarity. Vecstore is about 8x faster on search (300ms vs 2.5s), doesn't require a separate database, supports text-to-image search, and auto-indexes without manual training. Imagga is stronger at structured image tagging, color extraction, and background removal.

How the Two Approaches Differ

The biggest takeaway from testing wasn't speed. It was that the two APIs use fundamentally different approaches to image search.

Imagga categorizes images into tags using WordNet taxonomy and then finds other images that share similar tags. When you search for a dog photo, it first categorizes it as border_collie.n.01 with 93.4% confidence, then finds other images that were categorized similarly. It's a categorization-first approach.

Vecstore converts images into vector embeddings that represent visual meaning, then finds the closest matches in vector space. It doesn't categorize or tag anything. It compares what images actually look like.

Both are valid approaches. They solve different problems.

Imagga's Own Demo Needs a Second Database

This was the most interesting finding. I opened the network tab on Imagga's visual search demo and watched what happens when you search.

Two requests fire:

Request 1 goes to Imagga's API and returns categories + image IDs:

// Imagga search response
{
  "categories": [{
    "name": "border_collie.n.01",
    "confidence": 93.41
  }],
  "images": [{
    "id": "img_1770651039261-q6ozvx531",
    "distance": 0.387
  }]
}

No image URLs. No metadata. Just IDs and distances.

Request 2 goes to a Supabase database to resolve those IDs:

// Second request to Supabase
GET /rest/v1/visual_search_images
  ?select=save_id,image_url,file_name
  &save_id=in.(img_1770651039261-q6ozvx531,img_1770651039253-ggmgwfihy,...)

Their own demo needs a separate Postgres database just to display search results. That's not a limitation of the demo, it's how the API works. Imagga returns IDs, you resolve them yourself.

On Vecstore, one request returns everything:

// Vecstore search response
{
  "vector_id": "abc123",
  "score": 0.94,
  "metadata": {
    "image_url": "https://...",
    "name": "Border Collie",
    "category": "pets",
    "price": 45.00
  }
}

Image URLs, custom metadata, similarity scores. No second database.

Architecture Comparison

Here's what each setup looks like in practice:

Imagga:
Your app → Imagga API (returns IDs) → Your database (resolve URLs) → Your storage (serve images)

Vecstore:
Your app → Vecstore API (returns full results with URLs) → Your storage (serve images)

With Imagga you're maintaining a separate database that maps image IDs to URLs and metadata. With Vecstore that mapping lives inside the search itself.

Speed Comparison

I benchmarked every operation with real API calls.

Operation	Imagga	Vecstore
Insert image	3.8 - 4.7s	~200ms
Train index	~0.9s (manual step)	Not needed
Search query	2.0 - 2.5s	~300ms
Insert to searchable	~5-6s + manual retrain	~200ms (instant)

Vecstore's 300ms breaks down to about 90ms for embedding generation and 5-8ms for the actual vector search. The rest is network overhead.

Imagga's 2-2.5 seconds covers the image categorization and tag matching. That doesn't include the second call to your own database to resolve image URLs.

The WordNet Labels

Imagga uses WordNet taxonomy for its category names. In practice that looks like this:

border_collie.n.01
loggerhead.n.02
turbine.n.01
Persian_cat.n.01

The .n.01 suffix means "noun, first sense." This is standard in computational linguistics but not something most developers want to parse or display to users. You'd need a mapping layer to convert these to human-readable labels.

Vecstore doesn't return category labels at all. It returns similarity scores and whatever metadata you stored when inserting the image. You control the naming.

Index Training

With Imagga, after you insert images into an index, you need to manually call a train endpoint before those images become searchable. When you add new images later, you retrain again.

Here's what the insert-train-search flow looks like:

# Step 1: Insert images
curl -X POST "https://api.imagga.com/v2/images-similarity/index/save-image" \
  -u "api_key:api_secret" \
  -F "image_url=https://example.com/dog.jpg" \
  -F "index_name=my_index" \
  -F "save_id=img_001"

# Step 2: Manually train the index (required before search works)
curl -X POST "https://api.imagga.com/v2/images-similarity/index/train" \
  -u "api_key:api_secret" \
  -F "index_name=my_index"

# Step 3: Now you can search
curl -X GET "https://api.imagga.com/v2/images-similarity/index/search" \
  -u "api_key:api_secret" \
  -d "image_url=https://example.com/query.jpg" \
  -d "index_name=my_index"

For apps where users upload images regularly (marketplaces, social platforms, photo libraries), this means either retraining after every upload or batching retrains and accepting that new images won't be searchable immediately.

On Vecstore, insert and search:

# Insert (instantly searchable)
curl -X POST "https://api.vecstore.app/api/databases/{id}/documents" \
  -H "X-API-Key: your_key" \
  -H "Content-Type: application/json" \
  -d '{"image_url": "https://example.com/dog.jpg"}'

# Search
curl -X POST "https://api.vecstore.app/api/databases/{id}/search" \
  -H "X-API-Key: your_key" \
  -H "Content-Type: application/json" \
  -d '{"image_url": "https://example.com/query.jpg", "top_k": 10}'

No training step. Images are searchable the moment you insert them.

Text-to-Image Search

Imagga's visual search is image-to-image only. You search by uploading a photo.

Vecstore supports both. You can type "wind turbine on a hillside" and get matching images back. This works because the model understands both text and images in the same embedding space.

If your users need to search by description (e-commerce, stock photography, content discovery), this matters.

No Metadata Filtering on Imagga

Since Imagga returns only IDs, there's no way to filter results at search time. You can't say "find similar images where price is under $50" or "find similar images in the shoes category."

With Vecstore, metadata is stored alongside the vectors and returned with results. Filtering by metadata fields is part of the search query itself.

For e-commerce and marketplace use cases where you need to combine visual similarity with business logic, this is a meaningful difference.

Pricing

The pricing models are different. Imagga charges monthly subscriptions where unused requests expire at the end of each billing cycle. Visual search requires the $79/mo Indie plan or higher.

Vecstore sells credit packs that never expire. All features are included on every plan.

Volume	Imagga	Vecstore
5K operations	$79/mo	$8
70K operations	$79/mo	~$66
300K operations	$349/mo	~$240

At lower volumes, Vecstore is significantly cheaper. At higher volumes the gap narrows. The main structural difference is that Imagga locks features behind higher tiers (face recognition needs the $349/mo Pro plan) while Vecstore includes everything on all plans.

What Imagga Does Well

Imagga's core strength is image tagging and categorization. If you need to auto-generate structured labels for images, extract dominant colors, remove backgrounds, or read barcodes, Imagga has mature, well-documented tools for that. Their categorization engine is solid and they've been doing this for a long time.

Their visual search is built on top of that categorization engine, which makes sense for their product. It's a different approach than embedding-based search, with its own strengths: structured categories, confidence scores for each label, and a well-defined taxonomy.

When to Use Which

Imagga is a better fit when you need:

Structured image tagging and categorization
Color extraction and analysis
Background removal
Barcode and text recognition in images

Vecstore is a better fit when you need:

Visual similarity search (find images that look alike)
Text-to-image search (describe what you want, get matching images)
Face search across an image library
Content moderation (NSFW detection)
Instant indexing without manual training steps
Search results with image URLs and metadata in one call

If your use case is primarily search, the differences in speed, developer experience, and architecture add up. Vecstore was built for search from the ground up. Imagga was built for image understanding, and search is one application of that.

See the full side-by-side comparison or try Vecstore free.

Vecstore vs Algolia: Semantic Search vs Keyword Search

Giorgi — Sun, 12 Apr 2026 15:14:54 +0000

Algolia is the default answer when someone says "I need search." And for good reason — it's fast, reliable, and has been the industry standard for years. If you need autocomplete, faceted filtering, or typo tolerance on product names, Algolia is hard to beat.

But search has changed. Users don't just type exact product names anymore. They describe what they want in plain language. They upload photos to find similar products. They search in their own language and expect it to just work.

That's a fundamentally different problem, and it requires a fundamentally different approach.

How Algolia Searches

Algolia is a keyword search engine. It matches the words in a query against the words in your records. If a user types "running shoes," Algolia finds records containing "running" and "shoes."

It's enhanced with powerful features on top — typo tolerance, faceting, synonyms, and instant search-as-you-type. These make the keyword matching experience feel polished. But the underlying mechanism is still matching strings.

This means:

"car that is quick" won't find a record that says "car that is fast" — the word "quick" doesn't appear in the data
Synonyms require manual configuration — you have to tell Algolia that "quick" and "fast" mean the same thing, for every synonym pair, in every language
Multilingual search requires per-index setup — you can't just throw a Japanese query at an English index and expect results

For structured, predictable search queries, this works great. For everything else, it creates friction.

How Vecstore Searches

Vecstore is a semantic search engine. Instead of matching words, it matches meaning.

When you insert a document or image, Vecstore converts it into a vector — a mathematical representation of its meaning. At search time, the query is also converted into a vector, and Vecstore finds the closest matches by meaning, not by words.

This means:

"car that is quick" finds "car that is fast" because the two phrases mean the same thing
No synonym configuration — the model understands language natively
100+ languages work out of the box — semantic search works natively in Japanese, Korean, Arabic, and 100+ more languages without any extra configuration
Images are searchable by content — not by tags someone manually attached

Where Each One Wins

This isn't about one being better than the other. They solve different problems.

Algolia is the better choice when you need:

Autocomplete. Search-as-you-type with instant dropdown suggestions. Algolia's prefix matching is purpose-built for this. If your users expect results before they finish typing, Algolia delivers.

Faceted navigation. Filtering a product catalog by brand, size, color, price range — this is Algolia's bread and butter. It's deeply integrated and fast.

Typo tolerance on exact terms. If users are searching for specific product names, part numbers, or SKUs, Algolia's fuzzy matching on exact strings is excellent.

Vecstore is the better choice when you need:

Natural language queries. When users type "something to keep my coffee hot" instead of "insulated travel mug," semantic search finds the right results. Keyword search doesn't.

Image search. Vecstore supports reverse image search (upload a photo, find similar ones), text-to-image search (describe what you want, get matching images), face search, and OCR search (find images by the text inside them). Algolia has no native equivalent — their image approach requires external tagging services.

Multilingual search. Vecstore understands 100+ languages natively. Your Japanese users search in Japanese and get accurate semantic results — no per-language index, no translation layers, no extra configuration. Same API, same accuracy, every language.

Content moderation. Vecstore includes built-in NSFW detection across 52 categories. If your platform accepts user-uploaded images, this is one API call instead of a separate moderation pipeline.

The Image Search Gap

This is where the difference is most visible. Algolia doesn't do image search natively. Their documentation recommends using external services like Google Vision or AWS Rekognition to generate tags, then storing those tags as searchable attributes in your Algolia index.

That means:

You need a separate tagging service
You pay for both the tagging API and Algolia
Search quality is limited to whatever tags were generated
A search for "vintage rucksack" won't match an image tagged as ["backpack", "leather", "brown"]

With Vecstore, you insert the image and search it. A search for "vintage rucksack" finds a leather backpack because the model understands visual similarity — not because someone tagged it correctly.

Side-by-Side Comparison

Feature	Vecstore	Algolia
Search type	Semantic (meaning)	Keyword (strings)
Image search	Native — reverse, text-to-image, face, OCR	Requires external tagging
Synonym handling	Automatic	Manual configuration
Multilingual	100+ languages, one index	Per-index setup
Natural language queries	Works natively	Needs rules and synonyms
NSFW detection	52 categories built-in	Not available
Autocomplete	Not available	Built-in
Faceted filtering	Not available	Built-in
Pricing	From $1.60/1K operations	Per search + per record

We're being honest about the gaps. Vecstore doesn't do autocomplete or faceted filtering. If those are critical to your product, Algolia is the right choice — or use both.

When to Use Both

For many products, the answer is both. Use Algolia for your search bar autocomplete and faceted catalog navigation. Use Vecstore for natural language search, image search, and content moderation.

The two aren't mutually exclusive. They're different tools for different problems.

The Bottom Line

Algolia is an excellent product that earned its place as the industry standard for keyword search. If your users search by typing exact product names into a search bar, it's the right tool.

But if your users describe what they're looking for, search by uploading images, or need search that works in their language — keyword matching isn't enough. That's what Vecstore is built for.

The right question isn't "which is better?" It's "what kind of search do my users actually need?"

Try Vecstore free or see the full comparison.

How to Search Images by Text Description (Text-to-Image Search)

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

Your user types "vintage wooden chair with armrests" into a search bar. Your app returns photos of vintage wooden chairs with armrests from a database of 100,000 product images. None of those images were tagged with those words. Nobody manually labeled them. The search just understands what the user is describing.

That's text-to-image search. And it's more practical than most people realize.

What Is Text-to-Image Search?

Text-to-image search lets users find images by describing what they want in plain language. Instead of browsing categories or filtering by tags, the user just says what they're looking for and gets matching images back.

This is different from traditional image search where you need metadata. In a typical setup, someone has to tag each image with keywords like "chair," "wood," "vintage," "armrest." If they miss a tag, the image is invisible to search. If the user uses a word that doesn't match any tag (like "antique" instead of "vintage"), the search returns nothing.

Text-to-image search skips all of that. The system understands both the text query and the visual content of the images, and matches them by meaning.

How It Works

The technology behind this is called a multimodal embedding model. The most well-known one is CLIP, built by OpenAI. Others include OpenCLIP, SigLIP, and SigLIP2.

These models do something clever: they map both text and images into the same mathematical space. A photo of a red sports car and the text "red sports car" end up near each other in this space, even though one is pixels and the other is words.

Here's the process:

At index time, each image in your database gets converted into a vector (an array of numbers, usually 768-1024 of them). This vector captures what the image looks like, what objects are in it, the scene, the colors, the composition.
At search time, the user's text query also gets converted into a vector in the same space.
The system finds the image vectors that are closest to the query vector. "Closest" means most similar in meaning.

The result: "cozy living room with fireplace" finds photos of cozy living rooms with fireplaces, even if nobody ever described those images that way.

Why It's Better Than Tags

Manual tagging has been the standard for decades. It works, but it has real problems at scale.

Tags are incomplete. A person tagging a photo of a beach sunset might write "beach, sunset, ocean." They probably won't add "vacation, travel, golden hour, silhouette, waves, coastline, relaxation." But a user might search for any of those terms. With text-to-image search, all of those queries would find that image because the model understands the full visual content.

Tags are inconsistent. Different people tag differently. One person writes "sneakers," another writes "trainers," another writes "athletic shoes." With manual tagging, you either enforce a strict vocabulary (which limits what users can search for) or accept inconsistency (which creates gaps in search results).

Tags don't scale. Tagging 100 images is tedious. Tagging 100,000 is a full-time job. Tagging 10 million requires a team. Text-to-image search has no per-image cost. You insert the images and they're searchable immediately.

Tags can't capture everything. How do you tag "mood" or "style"? A user searching for "minimalist interior" has a specific aesthetic in mind. You can't tag for that. But a model trained on millions of images understands what "minimalist" looks like visually.

Where Text-to-Image Search Gets Used

E-commerce product search. A customer types "casual blue dress for summer" and gets matching products. This works especially well when your catalog has thousands of items and your customers don't know the exact product names or categories.

Stock photography. Designers search for "person working at laptop in coffee shop" and find relevant photos. This is how platforms like Shutterstock and Getty Images work. Without text-to-image search, finding the right stock photo means browsing hundreds of loosely tagged results.

Real estate. "Modern kitchen with island and natural light" returns listing photos that match. Buyers know what they want to see. Text-to-image search lets them describe it instead of clicking through filters.

Fashion and styling. "Oversized wool coat" or "streetwear outfit with jordans" returns visual matches from your product catalog or user-generated content. Fashion is inherently visual and hard to search with keywords alone.

Content management. Your company has 50,000 photos from events, product shoots, and marketing campaigns sitting in a DAM. Nobody can find anything because the tagging is inconsistent. Text-to-image search makes the entire library searchable without re-tagging a single image.

Food and recipe apps. "Pasta dish with fresh basil" finds matching food photos. This works because the model understands what basil looks like on a plate, not because someone tagged the image with "basil."

How to Add It to Your App

If you're building this yourself, you need a CLIP model running on a GPU server, a vector database to store image embeddings, and a pipeline to keep everything in sync. That's a real project (we wrote a full cost breakdown if you're curious).

With an API like Vecstore, the process is simpler:

1. Insert your images.

POST https://api.vecstore.app/api/databases/{id}/documents

X-API-Key: your-api-key

Body:
  image_url: "https://example.com/products/chair.jpg"

Each image gets embedded automatically when you insert it.

2. Search by text.

POST https://api.vecstore.app/api/databases/{id}/search

X-API-Key: your-api-key

Body:
  query: "vintage wooden chair with armrests"
  top_k: 10

The API returns the most visually relevant images ranked by similarity score.

That's it. No tagging, no CLIP model to run, no vector database to manage. The same database also supports reverse image search, face search, and OCR search.

If you want a full tutorial with frontend code, we have step-by-step guides for React and Next.js.

Text-to-Image Search vs. Image-to-Image Search

These are related but different.

Text-to-image: user types a description, gets matching images. Good when the user knows what they want but doesn't have a reference image.

Image-to-image (reverse image search): user uploads a photo, gets visually similar images. Good when the user has a reference ("find me more like this") but can't describe it in words.

Both use the same underlying technology (multimodal embeddings) and work against the same image database. Most production search features support both, letting users switch between typing a description and uploading a photo.

Getting Started

If you want to try text-to-image search on your own images, the fastest path is Vecstore's free tier. Insert some images, run a few text queries, and see how the results look.

Try it free or check out the live demo on our homepage, which searches 10,000 paintings by description.

Search Is the Most Neglected Feature in Every SaaS App

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

Go to any SaaS app you use daily. Click the search bar. Type something slightly outside the exact phrasing of a menu item or document title. See what happens.

Nine times out of ten, you'll get nothing useful. Maybe a "no results found" page. Maybe results sorted by creation date instead of relevance. Maybe a list of every record that contains one of the three words you typed.

This happens on products built by teams of 50+ engineers with millions in funding. The search bar is right there in the UI. It just doesn't work.

The Numbers Are Bad

Search users are not casual browsers. They're the people who showed up knowing what they want.

68% of users go straight to the search bar when they land on a site
Search users convert at 2-3x the rate of non-search users
Only 15% of visitors use site search, but they generate 45% of total revenue
Amazon's conversion rate jumps from 2% to 12% when search is used

And the other side:

80% of users leave because the search results are bad
81% of sites return irrelevant results for simple two-word queries
U.S. retailers alone lose roughly $300 billion per year to poor search

That last number sounds made up. It's not. When your highest-intent users hit a dead end, they don't try rephrasing. They leave.

How Search Actually Gets Built

Nobody sets out to build bad search. It just kind of happens.

A product launches with no search. Users ask for it. Someone adds WHERE title ILIKE '%query%', maybe with some ts_vector if they're feeling ambitious. It ships. It technically works.

Six months later, the data has grown. Results get worse. Users complain. The team acknowledges it's a problem but nobody prioritizes it because search isn't a feature anyone owns. It's nobody's OKR. It doesn't have a PM. It falls into the gap between product, engineering, and data, and it stays there.

A year in, somebody suggests Elasticsearch. Two weeks of setup, ongoing tuning nobody wants to do, and eventually it's "good enough" and the team moves on.

Search is a horizontal feature. It touches everything but lives in no team's roadmap.

Why Keyword Search Breaks Down

Most product search is still keyword matching. And keyword matching can only find exact words.

User types "affordable laptop for coding." Your database has "Developer Workstation Pro — $899." Zero keyword overlap. Nothing returned.

User types "warm jacket for hiking." You have "Insulated Trail Parka." Nothing.

User uploads a photo of a product they saw in a store. Keyword search doesn't even know what to do with that.

This is how normal people search. They describe what they want in their own words. Keyword search needs them to guess the exact words in your database. The mismatch is constant, and it gets worse with scale.

What Good Search Looks Like

Good search is invisible. You type what you're thinking, you get what you meant.

It understands intent, not just keywords. "Affordable laptop for coding" surfaces budget developer machines even without exact word matches. Semantic search matches meaning, not strings.

It's fast. Every additional second of latency drops conversions by about 7%. Good search returns results in under 200ms.

It handles failure gracefully. Showing related results instead of a blank "no results" page keeps 56% of users engaged. Most implementations don't bother.

Autocomplete actually helps. Autocomplete alone boosts conversions by 24%. Most implementations either skip it or suggest irrelevant completions based on alphabetical order.

Spotify's search understands moods and genres, not just song titles. Pinterest is essentially a search engine with a visual interface. None of these are LIKE '%query%' wrappers.

Why It Stays Broken

If the data is this clear, why doesn't every team fix their search?

It's not a weekend project. Good search in 2026 means semantic understanding, which means embeddings, GPU inference, vector storage, and a pipeline to keep it all in sync. For 1M items, the infrastructure alone runs $740-1,845/month before you write a line of product code.

The maintenance is the real cost. Models get updated. Indexes need rebuilding. Sync logic breaks at 3 AM. Teams underestimate the ongoing tax.

The ROI is hard to sell. "Search users convert at 3x" doesn't cleanly translate to "improving search will 3x conversions." The causality is muddy enough that it never wins the prioritization fight against a new feature or a dashboard redesign.

So search stays in the backlog. The search bar sits there, quietly losing money.

Search Is a Product Surface

The search bar is the only place in your product where users tell you what they want in their own words. Every other interaction is constrained by your UI - buttons you designed, menus you structured, forms you created. Search is where they express raw intent.

A user who searches is telling you exactly what they need. If you give them the right result, they convert. If you give them nothing, they leave.

The companies that figured this out early built their entire products around it. The ones that didn't are still shipping ILIKE '%query%' and wondering why engagement plateaus.

Search isn't a feature. It's the closest thing to a conversation your product has with your users. Treat it like one.