VeloDB Cloud v26.1 Is Now in Public Preview, Powered by Apache Doris 4.1

VeloDB Cloud v26.1 is now in public preview, powered by Apache Doris 4.1. This is the first time Apache Doris 4.1 runs on VeloDB Cloud, and the release includes community-contributed hardening and fixes across the 4.1 release.

v26.0 made VeloDB a Unified Analytics & Search Database. v26.1 extends that foundation in 4 directions: vector search that scales to billion-level, full-text search that runs as plain SQL, OLAP queries that run up to 22.6% faster on standard benchmarks, and compute-storage separation improvements that cut object storage costs by up to 90% in high-frequency import scenarios.

Public preview means v26.1 is open to every VeloDB Cloud account today. You can create a v26.1 warehouse from the console and run real workloads against it. Preview versions carry preview terms rather than the GA production SLA, so plan accordingly for anything that depends on one. What you send us during preview shapes what ships at GA.

Apache Doris 4.1 against 4.0, across the four areas this release touches.

Here is what's new.

Vector search at billion-scale

Apache Doris 4.0 introduced the HNSW vector index. HNSW is fast, but it holds the full index in memory, and memory gets expensive past tens of billions of vectors.

Doris 4.1 adds 2 new index types:

• IVF clusters vectors into buckets, then searches only the relevant buckets. It handles larger datasets than HNSW with lower memory usage, trading a small amount of recall for a large speedup.

• IVF_ON_DISK follows the design of Microsoft's SPANN paper, combining in-memory caching with filesystem caching. It cuts index build overhead compared to DiskANN and gives teams a practical path to Billion-scale vector search. On the compute-storage separation architecture that VeloDB Cloud runs on, it prunes and recalls at very low cost.

INT8, INT4, and Product Quantization compress the index memory footprint to 1/4 to 1/8 of the original, with a small recall trade-off.

The graph structure is a rounding error. The vectors are the bill, which is why every lever in 4.1 acts on the vectors themselves.

Query performance improved too. The new "Ann Index Only Scan" lets vector queries skip I/O on raw columns, making vector index queries up to 4x faster than 4.0. On a 16-core, 64GB machine with 1 million vectors, Doris sustains around 900 QPS at 97% recall.

Full-text search as plain SQL

The search() function brings full-text search directly into SQL, with syntax compatible with Elasticsearch query_string. If your team is migrating off Elasticsearch, the query semantics carry over.

SELECT model_name, COUNT(*) AS error_count,
       PERCENTILE_APPROX(latency_ms, 0.99) AS p99_latency
FROM inference_logs
WHERE search('level:ERROR AND error_msg:"CUDA out of memory" AND NOT module:healthcheck')
  AND log_time > NOW() - INTERVAL 1 HOUR
GROUP BY model_name
ORDER BY error_count DESC;

search() supports TERM, PHRASE, WILDCARD, REGEXP, PREFIX, NOT, and NESTED operators, BM25 relevance scoring with storage-layer TopN, and multi-field search through best_fields and cross_fields. Query-tree compilation and DSL-level caching keep repeated searches fast. Because search() returns a boolean predicate, it works inside joins, window functions, and subqueries. One query can filter logs by keyword, aggregate the results, and join them against business tables.

100MB JSON documents for long-context AI

AI workloads produce long context: multi-turn conversations, agent execution traces, tool call logs, transcripts. Doris 4.1 stores single JSON documents up to 100MB, so a complete session lives in one row. Filtering, aggregation, and JOINs run against those rows directly.

This removes 3 pieces of infrastructure from a typical AI data stack: the separate object store for raw context, the consistency logic between metadata and content, and the segmentation-and-reassembly code.

Storage for wide, sparse AI data improved as well:

• Segment V3, a new storage format, decouples metadata from the file footer. On a table with 7,000 columns and 10,000 segments, segment open is up to 16x faster with up to 60x lower memory usage.

• Sparse sharding and sparse cache spread long-tail JSON paths across multiple physical columns and cache the hot ones, keeping ultra-wide VARIANT data fast to read.

• DOC mode keeps raw JSON at write time and defers sub-column extraction to compaction, cutting write amplification for trace and event data that is usually retrieved as a full document.

Double-digit OLAP gains

Compared to 4.0 on standard benchmarks, Doris 4.1 is 22.6% faster on TPC-H, 19.1% faster on TPC-DS, and 14.3% faster on SSB. Benchmark was tested on AWS with c7a.metal-48xl instances.

Optimizations drive these improvements:

• Aggregation pushdown through JOIN aggregates each side locally before the join, shrinking the data that reaches the join operator. Performance on the target benchmark set improved by more than 200%, and nearly 1/3 of cases improved by over 100x.

Same answer, same hardware. The join handles 40,000 rows instead of 1.2 billion.

• Grouping Sets optimization completes the finest-grained aggregation first, then derives the other groups from that result. Benchmark performance improved by more than 10%, with a maximum gain of 160%.

• Nested column pruning reads only the subfields a query touches, for internal tables and for external ORC and Parquet data. Benchmark performance improved by more than 60%.

• CASE WHEN optimization merges and eliminates branches and pushes down extracted enum values. Average benchmark performance improved by more than 200%.

• Condition Cache and Query Cache reuse per-segment filter results and intermediate aggregation results across repeated queries. Condition Cache alone improved complex query workloads by more than 10%.

Compute-storage separation, tuned for the cloud

VeloDB Cloud runs on the Doris compute-storage separation architecture, now in production at more than 2,000 companies. 4.1 improves it where cloud customers feel it most: cost, elasticity, and cold performance.

• Object storage cost drops by up to 90% in high-frequency import scenarios, through node-level request merging that reduces request counts and small files.

Object storage is cheap per byte and expensive per operation. High-frequency import pays the second number.

• Scaling completes in minutes on clusters with millions of tablets, because scheduling now runs independent of global tablet counts.

• File cache state is durable and visible. Cache metadata persists across restarts, and the new information_schema.file_cache_info system table exposes block-level cache detail, so you can locate hot data and diagnose cache imbalance with SQL.

• Cold queries got faster through prefetching built on Doris's page-scanning semantics, and the default compression codec is moving to ZSTD for better storage efficiency and cold reads. A caching layer in front of the Meta Service raises metadata throughput, and pre-decoded binary encoding cuts runtime decode cost.

• FE memory dropped by 30%+ at millions-of-tablets scale.

Lakehouse: full Iceberg read and write

Doris SQL now covers the full Apache Iceberg lifecycle: INSERT, UPDATE, DELETE, and MERGE INTO on Iceberg V2 and V3 tables, including Deletion Vector and Row Lineage, with no external engine required. Apache Paimon DDL runs through Doris SQL as well, with write support planned.

Lake query performance improved alongside:

• Iceberg sorted writes generate sorted metadata for file pruning, improving TPC-DS performance on lake data by about 15%.

• Manifest caching drops complex metadata resolution to the hundred-millisecond range under frequent queries.

• The new Parquet Page Cache improved ClickBench performance on lake data by about 20%.

Operations improved too. Cache admission control sets data cache rules by user, catalog, database, or table (with hot reload and EXPLAIN visibility), so cold data stops evicting hot data. A new Parquet metadata table function exposes row group and column statistics through SQL for pruning diagnostics. MaxCompute catalogs add CREATE TABLE and INSERT support for the Alibaba Cloud ecosystem.

Batch, ingestion, and SQL surface

The remaining changes round out this release:

• MERGE INTO handles INSERT, UPDATE, and DELETE (upsert) in one standard SQL statement, simplifying CDC merge workflows.

• Sequence-aware multi-stream updates let different streams update different columns on the same primary key table, each merging by its own sequence field: real-time upserts and offline backfills run concurrently. Routine Load adds flexible partial updates on non-key columns.

• Write paths got steadier and easier to audit. The MemTable flush pool adapts to cluster load for higher write throughput, and Stream Load records can land in the audit log system table for unified query history and debugging.

• Recursive multi-level spill-to-disk covers JOIN, aggregation, and sort operators. Doris 4.1 can run every TPC-DS 10TB query on a single BE node with 8GB of memory.

• New SQL constructs: UNNEST for arrays and nested JSON, recursive CTEs for hierarchies, ASOF JOIN for nearest-match time-series joins, and a native TIMESTAMPTZ type that stores UTC and converts to the session time zone automatically.

• Streaming ingestion: continuous import jobs from S3 detect and load new files automatically, and MySQL and PostgreSQL real-time sync covers both full initialization and incremental updates.

Try the public preview

VeloDB Cloud v26.1 is in public preview today on AWS in US East (N. Virginia), US West (Oregon), US West (N. California), AP (Hong Kong), AP (Singapore), and EU (Frankfurt). Any account can select it from the console, with no waitlist. For availability in other regions, contact us.

Apache Doris 4.1 was built by the Apache Doris community. Join the community on Slack to help shape the next release.

Try the VeloDB Cloud v26.1 public preview today.