Embedding models comparison: OpenAI, Google, Qwen, Nomic, Jina, BAAI

A practical guide to text-embedding-3-small & -large, gemini-embedding-001, embeddinggemma-300m, qwen3-embedding, nomic-embed-text-v2-moe, jina-embeddings-v5-text-small, and BGE-M3.

Why it matters

Embedding models are the backbone of semantic search, RAG pipelines, and vector databases. Choosing the wrong one costs you accuracy, money, or both. This post compares eight models that frequently come up in modern AI stacks - spanning zero-ops APIs, self-hosted open weights, on-device models, and hybrid retrieval - so you can pick one with confidence.

The contenders

Deep dive

text-embedding-3-small (OpenAI)

OpenAI's workhorse embedding model.

It introduced Matryoshka Representation Learning (MRL), letting you truncate dimensions at inference time without retraining - so you can trade a little accuracy for significant storage and speed savings (e.g., dropping to 512 dims cuts index size by ~66% with minimal quality loss).

Strengths:

• •

  Best-in-class API reliability and SLA

• •

  Native dimension reduction via MRL (dimensions available from 256 to 1536)

• •

  Solid English MTEB score (~62 average)

• •

  Zero ops - no GPU, no deployment

Weaknesses:

• •

  Proprietary: no local deployment, cost per token

• •

  Context window tops out at ~8K tokens

• •

  Black box: no insight into training data or architecture

Best for: Teams that want to ship fast and don't want to manage infrastructure. Prototyping, low-volume production, or when your stack is already OpenAI-native.

text-embedding-3-large (OpenAI)

The larger sibling of text-embedding-3-small.

Same API, same 8K context, same MRL trick - but a higher quality ceiling, defaulting to 3072 dimensions (adjustable down to 256). OpenAI reports ~64.6 MTEB (English), and a shortened 256-dim -large vector still outperforms a full 1536-dim ada-002 vector.

Strengths:

• •

  Higher accuracy than -small with the same zero-ops workflow

• •

  3072 default dims, adjustable via MRL for storage/quality trade-offs

• •

  Drop-in for teams already on OpenAI

Weaknesses:

• •

  More expensive per token than -small, and larger vectors cost more to store/index

• •

  Same ~8K context limit and proprietary black-box constraints

Best for: OpenAI-native teams that want more accuracy than -small and are willing to pay for larger vectors and higher per-token cost.

gemini-embedding-001 (Google)

Google's first general-purpose text embedding model, and currently a leaderboard topper.

It defaults to 3072 dimensions (reducible to as low as 128 via MRL), covers 100+ languages, and took #1 on MTEB Multilingual, MTEB English v2, and MTEB Code, with an average task score around 68.

Strengths:

• •

  State-of-the-art quality across multilingual, English, and code retrieval

• •

  Flexible dimensions (128–3072) via MRL

• •

  Zero ops — served through the Gemini API

Weaknesses:

• •

  Proprietary and API-only; no self-hosting

• •

  Shorter input window (~2K tokens) than Qwen3 or Jina v5

• •

  Requires manual normalization when using non-default dimensions

Best for: Teams that want top-tier quality with no infrastructure and are comfortable with an API dependency. A strong "best quality, no GPU" default.

embeddinggemma-300m (Google)

Google's open-weight counterpart to gemini-embedding-001, released in September 2025. It's a 300M-parameter encoder built from Gemma 3, deliberately sized for on-device deployment — Google positions it for "environments with limited resources such as mobile phones, laptops, or desktops."

It outputs 768 dimensions, truncatable to 512, 256, or 128 via MRL, handles a 2048-token context, and was trained on 100+ languages. Google reports mean(task) scores of 69.67 on MTEB English v2, 61.15 on MTEB Multilingual, and 68.76 on MTEB Code — remarkable for the parameter count. Quantization-aware trained checkpoints (Q4_0, Q8_0, mixed precision) ship alongside the full-precision weights.

One important operational detail: EmbeddingGemma expects task-specific prompt prefixes. Queries are formatted as task: {task description} | query: {content} and documents as title: {title | "none"} | text: {content}, with distinct prefixes for retrieval, question answering, fact verification, classification, clustering, semantic similarity, and code retrieval. Skip the prefixes and you leave quality on the table.

Strengths:

• •

  Genuinely small: 300M params, with QAT checkpoints for low-memory deployment

• •

  Runs on-device — no GPU, no API, no data leaving the machine

• •

  100+ languages and strong MTEB scores for its size

• •

  Compact 768-dim output, reducible to 128 via MRL

Weaknesses:

• •

  Gemma license, not Apache 2.0 or MIT — subject to Google's Terms of Use and Prohibited Use Policy, so check it against your compliance requirements

• •

  2048-token context, same as gemini-embedding-001 and well short of Qwen3 or Jina v5

• •

  Requires task-specific prompt prefixes; getting them wrong silently costs accuracy

• •

  Absolute quality still trails the frontier API models and larger open weights

Best for: On-device, offline, or privacy-sensitive retrieval — mobile apps, desktop tools, edge deployments, or anywhere you want embeddings without a GPU or a network round-trip. Also a good fit when you want a Google-quality model self-hosted rather than API-only.

qwen3-embedding (Alibaba / Qwen)

The Qwen3 embedding family comes in three sizes (0.6B, 4B, 8B) and supports an unusually long 32K token context window — a standout feature for document-level retrieval. It ranked #1 on the MTEB multilingual leaderboard (8B, score 70.58 as of June 2025), thanks to Qwen3's 100+ language pre-training, and is the strongest open-weight option at the top end.

Strengths:

• •

  State-of-the-art open-weight MTEB scores, especially multilingual

• •

  32K context window — best in class for long documents

• •

  Full Apache 2.0 license, self-hostable

• •

  Flexible sizes: use 0.6B for speed, 8B for quality

Weaknesses:

• •

  8B variant needs real GPU memory (~16GB VRAM for fp16)

• •

  Larger sizes are heavier to serve than compact models

• •

  Cold-start cost if self-hosting for the first time

Best for: Long-document retrieval, multilingual applications, or teams that want top-tier quality with the freedom to self-host. Strong default choice for serious production workloads.

nomic-embed-text-v2-moe (Nomic AI)

Nomic's v2 is built on a Mixture of Experts architecture (8 experts, top-2 routing): 475M total parameters but only 305M active per forward pass, giving it a favorable quality-per-FLOP ratio. Unlike the English-only v1, v2-moe is explicitly multilingual (~100 languages, trained on 1.6B pairs), and it ships with fully open weights and a reproducible training pipeline.

Strengths:

• •

  MoE architecture: 305M active params for efficient inference

• •

  Fully open: weights, training data, and code are public

• •

  Multilingual out of the box (~100 languages)

• •

  768-dim output, reducible to 256 via MRL — compact for storage-sensitive workloads

Weaknesses:

• •

  Short 512-token context window — you'll need tighter chunking than the other models here

• •

  MoE inference carries more memory overhead than a dense model of similar active params

• •

  Top-end quality trails Qwen3-8B and the leading API models

Best for: Teams that care deeply about reproducibility and open science, or who want an efficient, multilingual, self-hosted model — provided your chunks fit within 512 tokens.

jina-embeddings-v5-text-small (Jina AI)

Despite the "small" name, this is a ~677M-parameter model built on a Qwen3-0.6B backbone — not a tiny CPU model. It distills much larger models into a sub-1B footprint and is SOTA for its size: ~71.7 on MTEB English v2 and ~67.7 on MMTEB, the highest among multilingual embedding models under 1B parameters. It supports a 32K token context, defaults to 1024 dims (truncatable to 32 via MRL), and ships task-specific LoRA adapters for retrieval, similarity, clustering, and classification.

Strengths:

• •

  SOTA quality among sub-1B multilingual models

• •

  32K context window for long-document retrieval

• •

  MRL down to 32 dims, plus task-specific LoRA adapters

• •

  Apache 2.0, self-hostable

Weaknesses:

• •

  At ~677M params it wants a GPU for high throughput — not a CPU-only edge model

• •

  Newer release — less community tooling than long-established models

Best for: Teams that want near-frontier retrieval quality in a self-hostable sub-1B model, with long context and flexible output dimensions.

BGE-M3 (BAAI)

BGE-M3 from the Beijing Academy of AI is a versatile open model (~568M params, XLM-RoBERTa backbone) best known for multi-functionality: it can produce dense, sparse (lexical), and multi-vector (ColBERT-style) representations from a single model. It handles 100+ languages, an 8K context, and 1024-dim dense output, under a permissive MIT license.

Strengths:

• •

  Dense + sparse + multi-vector retrieval from one model — ideal for hybrid search

• •

  100+ languages, 8K context

• •

  MIT license, self-hostable

Weaknesses:

• •

  Dense-only MTEB scores trail the newest frontier models

• •

  Getting full value requires plumbing for sparse/multi-vector, not just dense vectors

Best for: Hybrid lexical-semantic search systems, and teams that want one self-hosted model covering dense, sparse, and multi-vector retrieval.

Benchmark snapshot (MTEB, English)

Decision guide

Using with SurrealDB

All of these models produce float vectors you can index with SurrealDB's HNSW or DiskANN indexes. A minimal setup:

DEFINE TABLE documents SCHEMAFULL;
DEFINE FIELD content ON documents TYPE string;
DEFINE FIELD embedding ON documents TYPE array<float>;
DEFINE INDEX idx_embedding ON documents
  FIELDS embedding
  HNSW DIMENSION 1536  -- match your model's output dims
  DIST COSINE;

Takeaway

• •

  Ship fast, no infra: text-embedding-3-small (or text-embedding-3-large for more accuracy)

• •

  Best quality with no infra: gemini-embedding-001

• •

  Best self-hosted quality: qwen3-embedding-8B

• •

  Frontier quality in a small self-hosted model: jina-embeddings-v5-text-small

• •

  On-device, offline, or CPU-only: embeddinggemma-300m

• •

  Hybrid dense/sparse/multi-vector search: BGE-M3

• •

  Open science / reproducible: nomic-embed-text-v2-moe

There is no universal winner — the right choice depends on your latency budget, infrastructure, language coverage needs, context-length requirements, and how much you care about keeping the model on-prem. Run a quick MTEB-style eval on a sample of your own data before committing to any of them.

Get started

Ready to build semantic search and RAG on top of these embeddings?

• •

  Create a free cloud instance

• •

  Start building

• •

  Join our Discord server - new to embeddings in SurrealDB? Start in the #all-ai channel.