StarRocks Stella 2.2: Unified Vector, Full-Text & AI Functions Across Lake Tables

On July 20, 2026, Alibaba Cloud released EMR Serverless StarRocks Stella 2.2.0, positioning it as an AI-native, full-modality lakehouse analytics engine. The core breakthrough is unified multimodal capabilities across both internal tables and lake tables: whether data resides in StarRocks' storage-compute separated internal tables or in open-format lake tables like Paimon, Iceberg, or Lance, users can now perform structured analytics, full-text search, vector search, and AI functions through a single SQL entry point, closing the loop from multimodal data processing to vectorization, multi-route retrieval, and analytical consumption.

1. Core Capabilities: Three Unified Abilities Across Internal and Lake Tables

1.1 Unified Multimodal Retrieval: Lake Tables No Longer Second-Class Citizens

Stella 2.2 aligns lake table capabilities with internal tables across three dimensions:

Full coverage of mainstream lake formats : Native support for Apache Paimon, Apache Iceberg, and Lance, allowing structured, semi-structured, vector, full-text, and binary blob data to be stored and managed uniformly in the lake.

Indexes co-located with data in lake storage : Vector and full-text indexes are stored alongside data files in object storage, decoupled from compute nodes. Cluster scaling and fault recovery require no index rebuilds, eliminating the operational pain of compute-side indexes.

Single SQL for hybrid retrieval : Supports "scalar filter + vector search + full-text match" multi-route hybrid recall without jumping between systems. For example, directly on a Paimon lake table: filter quality score > 0.85, perform semantic similarity search, and sort by time — all in one SQL.

Minimal lake table multimodal retrieval example

-- 1. Create Paimon multimodal lake table
CREATE TABLE quality_dataset.docs (
  doc_id BIGINT,
  title STRING,
  content STRING,
  category STRING,
  embedding ARRAY<FLOAT>
) USING paimon;
-- 2. Hybrid retrieval: scalar filter + vector similarity + full-text match
SELECT 
  doc_id, 
  title,
  cosine_similarity(embedding, ai_embed("高质量数据集标注规范")) AS similarity
FROM quality_dataset.docs
WHERE category = "标注规范" 
  AND MATCH(content, "标注质量")
ORDER BY similarity DESC
LIMIT 20;

1.2 AI Functions: LLM Capabilities Natively Embedded in SQL Execution

AI Functions are not new, but Stella 2.2 deeply adapts them to lake table scenarios, realizing "lake data stays put, SQL calls LLM directly", fundamentally avoiding security risks and operational costs of exporting data to external AI systems.

12 Built-in Standardized AI Functions Covering All Scenarios

All functions support both internal and lake tables, return structured types (VARCHAR/FLOAT/JSON/BOOLEAN), and can be naturally combined with JOIN, GROUP BY, aggregation, filtering, and other SQL operators.

Native Multimodal Support: Unified Vectorization of Text, Image, Video

Based on Qwen multimodal embedding models, supports unified vectorization of text, images, and video, natively enabling cross-modal retrieval (text-to-image, image-to-video):

Supports reading OSS URLs, Base64 encodings, and VARBINARY binary data stored in Paimon lake tables directly.

Engine side does not download binary files; only passes URLs to model API, avoiding extra transfer overhead and storage pressure.

Multimodal vectorization example

-- Image vectorization: directly read image URL stored in lake
SELECT 
  product_id,
  ai_embed_multimodal(product_image_url, 'image') AS image_vec
FROM paimon_catalog.ecom.products;
-- Cross-modal retrieval: use text description to search product images
SELECT 
  product_id, product_name,
  cosine_similarity(image_vec, ai_embed_multimodal("白色纯棉短袖T恤", 'text')) AS score
FROM product_vectors
ORDER BY score DESC LIMIT 20;

Architecture-Level Stability Guarantees

To prevent LLM calls from dragging down the analytics engine, Stella 2.2 implements a three-layer architecture:

Async Pipeline Execution : AI calls are pipelined with SQL computation, not blocking main query threads.

Resource-Bounded Control : Per-instance AI concurrency limit is configurable, preventing high-concurrency queries from overwhelming model endpoints.

Three-Level Flow Control : Built-in token bucket + circuit breaker + retry mechanism, compatible with DashScope interface specs; users need not worry about RPM/TPM limits.

Token Cost Optimization : Predicate pushdown filters data before AI calls; result caching eliminates duplicate calls; precise metering of every token consumption.

1.3 Engine Positioning Leap: From Pure OLAP to OLAP & Search Integrated Hybrid Engine

Stella 2.2's deeper significance is pushing StarRocks from a "single MPP analytics engine" to an "OLAP + Search hybrid retrieval engine", the core foundation for long-term AI data services.

In traditional stacks, enterprises needing BI analytics, text search, and semantic search simultaneously often deploy three separate systems:

OLAP engine (e.g., StarRocks, Presto) for structured aggregation, multi-dimensional statistics, report queries.

Full-text search engine (e.g., Elasticsearch) for inverted indexing, keyword matching, relevance scoring.

Vector database (e.g., Milvus, FAISS) for embedding similarity search, semantic recall.

Three engines mean triple costs:

Resource cost : Same data stored and indexed in three systems, storage amplified 2-3x, compute resources scaled independently, overall TCO remains high.

Ops cost : Three systems each have tuning, monitoring, troubleshooting paths; team skill requirements high; ops headcount grows linearly with component count.

Consistency cost : Data written to different systems has time lag; search results and statistical results have inconsistent calibers; cross-engine debugging chain long, root-cause difficult, data caliber unification hard.

Stella 2.2 deeply fuses full-text search, vector search, and scalar OLAP analytics into a unified execution framework, forming a native OLAP & Search hybrid engine:

Unified index build syntax and query syntax; internal and lake table development experience identical.

Built-in inverted index, multi-language tokenization, BM25 relevance scoring, meeting enterprise full-text search needs.

Supports hybrid recall of vector and full-text search (RRF/weighted fusion), combined with native OLAP for reranking and statistical analysis, one-stop "retrieve + analyze + aggregate" full process.

All capabilities share same compute resources, same data copy, same permission and audit system; no need to deploy separate search engine or vector database.

This evolution upgrades StarRocks from a "BI report dedicated engine" to a unified data service foundation capable of long-term support for AI applications: AI data consumption no longer requires cross-engine stitching, and enterprises don't need to add a new storage-retrieval system for every new AI scenario.

2. Underlying Technical Support: Why Lake Tables Can Run Multimodal AI Well

Lake table performance bottlenecks have long been an industry pain point. Stella 2.2's ability to run vector, full-text, and AI functions smoothly on lake tables relies on four layers of low-level optimization.

2.1 Native Reader: Order-of-Magnitude Lake Table Read Performance Improvement

StarRocks implemented a C++ native reader for Paimon/Iceberg, replacing the previous JNI approach, completely eliminating Java-layer type conversion, GC pauses, and row-column conversion overhead. Measured data shows Paimon MOR table read performance improved over 5x, high-concurrency point query QPS improved over 80%, greatly narrowing the performance gap between lake and internal tables.

2.2 Stella Lake Optimizer: Intelligent Lake Query Optimization

The Stella 2.x series includes a dedicated lake table optimizer. Through intelligent predicate pushdown, partition pruning, projection pushdown, and distributed manifest parsing, lake query QPS improved over 200% compared to open-source versions. For multimodal retrieval scenarios, the optimizer automatically decides whether to "filter then vectorize" or "retrieve then filter", choosing the optimal execution plan.

2.3 Multi-Level Caching: Mitigating Object Storage Latency

To address the inherent high latency of object storage, a three-level cache system is built:

Local file cache : Hot data files cached to compute node local SSDs.

Metadata cache : Table partitions, manifests, index metadata fully cached, avoiding repeated LIST operations on object storage.

Engine page cache : Page-level cache inside query engine; on hit, performance on par with integrated storage-compute.

Under three-level cache synergy, hot data query performance gap with internal tables is controllable within 10%.

2.4 Serverless Storage-Compute Separation: Optimal Elasticity and Cost

All capabilities are built on a serverless storage-compute separation architecture:

Compute resources auto-scale elastically with query load; zero compute cost when idle.

Storage based on object storage pay-as-you-go; PB-scale datasets need no upfront capacity planning.

Supports multiple compute groups for physical isolation; labeling, model training, BI analytics, AI inference workloads do not interfere.

3. Typical Deployment Scenarios: From Dataset Management to End-to-End AI Applications

Stella 2.2's unified multimodal capabilities precisely match core needs of high-quality dataset construction and AI application deployment, covering four typical scenarios.

3.1 High-Quality Dataset Full Lifecycle Management

Addressing PB-scale high-quality dataset management pain points, achieves "unified lake storage + multimodal retrieval + AI-assisted annotation + quality control" integrated solution:

Raw data, annotation results, feature vectors, quality metadata all stored in Paimon lake tables, no multi-system fragmented management.

AI functions automatically perform pre-annotation, content review, quality scoring, reducing manual annotation cost.

Supports semantic sample retrieval, version-based annotation history rollback, quality-score-based training set filtering; dataset management efficiency improved multiple times.

3.2 Enterprise Knowledge Base & RAG Systems

Traditional RAG architecture requires simultaneous setup of object storage, text chunking service, vector database, OLAP engine, LLM service — many components, long chain, poor data consistency.

Based on Stella 2.2, "one library solves all": documents directly ingested into lake, SQL calls AI for chunking and vectorization, hybrid vector + full-text retrieval, combined with structured permissions and auditing, full chain closed-loop inside lakehouse, no extra vector database needed.

3.3 Content/E-commerce Multimodal Asset Retrieval

Ad creatives, e-commerce products, short videos and other multimodal content can complete storage, tagging, retrieval, and analysis directly in the lake:

AI functions automatically classify images/videos, extract tags, recognize elements.

Supports text-to-image, image-to-image, image-to-video cross-modal retrieval.

Retrieval results directly used for statistical analysis (creative conversion rates, category distribution) without data movement.

3.4 Financial Ticket & Public Opinion Monitoring

For financial customer service tickets, public opinion texts, AI functions enable automated tagging, sentiment analysis, risk identification, while combining full-text and vector search for similar ticket clustering and historical case matching. All analysis completed inside SQL, no external NLP services needed, data security and compliance better guaranteed.

4. Architectural Significance for AI-Native Lakehouse

Stella 2.2's release is not just a version feature update, but an important milestone in lakehouse architecture evolving toward AI-native. Its core value manifests in three layers.

First, ends multi-engine stitching architectural pain, significantly reduces enterprise long-term costs . Pre-AI era, enterprises had to deploy OLAP engine, vector database, full-text search engine, AI inference service simultaneously to satisfy analytics, retrieval, inference needs — data redundancy, inconsistency, ops complexity, high cost. Stella 2.2 unifies four capabilities into a single lakehouse engine, using one SQL, one data copy, one foundation to support all loads; architecture complexity and ops headcount drop sharply. More critically, enterprises need not continuously stack new engines as AI scenarios expand; tech stack convergence brings very significant long-term TCO benefits.

Second, makes lake data directly AI-valuable, governance natively covers full pipeline . Traditional solutions require lake data to be extracted, transformed, exported, loaded into AI systems — long chain, high risk, governance policies ineffective. Stella 2.2 realizes "data doesn't move, AI comes to lake"; lakehouse native permissions, masking, auditing, lineage directly cover AI pipeline, truly achieving "develop compliant, write with quality checks".

Third, lowers AI adoption barrier, supports continuous AI evolution at scale . Full SQL pipeline lets ordinary data developers build AI apps without mastering vector databases, model serving deployment. More importantly, OLAP & Search integrated hybrid engine can continuously accommodate AI form evolution: from structured stats to full-text search, from vector RAG to multimodal retrieval, to future agent data services — enterprises can continuously iterate on same foundation, protecting existing tech investments. Enterprises can focus energy on data quality and business scenarios, not underlying engine stitching and ops.

5. Summary

EMR Serverless StarRocks Stella 2.2's core value is unifying the complete chain of " high-quality dataset construction — multimodal retrieval — AI analytical consumption " into the lakehouse foundation. Internal and lake table capability alignment lets enterprises avoid choosing between "performance" and "openness"; native integration of vector, full-text, and AI functions evolves the lakehouse from BI-era "data warehouse" to AI-era "intelligent data platform".

The positioning leap from pure OLAP to OLAP & Search hybrid engine determines this architecture is not a single-point feature for one current AI scenario, but infrastructure capable of supporting long-term enterprise AI development. For enterprises laying out high-quality datasets and AI applications, this solution's value lies not only in technical capability uplift, but in architecture simplification, cost reduction, and enhanced security/compliance — precisely the three core barriers to AI production deployment and scaling.

References

[1] Alibaba Cloud Developer Community: EMR Serverless StarRocks (Stella 2.2.0) Release: Multimodal Processing & Analytics Closed Loop, Unified Retrieval for Internal & Lake Tables

[2] Alibaba Cloud Help Center: EMR Serverless StarRocks AI Function Commercial Release

[3] Alibaba Cloud Help Center: AI Center

[4] Alibaba Cloud Developer Community: EMR Serverless StarRocks Stella Capability Interpretation: One-Stop SQL Practice

[5] Alibaba Cloud Blog: EMR Serverless StarRocks Lakehouse Multimodal Retrieval

[6] Juejin: EMR Serverless Stella 1.0 Technical Sharing: StarRocks Enterprise Kernel Major Breakthrough

[7] Juejin: Alibaba Cloud EMR Serverless StarRocks Skills Official Release