MongoDB Day Amsterdam 2025 and the AI House Opening

Thursday 13 November 2025 started with databases and ended with a building opening. In the day I was at MongoDB Day Amsterdam 2025 at Venue Collective, Generaal Vetterstraat 55 (08:00–18:00 according to the registration in my calendar). In the evening I went to the AI House Grand Opening at Gustav Mahlerplein 5, the official opening of Prosus’s AI House Amsterdam.

This is a throwback post built from my photos and the slides on screen. Product facts are checked against mongodb.com and linked. Speaker names come from slides or from the event invite.

Arriving at Venue Collective. The green balloons made the entrance easy to find.

MongoDB Day Amsterdam 2025

The opening screen read “Hallo Amsterdam” with the MongoDB Day 2025 logo. The keynote speaker’s title slide named Massimiliano Marcon, Director, Product Management. After the keynote the day split into talks and hands-on workshops in several rooms. An AWS banner stood in the foyer.

The keynote room at Venue Collective, between two MongoDB Day roll-ups.

Helvetia: a critical insurance application on Atlas

The first customer story was “Successful Use of Atlas MongoDB at Helvetia Insurance: Modernizing a Critical Application for Motor Vehicle Insurance Certificates”. The title slide named Peter Györgyfalvay, Solution Architect / Software engineer, Helvetia Versicherungen, and dated the talk 13.11.2025, Amsterdam.

Helvetia’s session: a motor insurance certificate application moved to MongoDB Atlas.

MongoDB Atlas is MongoDB’s managed cloud database service. My photos only cover the title slide, so I can’t report the architecture details. The framing is still worth noting: an insurer calling a certificate system “critical” and putting it on a managed document database is the kind of reference that convinces other regulated companies.

From relational to document model, with Franck Pachot

The workshop I stayed for was “From Relational to Document Model: Data Modeling for MongoDB”. Its intro slide read “Hi, I’m Franck Pachot! Developer Advocate at MongoDB”. The ground rules were “Hands-on sessions”, “There are no stupid questions” and “Be respectful”, and there was a printed worksheet. Its Data Modeling Methodology for MongoDB had four steps:

1. Entities: identify the entities and describe their properties.
2. Workload: qualify and quantify the operations.
3. Relationships: identify and quantify them, then embed or reference.
4. Patterns: optimise the schema and avoid anti-patterns.

The definitions came first: “Data modeling is the process of determining how to structure and store data”, and the database schema is “the blueprint or the physical model”. Then came the slide that sums up the whole approach, “Contrasting data models”. On one side, the relational model: a “data-centric schema for many workloads, but involves complex mapping to business entities and application objects”. On the other, the document model: a “schema optimized for your workload”, shown as a customer document with a nested name, an array of addresses with GeoJSON points, a date of birth and a NumberDecimal retirement fund.

Relational is shaped by the data. The document model is shaped by how the application reads it.

The slide I found most interesting, as someone who also runs PostgreSQL, compared querying a PostgreSQL JSONB column with a MongoDB query on the same book-review data. This is what was on screen:

-- Querying a PostgreSQL JSONB column
SELECT title FROM books
WHERE other_data->'reviews' @> '[{"name": "John"}]';

-- GIN index
CREATE INDEX ON books
USING gin ((other_data->'reviews') jsonb_path_ops);

// MongoDB query
db.books.find(
  { "reviews.user": "John" },
  { title: 1 }
);

// Regular index
db.books.createIndex(
  { "reviews.user": 1 }
);

(The slide used name on the SQL side and user on the MongoDB side; the point is the same.) PostgreSQL can store and index the same nested data, but you query it through JSONB operators and a GIN index with jsonb_path_ops. In MongoDB the nested field is a normal dotted path with a normal B-tree index.

JSONB with a GIN index versus a dotted path with a regular index: the same data, two different query models.

The exercises used a library app (“The app has book and author details pages…”), and the attendees had to decide how to model the book–author relationship. The workshop ended with “Skill badge time”.

My take: I like that this comparison was made at a MongoDB event, and that it was fair to PostgreSQL. JSONB plus GIN is a perfectly good answer when documents are a side feature of a relational system. I wrote about stretching PostgreSQL in PostgreSQL Is More Than Relational. The deciding question is the one on the worksheet: what is the workload? If most reads fetch one aggregate (a book with its reviews, a customer with their addresses), modelling for that read beats normalising and joining on every request.

Skill badges

Between sessions MongoDB pushed its Skill Badges hard. The slide grouped them under data modelling, monitoring/tuning/automation, performance at scale, gen AI, security, query, aggregation, sharding, indexes, architecture and search. According to MongoDB’s skills page, they are “free, focused credentials”: you watch short videos and do hands-on labs, pass a 10-question skill check and claim a Credly badge. A slide also promoted the local Amsterdam MongoDB User Group.

MongoDB’s skill badge catalogue, with gen AI as a category of its own.

The A to Z of building AI agents

The afternoon workshop was “The A to Z of Building AI Agents”, run as an Instruqt lab. It started from first principles. Perception was defined as the “mechanism to gather information about its environment”: text, images, speech, multimodal input and physical sensors. “Planning without feedback: Chain of Thought” showed the familiar few-shot, few-shot CoT, zero-shot and zero-shot CoT comparison, with the tennis-ball and juggler arithmetic examples. Then “How agents work” traced a request (“What’s the weather in SF today?”) from the user to the agent, to the LLM, and out to a weather API, a search API and memory.

Left: chain-of-thought prompting as “planning without feedback”. Right: the agent loop, with tools and memory around the LLM.

The memory box is where MongoDB fits into an agent stack. Atlas Vector Search keeps vector embeddings next to operational data (“no separate databases, no data to sync”, in MongoDB’s words). MongoDB now also offers Voyage AI embedding and reranking models as part of its AI search and retrieval platform, after acquiring Voyage AI.

My take: for teams that already run MongoDB, putting agent memory and retrieval in the same database removes a sync pipeline and a second system to secure. That matters more than any benchmark. The design work is still yours: which memories to store, how long to keep them and what to send back into the context window. The data modelling workshop in the morning applies to agent memory just as much as to books and authors.

The AI House Amsterdam grand opening

In the evening I went from Venue Collective to Gustav Mahlerplein 5. I had already been to AI House in October for an evening on AI coding assistants with OpenAI, but this was the official grand opening. The invite promised “a great VIP speaker lineup”, and the screens matched it.

Fabricio Bloisi, CEO of Prosus, spoke before the panels. A first panel brought together Michiel Boots (Director General Economy and Digitalisation at the Ministry of Economic Affairs), Jelle Prins (co-founder of Cradle) and Sebastiaan Vaessen (Prosus Group Head of Strategy). A second panel had Kirill Skrygan (CEO of JetBrains), Nal Kalchbrenner (ex-Google DeepMind), Euro Beinat (Global Head of AI at Prosus) and Caroline Daniel (Partner at Brunswick Group, former editor of FT Weekend). The names and titles are from the stage screens. The screen spelled Skrygan as “Skygran”; I’ve used the spelling from the invite.

Fabricio Bloisi, CEO of Prosus, on the screen at the AI House Amsterdam opening.

Left: government, a Dutch AI start-up and Prosus strategy on one stage. Right: JetBrains, a former DeepMind researcher, Prosus AI and a former FT editor.

The mix on the two panels said a lot about what the building is for: a ministry, a start-up, a developer-tools company and the investor that funds the space. At the end of the evening the screens changed to a picture of giraffes in blue tracksuits and the line “The AI House Amsterdam is now officially open.”

The closing slide of the grand opening.

Six days later I was back at AI House for Agents in Production with the MLOps Community: my notes from that evening. I went back many times in 2026. See, for example, my posts on models, machines and robotics and the European Playbook evening.

Related

• Agents in Production at AI House and HOPE 2025
• PostgreSQL Is More Than Relational: ldap-pg
• AI House Amsterdam: Models, Machines, and Robotics
• The State of AI in Europe: Prosus Report