Philipp Krenn is head of developer relations at Elastic, where he helps engineers build search systems that work reliably on real data. His approach to AI-powered retrieval combines the established mechanics of information retrieval with vector search, careful evaluation, and a healthy skepticism of vendor performance claims.
Based in Vienna, Krenn worked as a research assistant at TU Wien and later on operations, deployment, and databases at ecosio. He also taught Java, cloud computing, and data technologies including Elasticsearch, MongoDB, Redis, and PostgreSQL.
He contributed to the open-source SilverStripe project through Google Summer of Code, participating as a student in 2007 and a mentor in 2012, and wrote a book about extending its content-management system. His GitHub projects include accompanying source code.
Krenn first used Elasticsearch in 2010 and joined Elastic in 2016. He progressed through infrastructure, developer advocacy, and regional community leadership before becoming head of developer relations. He has organized Elastic Vienna, ViennaDB, and Papers We Love Vienna, and describes developer advocacy as technical education, mentorship, and bringing community feedback into product development. In 2025, he co-authored an Elasticsearch history with company founder Shay Banon.
How he thinks about search
Retrieval starts at ingestion. Tokenization, language-specific analysis, stemming, stop words, positional information, and inverted indexes determine what a system can find before anyone submits a query. Krenn demonstrates how the wrong analyzer damages multilingual results, why removing stop words can erase meaningful phrases, and how fuzzy matching or n-grams increase storage and computational costs.
Hybrid search beats embedding monoculture. Dense vectors capture conceptual similarities but can return plausible-looking results even when nothing is relevant. Krenn combines lexical retrieval, dense or learned sparse representations, filters, and reciprocal rank fusion, adding semantic reranking when higher-quality scoring justifies the cost. His retrieval workshop also explains why BM25 scores are relative rankings, not confidence percentages.
Benchmark the actual workload. Krenn challenges vector-search benchmarketing built on cherry-picked datasets, outdated competitors, read-only conditions, and speed measurements that omit retrieval quality. Restrictive filters can even slow HNSW-based search by forcing inspection of more candidates. He recommends representative read-write workloads, precision and recall, regression monitoring, and Elasticsearch Rally for reproducible experiments, as detailed in his benchmarking talk.
His Spring AI and Elasticsearch guide applies these principles to retrieval-augmented applications. Krenn also acknowledges that PostgreSQL with pgvector may suffice for modest vector-only workloads; specialized search infrastructure becomes more compelling when hybrid retrieval, lexical relevance, scaling, or richer ranking are essential.
Follow a Star Wars quotation through tokenization, lexical scoring, sparse and dense embeddings, and hybrid retrieval to see what each layer contributes—and what it costs.
Contradictory vector-search rankings often begin with different workloads, configurations and quality targets. A useful benchmark makes those conditions explicit.
▶ Watch ↗