Live vanaf Laracon EU 2026 spreken we met Andreas Braun, leider van het PHP-team bij MongoDB.
We duiken in databases, SQL versus NoSQL-denken, schema-ontwerp en performance op schaal. Andreas legt uit hoe Laravel-ontwikkelaars met MongoDB kunnen starten en wanneer een documentdatabase een logische keuze kan zijn.
Welcome to the Dutch Laval Foundation podcast. This one is for you broadcasting live from 2026 letter to you. >> Tada. >> Welcome to a surprising intro intro. >> Yeah, I didn't tell you at front because uh I'd like surprises. >> I appreciated that. >> Yeah. Yeah. So, we got a new outro as well, but I'm not going to do it now. >> Oh, that's that's cool. Yeah. >> So, people hang on the on the No. Okay. Well, uh, let's start. What is your name? Who are you? >> My name is Andreas. Um, and I'm just some dude that showed up at Laracon. >> Oh, yeah. Well, well, there's more to tell, I guess. >> Yeah, maybe. We'll see how much you can get out of it. >> So, can you tell a little bit about why you're here? What you're going to search for? What What >> Yeah. Um, so I was sent here by my employer. Um, we're here to basically talk to a number of engineers. Um, and find out how they're using MongoDB. Um, it just so happens that I work at MongoDB. I lead the PHP team. Um, so we maintain the driver uh for MongoDB in PHP that you would use to connect to MongoDB and send queries. And then we also maintain the framework integrations for Doctrine and Laravel. And it's for that second one that we're here. So that we're here to answer questions that people may have about MongoDB or the integration but also as an important feedback point for us so that we can ask oh you use it what you like about it what are you missing um that feedback loop is very important to us.
Okay cool and can you tell also a little bit about yourself what what your background is and stuff like that. >> Yeah so my background is in software engineering uh as in my dad was a software engineer um and so it was from a young age that I was confronted with this topic. Yeah. >> Um I have uh vivid memories of my dad telling me about SQL queries that he would write at work and he was really proud of those like really long and complex SQL queries and I think that's the reason I hate SQL with a passion these days and try to do something other than SQL. Yes. >> Okay. >> Yeah. Developers deserve better than SQL. I have stickers somewhere I think. Um I can give you one. Developers deserve better than SQL. Well, I for me it was a kind of magic thing that I was 13 with my dad and connected the first database to the front page website that I was building. >> Yes, I I >> really magic. >> I love it. It was It was really nice. And that kind of translated to me then getting into programming. We always had a computer at home, but it was a work device, not a toy. Right. You can't play games on a computer. It's a work device.
All right. Um, and so I was forced to write my own game because that was the only game that I would be allowed to play. Like, what are you doing here? Are you playing a game? Yeah, I'm testing it. I'm building this. Oh, that's fine. Okay, continue. And so that's how I started in Turbo Pascal back then. >> Um, and then discover graphics mode with like 640x 480 pixels and I learned how to actually do graphic stuff and how to save drawings in memory so that I could draw pages faster. It was really fascinating intro. So that is like the original software engineering background that I have. >> All right. And do you program or build queries nowadays as well? >> Um not as much as I'd like to. I'm getting back more into it. Um but becoming a lead of the team. There is more and more work that or work time that is spent doing things other than programming. So I managed to build a couple of prototypes over the last year or so. Um and now I'm getting back more into active engineering. >> All right. And um you told me earlier that you were sent for from your boss to here >> but does it actually went that way? You were sent to here or do you ask? Well >> no we we asked for that like so we tried to go to the big framework conferences which would be Laracon um US and EU.
You've been also to US. >> Uh I didn't go um I don't travel to the US for specific reasons. Um but Jeremy my colleague was there and Rishop as well. Um so we will have a presence at uh Laracon US until and until recently we also had sponsorship booths um to just have a spot where people can find us to us. >> Last year also >> yes correct we were here we had a booth. >> Oh yeah I saw you at the after video I guess because >> yeah you're kind of a >> Yeah. People can't really see it but you I'm kind of recognizable aren't I? Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. I I get that a lot. I don't know why. I don't know why. Oh, that's cool, man. All right. Yeah, you can see it on Spotify. Oh, well, uh, we're uploading video at Spotify, so you can see it. >> Oh, people can actually see me better. Try and look at >> I really like your color hair uh with my shirt as well as stuff. >> It is. It is. And I've I've had the red hair for like 3 years now. And I think if I got away with it, I would like if I did away with it, I think I would get so many questions about why I don't have red hair anymore that I just I just don't.
Yeah. >> I just don't. I like it. Cool. I like colorful people. Um, so let's talk about a little bit about uh MongoDB. >> Yes. >> So because it's not like the typical uh pick I should pick the typical choice I should pick with my new side project for example. So can c can you give me some uh >> um how do you say it? >> How do you choose your database for your side projects? >> How do I choose it? Well, for my current side project, I'm I had to choose uh Postgress because I wanted to to draw uh to host it on Laravel Cloud. >> Yep. >> So, I had to choose Postgress because it wasn't uh ready yet there. >> But I also um basically I had uh first install MySQL and then I had to transfer everything to Postgress. So, that was kind of like a shitty uh way, a shitty path. And it's interesting because I I started doing PHP in 2003 when the whole LAMP stack was still like the thing and the M always stood for MySQL. >> Yeah. >> And you started using MySQL and you learned SQL and how it works and it was a good and and easy introduction. >> Yeah. >> And then after that maybe you discovered there's Postgress that can do things that MySQL can't or you have fewer performance issues with that maybe. And then you choose one and you stick to it.
But usually it's always going to be some flavor of SQL database that stores data in tables and columns right >> so very often the decision is basically about you know which database do you think is better like I don't use my SQL anymore because they were bought by Oracle so I use Mariah now or um >> oh yeah >> I use Oracle because my company pays for Oracle licenses and so I just have a developer license that I can use for everything all right fine right but very often we don't choose database cases for what they give us, but rather based on well, yeah, it uses SQL, so I'm going to use it. >> Yeah. >> Right. >> Yeah. >> Um, MongoDB is very different. First of all, it's not SQL. It does have SQL interfaces, but that's not the way we expected to work with it because SQL wasn't actually made for that purpose. And if you've ever used JSON columns in Postgress with SQL, you know how pain of an how much of a pain in the ass it is to work with them. Um but in general MongoDB we call it a general purpose database. You can do anything you can do in a relational database. You do it in MongoDB as well and a lot more. The main difference is how you store your data.
And this is where newcomers to MongoDB struggle most based on the like >> there as well. >> Yeah. I've I've used MongoDB for a number of years before I started working there. Yeah. Yeah. >> And that was the one recurring theme that I had to teach people was stop thinking in tables. >> Stop thinking like >> that's hard, >> right? Like so let's let's do an experiment. >> Yeah. >> Let's say I want to store fuel prices, >> right? >> Um so I'm going to have petrol stations >> and those petrol stations sell different types of fuel, right? And every once in a while I get a price report and I need to know that at a certain point in time a certain petrol station had a certain price for a certain fuel type, right? Yeah. >> Tell me if I'm right or wrong. You already in your mental picture in your head, you already see a station table, you see a fuel table, and you see a price report table, right? That combines the two. >> Uh yeah, it's price report sometimes. Yeah. There are the the dates and times where the prices are. Yeah. >> Your brain automatically went to think >> Yeah. Exactly. Yeah.
But why? >> Because I was programmed to do like that. >> Exactly. Because we've learned it, right? Even even when I think of data, I normalize it in my head, right? You know that you're not going to write diesel and E5 into the price report as like the fuel, but rather you're going to have an ID. Yeah. >> Because you don't know if there's going to be extra fuels later, right? All of that process of database normalization since we used relational database so long, >> we do it out of the box. And you have to unlearn that when you use MongoDB, >> right? because you wouldn't store the data that way. You might because you want to store the canonical data um to then produce read models or whatever. But for reading, you would store it in a very different format that is much more read optimized because storage is cheap. So it's okay to store data multiple times and like store few prices both in its canonical form and then keep a list of the like last 20 prices that this petrol station had directly in the station document. >> Yeah. >> Right. That's cheap nowadays. What's expensive is the CPU time that I need when I join stations and fuel prices.
That's the expensive part these days. And so that is a big thing why people would then sometimes struggle with >> Mongab. Yeah. And I can imagine, but then again, I I can also really understand what you're saying now. >> Yeah. >> Okay. Sounds logic thing. It opens up for me a whole kind of new way of thinking about that. >> So, I have this sample project that I built and I kind of use as a demo because fuel prices in Germany, I don't know if you've ever driven in Germany, they change frequently. >> Yeah. Also here. Yeah. >> Yeah. Like in Germany on average 24 times per day. >> That's how often the fuel price changes. So I imported a data set that contains prices for two years. That is about 600 million prices. >> All right. >> For just two years for 16,000 petrol stations in total. And if you tell me you would like to have the price of petrol at a given station on a given day, I can give you all of the prices of that day, those 24 out of 600 million records in six microsconds. >> Right? That is how efficient you can make queries >> if you design your database correctly and you use the right technology. If I had to join a table with 600 million records, >> no way.
No, exactly. >> So, and that's that's the key that makes mongod so fast in many big data applications is that you don't store relational models, but you store the data in a much more efficient way. >> Yeah. Yeah. Well, yeah. in much more and efficient is not is another way of thinking here, right? Because you thought you were doing efficient. >> Yes. Correct. Correct. You you are doing it efficiently now like you're optimizing for space. You're optimizing for well yeah if this changes, right? Um another example another example that I like to make is um a contact book. You have a contact that has multiple email addresses, right? You always extract the email address to a different table because you can't store multiple email addresses in one document. But technically, you shouldn't have to. >> No. >> Right. They they should just be a list inside. >> Did you know you can do that with Posgress too? >> No, I did not know that. See, this is the thing and this brings us back because this is one of my main gripes about tools like the doctrine OM from Symfony and also Eloquin is that they abstract the database >> and you lose features. Postgress can store array fields. You can store an array of strings in a column in Postgress.
I I only know that there was JSON fields in Postgress for doing this kind of stuff. >> Well, you can also have more complex types. You could define an address type with a street, a house number, a postcode, and a city and store that in a column >> as an object. You don't even need to use JSON. But since a lot of other SQL databases don't support them for tools like the Doctrine or M and Eloquent, makes no sense to add that in because only Postgress could leverage this logic and they would have to polyfill for everything else. So >> yeah, >> that's just not feasible. >> All right. So if I if remembering our members here. So if I want to start a new side project, what what is then the the steps I have to do to to use uh MongoDB? >> If you want to use MongoDB, first thing obviously you need a MongoDB server >> which you can do either locally um for development purposes. You can always use a local server. Yeah, >> there is also a hosted version of MongoDB that you can use for production and it has a special shared tier where you can store up to 512 megabytes of data and that is free forever. Like you don't even need to enter a credit card when you sign up. Obviously it's to get you to see oh cool Atlas is so easy to set up and you're going to use Atlas for production as well but technically you don't need to install it locally. Make an Atlas account, create a free cluster and use that for testing purposes. So that takes care of the database itself.
Um and then in PHP you need to install a PHP extension that contains the driver code and that maintains the connection and everything and then we have a highle library on top that you would use to insert documents and read data. >> Um the reason >> within Laravel is >> so that is all still outside of Laravel that is what this library offers is the drivers CRUD API and we call it the common CRUD API. We currently have database drivers for 10 different programming languages and the API is the same in all of them. >> So you will always create a client that is your connection to MongoDB. From there you can you can get a database object and from there you get a collection object and that has methods like insert one, insert many, find, find many, update one, update many and delete one, delete many and those are the methods that you actually use. So you don't use a query language. you actually use an API to work with the database. >> All right. So, it's another way around this as well there. >> Yes. And it's a lot more designed to be used in programs. So, for example, generating a dynamic filter where you don't know what columns you're going to or what fields you're going to be filtering on is a lot easier because you don't have to do string concatenation like in SQL, but rather it's just an object with properties and values that is your query.
All right? >> So, it's a lot easier in programs. Um, but writing it obviously like writing a query in the shell is like programming. You're building a JSON object. So there's trade-offs there. >> Yeah. >> And on top of that driver, we maintain framework integrations that are designed to make people feel comfortable, right? So if I said, well, yeah, we're going to have the doctrine ODM in Laravel, people will not be comfortable because they're used to Eloquent. >> Yeah. And so we maintain a special connection class that connects to MongoDB and lets you use Eloquent with MongoDB. It also supports all of the various builtin mechanisms of Eloquent. And then the challenge we have is to tag stuff on top that does not exist in a relational database like embedded documents like the aggregation framework that where you can write extremely complex queries um that do a lot more than just filtering and grouping. Um but the main point um is to just have the basic functionality that every Laravel developer knows from Elephant to have it there and allow them to easily switch over to a different database and start using it.
All right, cool. Thanks. And how is um Elastic in comparing to MongoDB? What's the difference between that kind of >> So I I'll try to answer the question because since I don't typically build applications last time I used elastic was quite a while ago and 10 years ago as well. >> Yeah. So I still know it as basically a search service where >> I index things and then I get records back. What I've seen from talking to people at various conferences is what people are starting to use eloquent um sorry elastic for is that they have their canonical data in my SQL or posgress and they have it neatly normalized um and then they create read models and basically have a JSON object like they would return it from their API and they store that in elastic >> right because it's much faster >> um so sure I think you can use elastic like a database and I I honestly don't know enough about Elastic to make an informed choice and say whether that's good or not. >> But you don't need to use two different services for that. You could just store your data like that in the first place. Like why are you storing it normalized if the more efficient way to handle this data is in that JSON form that you are storing in elastic? Why wouldn't you do it like this in the first place?
Yeah. All right. Okay. So uh 15 years ago I was working at a hosting company and we had to have all the firewall starts within one database. So this was really easy uh like the the database structure is really easy time the a time frame and then there's a coming in and out um >> IP addresses and what the kind of bandwidth is using stuff like that >> and then we need to something that was really >> easy and but also really fast to uh plot out different graphs and stuff like that. >> Yeah. Um so we then were uh checking or if MongoDB was a solution or elastic was >> then I choose I I think yeah I I was the one that choose had chosen that one but I chose an elastic because but but then again I had three weeks of grinding out how this actually works because that's pretty hard to wrap your head around. >> Yep. Oh, >> and when you have three weeks to decide between two technologies that you don't know, >> Yeah. >> you're screwed. >> Actually, yes. >> And when you have three weeks to decide between a technology that you know a little bit and one that you know nothing about, you may as well stop and just use the one you know a little bit and try to make it work, right? Because you're not going to learn the ins and outs of that.
Just think of you starting to work with a SQL database. >> It took you way more than 3 weeks to figure out how to do things properly. like your first your first things in databases are usually crap and slow and would completely collapse when you put a thousand rows in them, right? >> Um so that's increasingly difficult and there is no problem with starting with one tool because it just works and then a few weeks, months or years later figuring out well this has reached its limits. We need to find an alternative, right? You could have spent six months evaluating more, choosing MongoDB, but then you lost six months of revenue and you were bust. Yeah. Did you win anything? No. >> Nope. So, the important thing is that you actually looked for technology and decided which can I use instead of just jumping to the one thing that you know that is my SQL, right? So, that is already the most important step. >> Yeah. Okay. So and if uh users now for uh um uh could what's the first step that they could take to to use MongoDB but are there some uh uh you say yeah we have a community YouTube or is there >> yes so >> there is the MongoDB university um which is a learning center um it's completely free so the courses are completely free you can do a certification you can even even get a become a MongoDB PHP certified developer for a certain price Um I'll let people decide whether they want certifications or not. But we have courses >> both on like getting started with MongoDB, what the document model is.
Um we have courses on how to properly design schemas and to show you different schema patterns that allow you to store data efficiently. >> There's a getting started course for Laravel on there. There's an entire learning center that will help you build your first Laravel application. And there's courses on how to self-host MongoDB and how to manage a shardy cluster. Um, so that you don't have to pay a cloud company to host MongoDB for you, but host it yourself because it is source available. I'm not going to get into the SSPL. It's source available and the community edition you can host on your server for free and not have to pay anybody anything. >> That's a good story. >> Yeah. Yeah, that's always good. And so yeah the that developer center is very good or the learning center we also occasionally do blog posts um on various things. At the moment, I am publishing a blog post series on how to scale to a billion documents in Symfony. Um, simply because that's my background, but I'm currently looking for people that are experienced with Laravel and want to give this challenge a shot in Laravel to produce the same application with Laravel so that it can be used as a learning tool for >> Okay, shout out for everybody who's listening, right?
Yeah. Yeah. Yeah. >> Um, >> we're talking about you guys. >> Yeah. Please uh help me help me learn suck at it, >> right? Cool. Hey, and uh talking about the event, uh what is the thing that you want to see? What you what's your highlight? Uh >> um so for me, I've been going to conferences for so long that I only go to the hallway track. So essentially what we're doing here um is what I do all day. I roam the halls. Occasionally there is the talk that I go to because I think the topic is interesting or because I know the speaker and I'm there for moral support. Um but mostly it's me going around to the sponsor booths talking with people there um answering questions um about anything and just basically talking to anybody who's willing to listen. >> Now in that in that one where are we? So >> thank you very much. >> Thank you very much for having me on. >> Nice. Okay. Um shout out to everybody who's going to use MongoDB and where can they find you if they want to find you on? So my GitHub handle is Ala um like an old Greek poet. Um that's the one I use. >> Other than that um I am very active in the symphony slack. I don't know if Laravel has a Slack or if they >> we have a Dutch L foundation Slack channel. But uh what what we going to do in the show notes? Do you have LinkedIn or something like that?
I have a LinkedIn. We can put my LinkedIn in there and my Twitter account that I don't use anymore because I still call it Twitter. All right, I understand. Okay. Well, uh, thanks a lot. >> Awesome. >> Thank you very much. Let's go. >> Thanks for listening to the Dutch Laravel Foundation podcast. This one is for you. Broadcasting live from 2026