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, the slides on screen and short recordings I made of some of the sessions. Product facts are checked against mongodb.com and linked. Speaker names come from slides or from the event invite; where a speaker was not named on a slide I describe them by role. Figures from the stage are the speakers’ own claims.

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 was split between a MongoDB colleague who opened and closed it and Massimiliano Marcon in the middle, with a third colleague mentioned for the skill badges. Here is what I took from the recordings.

Agents need memory and state. The opening speaker framed agentic AI as moving beyond autocomplete and single-purpose chatbots. An agent sets an outcome, breaks it into steps and runs a loop of perceiving, deciding and acting. The LLM provides the reasoning, and the database provides what she called memory and state. Her example was a holiday booking agent: it knows your preferences from earlier trips, logs every action in the database and re-plans when a flight is cancelled. She listed four things the database contributes: memory, context, dynamic state and real-time data. She also cited an MIT study claiming that 95% of organisations see no return on their AI investment, and blamed weak memory and state design rather than the models. I can’t verify the study from the recording, so treat that as her framing.

Marcon on the database. He presented MongoDB 8.0 as the fastest-adopted release, with more than half of Atlas customers on it. According to him it gave 36% more read throughput on read-only workloads, up to 200% faster time series reads and resharding up to 50 times faster. For 8.2 he claimed unindexed queries 42% faster, array traversals about 20% faster and bulk time series inserts three times faster. The headline for me was queryable encryption gaining substring search (prefix, suffix and partial matches) on encrypted data. He also said that from 8.2 every incremental release ships across Atlas, Community and Enterprise Advanced, that long-term support for major releases goes from three to five years starting with 8.0, and that Atlas search and vector search become available for Community and Enterprise Server. On the AI side he explained embeddings and re-rankers, and pitched the Voyage models as the integrated alternative to running a separate database, embedding pipeline and re-ranker.

Modernisation. The closing section introduced MongoDB’s Application Modernization Platform, AMP, combining in-house tooling, a repeatable method and a team of engineers. The speaker said it makes conversion two to three times faster. The customer stories were a 200-year-old Swiss bank (she named Lombard Odier) that migrated code 60 times faster and cut regression testing from three days to three hours per feature, a fintech called Intellect that cut customer onboarding by 85%, and Bendigo Bank in Australia, 90% less development time for its core banking application. She was explicit that throwing a monolith at an LLM did not work when they tried it. The approach was to break the code into guarded chunks, generate and run tests, and loop build, test and repair.

My take: the ‘never throw a monolith at an LLM’ message is the most useful sentence of the keynote. Tests as the oracle, small chunks and a human for the hard cases is how I would run any AI-assisted migration, with or without MongoDB. The performance figures are vendor benchmarks, so I would re-measure them on my own workload before planning an upgrade around them.

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 management app (“The app has book and author details pages…”). There were three exercises: identify the entities and their attributes, estimate the workload, then model the relationships. The workshop ended with “Skill badge time”.

I recorded parts of Franck’s talk, and a few points stayed with me.

• Polymorphism, with guard rails. Paper books and ebooks can live in the same collection with a type field, because MongoDB has no need for the extra tables or the many nullable columns that SQL needs for the same case. But flexibility is not an excuse for a mess. Schema validation can require a title and an author on every document, so the application can rely on those fields. His advice was to prototype first and add validation when the model settles before production. Validation is per document and does not enforce references between documents, so the application has to check that an author still exists.
• Estimate the workload before choosing embed or reference. The worksheet had you turn figures such as three reservations per user per month into thousands of reservations a day, and 100 new books a month into about 6,000 in five years. His point was that the order of magnitude matters, not the exact number. Check the outliers too: one very popular book can have far more reviews than the average. The key question for any one-to-many relationship is “how many is many?”, and above all whether it is bounded.
• Mixing embed and reference. You can embed the first reviews and move the rest elsewhere once there are more than ten, or embed only the author’s name and keep the biography on the author. The cost is duplication, which is fine for data that rarely changes and a problem for data that changes daily.
• Evolving the schema without a big-bang migration. If you realise a book has several authors, you can switch a single value to an array for new documents, keep the old ones, add a version field and upgrade the old documents later. In a relational database you would migrate the whole table.
• Store the expiration date, not only a duration. An index on the expiry field lets a background job find expired reservations quickly, and a TTL index lets the database delete them itself. Franck used this to illustrate an application-first approach: an index is normally just a performance detail in SQL, but here it can carry behaviour, so deleting it has consequences.
• Use real date types. Don’t store dates as strings or Unix timestamps. He contrasted JSON, which has no date type, with BSON, which has more types, and a database check such as a due date that must come after the start date is a good use for validation.

The room asked good questions about a publisher with a million books (you would not embed them all, and the screen only ever shows a page), whether the reservation date is needed at all when the expiry date drives the logic, and whether you could store references on both sides of a many-to-many relationship (you can, if you maintain both).

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 lab presenter (not named on any slide I photographed) kept the definitions practical. An agent is a program that uses an LLM to reason, with tools that are small pieces of code (access to a ticketing system, a web search, files in object storage). It gathers data through the tools, feeds it back to the model and iterates until it has an answer. He explained RAG with an HR example: retrieve the relevant wiki page, add it to the prompt and let the model answer, and they argued that a bank would want to run such a model locally so private customer data does not leave the building. A ReAct example followed, where the agent answered a question about the Apple Remote by searching, reading the result and searching again. Their aside that MCP servers are “just agents in disguise” is a simplification of their own, not the specification. Finally they described a pattern used in MongoDB’s modernisation work: one LLM writes tests and another diagnoses why they fail, iterating until most tests pass, after which a human handles the hard remainder and the same two-model loop is used for the code conversion. This is the same approach as the AMP description in the keynote.

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. The MC for the evening introduced herself as a Prosus head of competition policy (a different Caroline from the panellist below). She said that since opening in October, AI House had hosted about 50 speakers and thousands of people, including a hackathon with more than 100 students the week before, with an agentic AI conference and an AI and policy event with Dealroom and the European Commission coming the following week. The programme was a welcome from the CEO, a first panel on AI policy in Europe, a second on AI entrepreneurship, then a ribbon-cutting and drinks.

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. From the recordings, the first panel was on AI policy in Europe and the second on AI entrepreneurship. The screen spelled Skrygan as “Skygran”; I’ve used the spelling from the invite.

Bloisi’s welcome was the part I recorded. He described himself as a tech founder who started a two-person company in Brazil and now runs Prosus. He went through 300 years of innovation cycles, from canals and railways to computers, in which a few champions emerge, and said Europe is behind the United States and China in global tech winners and “should be unhappy”. His diagnosis was ecosystem rather than talent: in Silicon Valley there are events every day, people know who is succeeding and learn faster. AI House is meant to be that meeting point in Amsterdam. He said the test events had been full every day, with about a thousand people in the first weeks, and that the space may need to double or more. He thanked early partners, including the MLOps Community and Tech Leap, and insisted the many Amsterdam initiatives are not in competition. Another speaker, whom I did not catch by name or title, closed with a call to build a Dutch AI ecosystem and avoid a new risky dependency on the US and China by excelling in AI niches.

My take: the ‘events every day’ argument is correct for engineers. I have learned more from the hallway and meetup network of a city than from any single conference, and a permanent venue is the cheapest way to build one. Whether it produces European champions is a different question that one evening can’t answer.

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