WooCommerce + RAG: Where Should You Store Your Vectors?

Choosing where to store vectors is an architectural decision, not merely a database preference. For a WooCommerce retrieval-augmented generation system, the vector store must support product, variation, category, attribute, order, and documentation data while preserving the relationships and permissions that make the retrieved context useful.

The right choice depends on catalog size, query volume, filtering requirements, operational expertise, and how closely semantic search must work with transactional WooCommerce data.

What the vector store needs to support

A WooCommerce RAG implementation typically stores more than an embedding array. Each vector should be associated with the content used to create it and enough metadata to filter, identify, refresh, and authorize the result.

• Embedding: The numeric vector generated by the selected embedding model.
• Searchable text: The product description, attribute summary, policy paragraph, or other source content represented by the vector.
• Entity identity: The WooCommerce product ID, variation ID, order-independent document ID, or external source ID.
• Content type: For example, product, variation, category, shipping policy, refund policy, or internal support article.
• Store and language: Important for multilingual, multisite, or multi-tenant installations.
• Version information: The embedding model, chunking strategy, source revision, and indexing timestamp.
• Filtering fields: Product status, catalog visibility, category IDs, stock state, brand, price range, and other fields used before or after vector search.

Do not treat metadata as an afterthought. A semantically similar result for a hidden product, an out-of-scope store, or a discontinued variation is still a bad retrieval result.

Option 1: PostgreSQL with pgvector

PostgreSQL with the pgvector extension is often the strongest default when the WooCommerce application already relies on PostgreSQL or when a separate application service owns the RAG pipeline.

It keeps vectors, metadata, and relational joins in one system. This makes it practical to combine semantic similarity with structured constraints such as store ID, language, product status, and category. It also allows a retrieval service to join vector results with authoritative product records instead of duplicating every display field in the index.

CREATE TABLE rag_documents (  id bigserial PRIMARY KEY,  source_type text NOT NULL,  source_id bigint NOT NULL,  store_id bigint NOT NULL,  language text NOT NULL,  content text NOT NULL,  metadata jsonb NOT NULL DEFAULT '{}',  embedding vector(1536) NOT NULL,  content_hash text NOT NULL,  embedding_model text NOT NULL,  updated_at timestamptz NOT NULL DEFAULT now());

For larger collections, an approximate nearest-neighbor index can reduce search latency. The exact index type and tuning depend on the pgvector version, distance metric, vector dimensions, and workload. Benchmark with representative catalog data rather than assuming default parameters will be suitable.

One important WooCommerce consideration is that standard WooCommerce installations commonly use MySQL or MariaDB. Adding PostgreSQL solely for vectors introduces another operational system. That can still be a good decision, but the team must define synchronization, backups, failover, and source-of-truth responsibilities clearly.

Option 2: A managed vector database

Managed vector databases can reduce the infrastructure burden for teams that need high-scale similarity search, horizontal scaling, or a specialized operational model. They commonly provide namespaces or tenants, metadata filtering, approximate nearest-neighbor indexes, and APIs designed for embedding search.

This option is useful when:

• The retrieval service is already independent from WordPress.
• The system indexes many stores or large external knowledge bases.
• The team does not want to operate database extensions and vector indexes.
• Search traffic is bursty or requires elastic capacity.
• The application needs capabilities that are not convenient in the primary relational database.

The main trade-off is data duplication. Product data and business rules remain authoritative in WooCommerce, while the vector service contains a derived copy. Webhooks, scheduled jobs, or an event queue must update or delete vectors when products change.

Do not rely only on a product ID stored in the vector database. Include tenant or store identity in every record and enforce it in the query filter. A product ID may be unique within one WooCommerce installation but not across a multi-store platform.

Option 3: MySQL-compatible vector support

If the existing WooCommerce stack is built around MySQL or MariaDB, keeping retrieval data in the same database may simplify deployment and backups. Some MySQL-compatible platforms and database services now offer vector data types and similarity functions, but support, index behavior, distance metrics, and version compatibility vary substantially.

Before choosing this route, verify:

• Whether the production database version supports the required vector type and nearest-neighbor index.
• Whether similarity search can use structured metadata filters efficiently.
• Whether vector queries will compete with checkout, cart, and order workloads.
• Whether the hosting provider permits the required extensions or features.
• How upgrades, replicas, backups, and restores handle vector columns and indexes.

A shared transactional database can be appropriate for a small or moderate catalog, but retrieval queries should not degrade checkout performance. Read replicas, a separate database, or an asynchronous retrieval service may be safer as usage grows.

Option 4: Search engines with vector capabilities

Elasticsearch, OpenSearch, and similar search platforms can combine keyword search, filters, facets, and vector similarity. This hybrid behavior is especially valuable for WooCommerce because shoppers often use exact product names, SKUs, model numbers, or attributes that semantic similarity alone may handle poorly.

A hybrid query can retrieve products using both lexical relevance and vector similarity, then combine or rerank the results. Search engines are also well suited to faceted filtering for categories, brands, attributes, and price ranges.

The cost is additional operational complexity and another derived index. The team must manage mapping changes, reindexing, document synchronization, shard sizing, and failure recovery. Search engines are usually a better fit when product discovery itself is a major requirement, not just when an internal support assistant needs a small number of document chunks.

Where not to store production vectors

Storing embeddings directly in WordPress post meta is convenient for a prototype but usually becomes difficult to operate. Post meta is not designed for efficient nearest-neighbor search, and serialized arrays create large rows, weak indexing options, and expensive updates. It also mixes derived machine-learning data with content fields that WordPress administrators may edit or migrate independently.

Flat files or JSON blobs can work for local experiments and deterministic test fixtures. They are not a reliable production store for concurrent updates, filtering, tenant isolation, or incremental reindexing.

Object storage is useful for raw documents, embedding export files, backups, and reindexing artifacts. It is generally not the primary query layer for interactive vector retrieval unless another search service indexes its contents.

Separate source data from retrieval data

The vector store should contain a derived representation of WooCommerce content, not become the authority for price, stock, tax, permissions, or order state. At retrieval time, use the vector result to identify relevant entities, then fetch current authoritative fields from WooCommerce or the application domain service when accuracy matters.

For example, a product chunk can contain a description and attribute summary, but the final response should not trust an old embedded price. Retrieve the current price and stock status separately, especially for questions such as “Which black jackets are available under $100?”

A practical storage pattern

1. Listen for product, variation, category, and policy changes.
2. Normalize the changed source into stable text and metadata.
3. Calculate a content hash so unchanged content is not embedded again.
4. Generate a new embedding asynchronously.
5. Upsert the vector record using a stable source key and tenant key.
6. Mark old versions inactive or remove them atomically.
7. At query time, apply tenant, language, visibility, and content-type filters before returning context.
8. Hydrate volatile fields such as price and stock from the authoritative WooCommerce data.

A stable record key might combine the store, source type, source ID, language, and chunk number. Store the embedding model and content hash with the record so a model change or chunking change can trigger a controlled reindex.

Decision guide for agencies

• Small catalog and existing PostgreSQL platform: Start with pgvector for a simple, relational design.
• Large multi-tenant retrieval service: Evaluate a managed vector database or a dedicated search platform with strict tenant filters.
• Strong keyword and faceted-search requirements: Consider Elasticsearch or OpenSearch with hybrid retrieval.
• MySQL-based WooCommerce hosting: Use native vector support only after validating version, performance, and hosting constraints; otherwise operate a separate retrieval store.
• Prototype or proof of concept: A local file or lightweight database is acceptable, but plan the migration path before indexing customer data.

Operational checks before launch

Measure retrieval latency, update delay, index size, embedding cost, filter performance, and relevance on real WooCommerce queries. Test product deletion, variation updates, language changes, store isolation, and a full reindex. Confirm that a disabled or deleted product cannot appear through stale vectors.

Also test failure behavior. If embedding generation is unavailable, the product update should not corrupt the authoritative WooCommerce record. If the vector store is unavailable, the application should return a controlled response or use a keyword fallback rather than exposing stale or cross-tenant context.