Apache Paimon 2.0 Multimodal Lakehouse: BLOB, VECTOR, and Indexing Realities

If your data lives in a single table — orders, users — you likely haven't faced the problem where a minimum viable AI dataset spans four separate systems: images in object storage, business attributes in a database, embeddings in a vector store, and training versions in scripts. Each system has its own metadata, update pipeline, permissions, and quality baselines. Aligning them every time you want AI to see the same data is the real pain.

Object storage suits binaries, databases suit transactional access, and specialized vector stores optimize online retrieval. This stack isn't wrong, but it repeats "the same truth": the same product image has metadata in object storage, attributes in the database, and a vector in the vector store. When the model upgrades, all three must change — and they almost never change simultaneously.

Apache Paimon aims to give these fragmented data a common table: one logical table holding structured attributes, raw images, text chunks, and embeddings — each in its most suitable physical form, not by stuffing binaries into ordinary columns.

I. Object Table and BLOB Are Fundamentally Different

Newcomers often confuse: "Paimon 1.0 already had Object Table; why does 2.0 emphasize BLOB?" They solve different problems.

Object Table builds a catalog index over files sitting in object storage: what files exist, names, sizes, last modified times. It answers discovery questions like "which images exceed 2 MB?" But it queries metadata only — the image content remains in the original object store.

BLOB brings the binary content itself under table management. After a product image is ingested, a logical row becomes: product_id | category | title | image | embedding Here image is a real BLOB column, physically stored in separate .blob files, isolated from regular structured columns. Querying product_id and category never touches image data.

Two modes exist: Managed BLOB (table manages file lifecycle) and Blob View / descriptor reference (table stores only a reference, reads from upstream on demand, avoiding a full binary copy). Logical unification ≠ physical replication; external objects are not automatically copied into Paimon.

II. VECTOR Is a Data Type, Not a Search Capability

Paimon 2.0 introduces VECTOR<t, n> for fixed-dimension dense vectors, supporting element types BOOLEAN, TINYINT, SMALLINT, INT, BIGINT, FLOAT, DOUBLE; dimension has no default. However, vector columns cannot serve as primary keys, partition keys, or sort fields. They can use dedicated Vortex files for independent storage to optimize reads, but independent storage ≠ direct similarity search.

This is the most common misconception in multimodal lakehouses:

Vector storage solves "where to put vectors";

Vector indexing solves "how to find nearest neighbors for a query vector".

Defining a VECTOR<FLOAT, 768> column only states "this table has 768-dim dense vectors, physically stored in vector files." Without an index, queries fall back to brute-force full-table scan — acceptable for small tables, disastrous for tens of millions of rows.

III. Indexing and Visibility: Where Engineering Fails

Paimon 2.0's global index system includes B-tree, Bitmap, Vector, Full-text. They address different needs:

B-tree / Bitmap: scalar predicate filtering (e.g., "after 2026-10, category = 'electronics'")

Vector index: approximate nearest neighbor (ANN) retrieval

Combination: scalar index narrows candidates first, then vector similarity recall on the candidate set

Three engineering pitfalls:

Pitfall 1: Indexes are not automatic. Creating a table, loading data, defining a vector column does not mean indexes are built. Index construction must be triggered separately; only after commit are they used by queries.

Pitfall 2: Indexes have a visibility window. Data write, data commit, index build, index commit are separate steps. New data may be in the table, but if the index hasn't finished building or committing, vector search won't recall it. This is the most frequent SLA trap in managed cloud offerings.

Pitfall 3: Filter predicates may not push down. Not every WHERE clause can combine with vector index for pre-filtering. Only expressions covered by a corresponding B-tree or Bitmap index push down; others filter after vector recall. If business requires "only search documents after 2024" but the date field lacks index coverage, the filter runs post-recall, scanning full volume and killing performance.

IV. The Real Data Pipeline: Ingest, Backfill, Index, Retrieve

Multimodal ingestion isn't a one-time load. The complete pipeline has at least three serial, interdependent stages:

Write : images/documents/audio arrive; business attributes go to regular columns; embedding model generates vectors; data lands in the table.

Index : engine builds and commits B-tree / Bitmap / vector indexes.

Retrieve : query generates a vector, follows qualifying filter paths, recalls candidates, then reads corresponding text or BLOB content.

Data written but index not committed = not searchable. Model upgraded, vectors backfilled, but index not rebuilt = old and new vectors mixed, results drift. That's why every row must carry a model_version during upgrades. Query vectors and indexed vectors must come from compatible model versions; otherwise recall correctness is void. Upgrade sequence: backfill → rebuild index → switch query path — no shortcuts.

V. Lakehouse Retrieval vs. Dedicated Vector Stores: Who Exits?

Cold water: Paimon's multimodal lakehouse will not put Milvus out of business.

Paimon's core strengths: historical management, unified lake tables, data evolution, batch analytics. If your retrieval workloads are batch-oriented, analytical, or tolerate some latency in hybrid search, the lakehouse approach can eliminate the "copy data to vector store" layer.

But for strict online SLAs — high concurrency, millisecond latency, independent scaling — dedicated vector stores still have a place.

Typical coexistence pattern:

Paimon owns authoritative historical data, versions, data governance.

Vector store holds an online-search-optimized replica derived from Paimon.

The real engineering challenge becomes sync latency, delete propagation, model version alignment, and rebuild procedures after failures — not replacement. (Analogous to StarRocks querying lake tables vs. internal tables.)

Claims like "million-vector millisecond recall" are not default guarantees. Actual performance depends on vector dimension, data scale, index type, scalar filter selectivity, recall-rate requirements, hardware, and concurrency. Run pressure tests with representative data and let numbers speak.

VI. Key Takeaways

Object Table watches the door; Managed BLOB brings content in. Object Table queries object metadata but doesn't manage content; BLOB truly brings content under table management.

VECTOR type ≠ you can search. Three things stay separate: data type, physical storage, retrieval index.

Unified table ≠ unified everything. Embedding updates, index builds, model version governance, permission management remain engineering responsibilities — they don't vanish because "it's in one table".

Index visibility window is a production incident hotspot. Write ≠ searchable; index commit = searchable. Ignore the gap, get paged at 3 AM.

Lakehouse retrieval and vector stores aren't mutually exclusive. Data lifecycle and online search load inherently need different engineering solutions; coexist where appropriate, don't force a false choice for architectural purity.

Next (Part 28) moves to the retrieval layer: "Unified Multimodal Retrieval — One SQL for Full-Text, Scalar, and Vector Hybrid Recall," further analyzing responsibility boundaries among Paimon, StarRocks, DLF, and Milvus across retrieval paths, and designing verifiable hybrid retrieval architectures based on data freshness, recall quality, and online SLA.