We're introducing Elasticsearch Columnar Mode: A new index mode that stores data once, in columnar form, with no redundant copies and no indexes the workload doesn't need. Not replacing the document model. Adding a second way to organise data alongside it, for the workloads where columnar is the right shape: logs, telemetry, metrics, security events, AI retrieval. One platform for search and analytics at the same level, on the same data. Tech Preview in 9.5, GA in 9.6.

🧵 Our BBQ at 1-bit/doc beats TurboQuant at 4-bit/doc on shifted data on ranking accuracy. At 1/5 the storage. We center on the segment centroid before quantization, so the bits go where they are actually needed for ranking. TurboQuant's Hadamard rotation can't exploit that structure.

30x faster than Prometheus on gauge averages sounds like a typo. It's not. Elasticsearch 9.4 rebuilt TSDS and ES|QL into a fully columnar metrics engine. Vectorized time series aggregations, zero-copy decoding, doc value skippers replacing inverted indices. The result at 1.4M time series: queries that took Prometheus 30+ seconds finish in under 2.

95 ns/vector vs 412 ns, Elasticsearch simdvec VS jvector scoring float32 at 32,500 vectors on x86. But the number isn't really the story here. The story is that at scale, past L3 cache, memory latency beats compute every time and simdvec is built just for that. At this depth, the kernel spends more time waiting for data than processing it. Prefetch too early and you've wasted the slot. Too late and you're stalling anyway. The window is narrow and simdvec times it right. Explicit prefetch instructions on x86 pull the next vectors into cache while the current batch is still scoring. On ARM, interleaved loads do the same job differently. Either way, the pipeline stays fed. Hardware counters show what that buys: 139K L1 cache misses drop to 19K. That's where the 4x gap lives. The simdvec team wrote up the full architecture and benchmarks, including their hardware counter data.

If your team lives in PromQL, you no longer have to context-switch to query your Elasticsearch metrics. The new PROMQL source command in ES|QL lets you run PromQL queries directly against Elasticsearch time series data, whether ingested from Prometheus Remote Write, OpenTelemetry, or other sources. Because it's built on the ES|QL engine rather than a separate query layer, PromQL output can be piped into filters, sorts, joins, and enrichments. That's not something you can do in Prometheus.

jina-embeddings-v5-text is here! Our fifth generation of jina embeddings, pushing the quality-efficiency frontier for sub-1B multilingual embeddings. Two versions: small & nano, available today on Elastic Inference Service, vLLM, GGUF and MLX.