ElasticON Amsterdam 2025: Forge the Future Recap

On Thursday 30 October 2025 I went back to the Beurs van Berlage in Amsterdam for ElasticON Amsterdam. The 2025 theme, on every screen and banner, was “Forge the Future”. A year earlier I had been in the same building for ElasticON 2024, which I wrote up in my Elastic Meetup and ElasticON Amsterdam 2024 post.

The timing was interesting. Elastic had announced Agent Builder on 21 October, as a technical preview on Elastic Cloud Serverless, “coming soon in version 9.2”. Two days later Elastic 9.2 shipped, with Agent Builder, DiskBBQ, Streams and smarter ES|QL lookup joins. So the Amsterdam audience was seeing all of this a week after release.

This is a throwback built from my photos. I’ve kept to what was on the slides and signs, and I’ve checked the product facts against Elastic’s own pages.

The keynote hall filling up, with “Search AI” on the big screen.

The agenda board

The digital agenda board split the day into five colour-coded tracks: Keynote Sessions, Search Track, Security Track, Observability Track and Lightning Talks. The rooms were the Effectenbeurszaal, Graanbeurszaal 1 and 2, the Administratiezaal and, for lunch and the reception, the Grote Zaal.

The ElasticON agenda: Agent Builder, ES|QL, Streams and LLM observability all had their own slots.

The session titles tell you where Elastic was putting its effort:

• Agents: “The future of building AI agents in Elasticsearch: Agent Builder”, “From Search to Intelligence: Building Autonomous Agents with Elastic MCP and Amazon Bedrock”, and “The AIOps Agentic Stack: Building Autonomous AI Agents with Elastic and Google’s Vertex AI”.
• ES|QL: “Explorations in ES|QL” and “Pipe dreams: A year of ES|QL innovation, search, and Joins”, plus “Present and future of Elasticsearch queries”.
• Observability: “Streams: The future of solving problems with logs”, “A new era for Metrics in Elastic: Performance, Prometheus, and more”, “Simplifying OTel data ingestion and analysis with Elastic”, “No more AI visibility gaps: LLM Observability in Elastic”, and “The road towards enterprise observability at TVH”.
• Security: “Architecting the SOC of the future: Overcome data deluge and hidden threats”, “Accelerate threat intelligence by including Attack Discovery”, and “Adapting to AI in security: Best practices for autonomous AI and human interaction”.
• Search: “Outsmarting the Enemy: Elevating Enterprise Search with Generative AI”, “AI powered autosuggest”, and “Semantics and scale: Elasticsearch vector database enhancements”.

The day ended with “Closing Remarks & AWS Hackathon Winner’s Presentation” at 17:25 and a networking reception from 17:45 to 18:45.

Opening keynote: Ash Kulkarni and Steven Schuurman

The opening keynote put two people on stage together: Ash Kulkarni, Chief Executive Officer, and Steven Schuurman, listed on the slide as Co-founder & Former CEO. My photo is from the back of the hall, so I’ll leave it at that rather than guess at what was said.

Ash Kulkarni (CEO) and Steven Schuurman (co-founder and former CEO) opening ElasticON Amsterdam 2025.

AWS: “Innovation Multiplied”

Next on the main stage was Michael Rambold, Chief Technologist at AWS, with “Innovation Multiplied: How Elastic and AWS collaborate on Generative AI and beyond”. The partnership slide listed three points under “The most secure, extensive, and reliable Global Cloud Infrastructure”:

• Long-term thinking and working backwards
• a 5-year Strategic Collaboration Agreement focused on GenAI
• 2024 AWS Global Generative AI Infrastructure and Data Partner of the Year

A quote from an AWS vice president on the same slide mentioned a “shared commitment to standards like Model Context Protocols” for agent-to-agent interactions. It also said Elastic’s search capabilities would be available with Amazon Bedrock through the AWS Marketplace.

The Elastic and AWS slide: a 5-year GenAI collaboration agreement and a 2024 partner-of-the-year award.

Observability with Elastic on Google Cloud

Over lunch I joined “Unleashing AI: The Power of Elastic on Google Cloud”, which the agenda put in the Administratiezaal at 12:45. One slide repeated Elastic’s claim that it was named a Leader in the 2025 Gartner Magic Quadrant for Observability Platforms “for the second year in a row”.

The main architecture slide was titled “Observability with Elastic on Google Cloud: AI-Powered with Search AI”, with the claim “50%+ better at RCA, resolution w/ 50% lower cost”. It showed:

• Ingest: logs, metrics, traces, profiling, custom KPIs, SLI/SLOs and alerts, and runbooks, with OpenTelemetry as the ingest path.
• Processing: an ML platform with “zero config AIOps”, accurate insights and automated analytics, on ESRE as the unified datastore.
• A RAG-based AI Assistant with Gemini: automated problem solving (RCA, remediations, correlations), answers (summaries, explanations, guides, examples, queries, parsing), cost optimization (time, effort, MTTR) and security.

Elastic on Google Cloud: telemetry in, relevant context out to a Gemini-based assistant.

My take: the useful part of this diagram is that runbooks and SLOs sit next to logs and traces as inputs. An assistant that suggests remediations is only as good as the runbooks it can retrieve. I’d also treat “50% lower cost” as a vendor claim to test on your own incidents.

TVH: the road towards enterprise observability

In the next session I joined, the whole audience wore wireless headphones. The slides carried the TVH logo, matching “The road towards enterprise observability at TVH” in the 13:30 slot on the agenda. The speaker’s name wasn’t on any slide I photographed.

TVH’s phase 1 plan and the cost results, with the audience on headphones.

Phase 1 – Observability platform had four steps:

1. a target architecture exercise, with Elastic Cloud as the key solution for logs and traces
2. analyse usage patterns
3. consolidate the existing platform
4. define policies, set guardrails, and actively optimise cost through the right data retention policies and infrastructure

The Optimizing cost slide gave the numbers: steady data ingestion of up to 2.5 TB per day. Changing data retention allowed infrastructure downscaling, and gave an immediate 10% cost reduction. A chart over four quarters peaked in Q3 and then dropped.

The Key takeaways slide said:

• organisation-wide adoption of observability requires a transformation
• use observability to bridge the gap between business and IT, and teach teams to self-organise around their own KPIs
• consider accelerators such as communities of interest and a dedicated SRE
• understand your stakeholders’ requirements and usage patterns before setting infrastructure and policies (Elastic professional services can speed this up)
• empower developers through self-service, but with fit-for-purpose policies and guardrails

My take: retention is the cheapest lever in any log platform, and it’s a policy decision, not a technical one. Getting 10% back right away at 2.5 TB/day, just by agreeing who needs which data for how long, is the usual pattern: the engineering is easy, and getting the data owners to agree is the hard part.

Semantics and scale: vector database enhancements

On the main stage, “Semantics and scale: Elasticsearch vector database enhancements” picked up where the int8 and BBQ talk at the 2024 meetup had left off.

It started with “What is a Vector Database?”: it stores and searches high-dimensional dense vectors. The core building blocks were managed embeddings, ANN index structures (graph-based and clustered), efficient storage and quantisation, filtering and hybrid search, and reranking on full-precision vectors.

“Our Progression”: from BM25 to semantic_text, quantisation and DiskBBQ, to hybrid and (future) managed multi-modal.

The “Our Progression” slide summed up Elasticsearch’s search features in three columns:

• Text and metadata: lexical search, BM25, Weak AND (WAND), feature fields.
• Semantic: semantic text (“just like text … with an embedding model behind the scene!”); bring your own vector (dense, sparse, rank); automatic quantisation (BBQ, int8, int4) with rescoring; HNSW and DiskBBQ.
• Hybrid: retrievers and ES|QL, Reciprocal Rank Fusion, normalisers. Under “Managed Multi-modal (future)”: text and image, then audio, then video, all embedded into one vector.

A-CORN for filtered graph search

The next slide was about a common problem in multi-tenant search: filters in ANN structures. The slide’s answer was “A-CORN adaptive pruning on HNSW graphs”, which “reduces candidate explosion” and is “applied automatically based on the selectivity of the filter”.

A-CORN: filtered kNN on HNSW without exploring the whole graph.

Elastic’s Search Labs post on filtered HNSW search with ACORN-1 gives the background. In Lucene 10.2, filtered kNN search became up to 5× faster. The new algorithm only kicks in when 40% or more of the vectors are filtered out, which is what “based on the selectivity” means in practice.

Vectors out of _source by default

The last slide I photographed was “Excluding Vectors from _source”. From 9.2.0, vectors are removed from _source by default, which reduces disk and snapshot size. The bar chart compared a baseline of 52.3 GB with 19.3 GB with excluded vectors.

Dropping the duplicate copy of each vector: 52.3 GB down to 19.3 GB in Elastic’s example.

The Search Labs post Lighter by default: Excluding vectors from source explains the details. The setting is index.mapping.exclude_source_vectors. It defaults to true only for newly created indices, so existing indices are unaffected. Elasticsearch “rehydrates” the vectors when it needs them for partial updates, reindex and recovery.

My take: this is the same lesson as int8-by-default in 2024. Defaults now depend on the version an index was created on. If your application reads embeddings back out of _source, test that path before you roll a new index template to production.

The session ended with a “Competitive Benchmarking” chart that I couldn’t read from my seat.

The expo floor and partners

Between sessions the Beurs van Berlage’s main hall was the expo, with Elastic stands around the floor and partner booths along the sides.

The expo floor from the balcony.

The partner wall thanked AWS, Microsoft, Google Cloud and Tines at the top, with Atos, Corelight, Devoteam and others below.

Me at the partner wall.

In the afternoon I stopped by BASE Conference 2025 at StartDock Singel (I wrote about BASE Conference 2024 last year). In the evening I went to the SRE NL meetup, which has its own post: SRE NL Amsterdam 2025: Learning from Incidents.

My take: from search engine to agent platform

Put the agenda next to the 9.2 release notes and the direction is clear. Elastic wants Elasticsearch to be the place where agents get their context, with ES|QL as the language that defines the tools. In 2025, agent sessions appeared in the search, security and observability tracks alike, not in one AI corner.

What I’d do with it:

• Try Agent Builder on a copy of real data first. I later tested Agent Builder’s MCP endpoint and ES|QL tools on a local cluster, without an LLM, in Elastic Agent Builder MCP: Tools and Workflows, No LLM. Treat the tool definitions like any other API: version them and give them least-privilege keys.
• Keep the observability basics boring. TVH’s story was retention policies and guardrails, not AI. That’s still where most of the savings are.
• Re-check vector index assumptions on each upgrade. Quantisation, DiskBBQ and _source exclusion are all defaults that change storage and recall without anyone choosing them.

Related

• Elastic Meetup and ElasticON Amsterdam 2024: BBQ and int8
• AI Native Netherlands at Elastic: Agents, MCP, Workflows
• Elastic Agent Builder MCP: Tools and Workflows, No LLM
• SRE NL at Elastic: OpenTelemetry and Your Brain’s Biases
• SRE NL Amsterdam 2025: Learning from Incidents