 Hello, everyone. My name is Carl and today I'm going to be talking about revolutionizing application architecture We're going to be talking about wasm in the database and why I'm super excited about it And also how I see wasm just helping out with so many parts of our ecosystem So just getting into it as I said, my name is Carl severe And I am a senior director of engineering at single store single source a database company We sell a distributed relational sequel database lots of buzzwords but what matters to this group is that single store embeds wasm so you can take any wasm module and Compile against the wazzy push it into single store and run that code directly inside of a massive distributed relational database And it works it works great, and I'm actually gonna be doing a live demo in a lightning talk So we're gonna see how all that goes So why put wasm in the database? I believe that wasm in the database allows us to build apps easier and safer and What does that mean? It means that we can basically make apps We can we can reduce the complexity of applications We can also ensure that things like state is handled in a more sort of atomic and transactional way Databases are really really good at this. This is sort of our bread and butter and Wasm is really good at moving compute to wherever the data is So if we combine these two ideas together, we can actually get something better than either idea by itself So let's talk about serious business So this is some serious business that I'm doing on my users and as you can see I'm looping through all my users and running some update functions. It's very important for my business I might have like hundreds of thousands of users and Ideally, I would say that most engineers writing this code expects this code to execute Transactionally you want all of your users to be updated or none of your users to be updated anywhere in the middle is very complicated But of course, we've all been here somewhere in the middle of that loop You know life doesn't go the way you think it goes And so, you know many many years ago people came up with a solution to this They said well we can use this thing called a relational database We can create transactions and we can pass transactions through all of our code and we can bundle up all these changes together and This does this works this does accomplish the goal of making this serious business operation Transactional and making it happen either entirely or or not at all and and when an exception occurs in this world We have some concept called rollback. We can reduce the state back to where it was before the transaction started Very very cool, but anyone who's written Transactional code and very large code bases know that this comes with a cost The cost is complexity and the cost is performance Not only do you have to now manage these transaction objects? Moving them through your code and this can be quite quite complex You might have to go through multiple libraries Maybe even third-party libraries to get the transaction object to use in all the right places But you also potentially have a lot of performance cost in this naive piece of code that I have here I'm now round tripping to the database for every single user in my in my data set This is cost that I sort of unavoidable because we need to be able to run Custom code custom business logic on each of these users and that business logic as of yet doesn't doesn't exist in the database We can't push it there But everyone would probably agree with me that this is this is complicated This is this is silly what we really want is we just want this We just want to write our code to the way that we originally intended it to be go through all my users run some Custom logic and then be done with it So this is the story of wasm in the database by putting wasm in the database We allow you to write code looks like this and we allow you to have that code intelligently pushed down into the engine and for the engine to actually understand that what what you're doing is looping through your users Running some update operation on each user and we want that to be done as close to the data as possible reducing any round trips that we don't need to do and That is a story of wasm and I'm very very excited You know a lot of the talks this morning have been forward-looking looking forward to where we see wasm going in This is yet another case We don't have everything that we need to be able to accomplish the goal I just set out but we're getting there we have the basic foundational building blocks and for that I'd like to do a cook live demo. Hopefully I have time And in specifically we're going to go to space So let me just exit out of the presentation So this is the wasm space program I do have to plug in my laptop because it's Linux and it's old and if I don't this will never render in real time so We're getting there and mostly looking okay The wasm space program is a demo that I created to show off what it's like to put wasm in a very large distributed system and Run a non-trivial workload in that system. So if we enter the wasm space program, we see one little solar system This is just running on my laptop Inside this system we have nothing let's let's go ahead and create some things So this is a little spaceship. I'm going to create I'm going to create some energy nodes right now My spaceship is doing nothing behind the scenes. This spaceship is represented by a literal row in a relational database That's all it is and every single second This relational database is essentially running that opera that serious business operation. I showed earlier It's looping through all the spaceships and running some wasm code on every single spaceship And that code is actually running inside of the engine right down beside the data. There's there's no other back-end service or anything like that So we have this spaceship. We want it to do something So let me open up my fancy fancy rust code And I wrote this macro because I didn't want to walk through a bunch of rust code and this is lightning cut talk So I have this macro which allows me to sort of fuse together a bunch of basic AI behaviors that I've already written So my strategy blank, which is the strategy that this spaceship is using has no behaviors. So I'm going to add in strategy chase energy Save that and and then we're just going to compile it. So this Compilation step is just you're going to quickly read through just cargo wazzy builds We're just doing a regular rust wazzy build and then we're just using the my sequel command-line tool to literally just upload that Wasm file to the engine that happens very quickly and Right away without doing anything else our spaceship has now moved to the closest energy node And if we create a couple more spaceships We can see that they they exhibit that behavior and that's because now that AI has Literally running that wasm code that I just uploaded the database This is really cool But I mean anyone we can obviously simulate a couple of spaceships on any any laptop. That's not very hard What might be more interesting is upgrading to a much larger cluster And so this is the real live wasm space program You guys can race me and try to go there before I before the demo completes in this live demo There is 32,000 solar systems and in each of these solar systems There's tons and tons of spaceships that all are living out their little spaceship lives inside of this massive virtual universe simulation and we can just jump anywhere in this demo and we see Spaceships doing various things and none of these ones are very exciting But we can just jump to like another solar system and see what's going on And in total this particular simulation so you can see there's spaceships running around over here This bit particular simulation has over a million spaceships that are running and simulated in real time every single 769 milliseconds to be precise about four and a half million wasm function invocations are happening in this cluster and That's all happening in real time every single operation allows a spaceship to see its entire region of space around the spaceship make Concrete AI decisions about what it wants to do issue those turns and execute it But even more interestingly is the entire turn that 750 milliseconds of operations that are going through and updating all the state runs in one transaction and That is the future of putting wasm in transactional systems I believe that this will make applications much easier and safer to build And that's pretty much my talk mind-blown emoji Every time Carl you're so good any questions for Carl. Is it a question in the back right? It looks like Hi So could you have the spaceships fire torpedoes and the torpedoes be affected by gravity? The answer is yes, but I didn't do that So here's my serious question. Um, so you're building wasm in the database and What about sequel and pill sequel so I sort of have that Oracle background How can can you compare what what you're going to be able to do with wasm in the database with what people use sequel and PL sequel for? Absolutely, it's a great question. So let's go ahead and look at all the PL sequel that is happening. So Right now our the limitation of single store wasm is that we can run wasm UDFs We can run wasm UDAs and TVFs Which are technical words and database speak for basically functions that operate over the data itself But we don't have yet the full procedural level sequel But that's next and so what you're seeing on the screen Hopefully is the run term function this runs a single transaction You can see we have start transaction here And this is a bunch of PL sequel which basically runs a bunch of update queries over the data and those update queries themselves Run wasm functions. So we are basically using a wasm single sort of push the AI down to like the lowest level To the actual sort of rows, but we still because we don't yet have that next level Which is the procedural level we don't have the ability to basically put this entire function in wasm But we want to do that. That's going to be the next stage Liam's having to do a little workout here This is really cool Reminds me a little bit of like what you'd imagine like a digital twin system before Do you envision using like component model and the newly announced worlds to describe an object and give it certain capabilities and characteristics and integrate that into the database. I Think that's a really cool idea So a lot of databases have looked at the idea if I understand your question correctly Like it's around using worlds to actually model objects within the database and be able to interact with them And other databases have used this sort of object model before they've they've tried to experiment Like I know that sequel server has like dotnet objects where you have like custom types with you can send and receive messages to them I think that's another story that was worth exploring here We are part of the bytecode alliance We are heavily involved in the component model and and we're trying to make sure that everything we do matches what you guys are doing So yeah, that's a great idea though back in the the link here around 2008 dotnet experimented seashell experimented with smartly or semi smartly moving code to the the database so trans having coders in line in your application program and moving segments that were relevant to the data to the database is That something you're exploring at the moment where you strictly focused on just moving an entire wasm module and it's got to be Called in some other way Fantastic idea, so we actually have a bunch of experimental work that is going on in the Python ecosystem Where you'd be able to have like a regular Python notebook and have Basically lambda functions trans dynamically push down into the engine So where we have you know a billion rows sitting in single store You might want to run some Python code over those billion rows to do some data science workload or something So we want to be able to dynamically sort of handle that and push that down. It's absolutely through. It's a it's another area that we're exploring This is fantastic. Could you please elaborate more about how wasm UDFs could be helpful for? Isolating transactions you mentioned that very beginning in that serious business and how will it affect the asset properties of database? So UDFs are the simplest case because fundamentally UDF is is stay in stay out They're they're not stateful themselves So we can actually just put them into our regular transactional framework which already supports running arbitrary code Except right now with single store before wasm you had to write the code in in the special pl sequel language Now you can basically run write your code and rust But the asset the atomic unit of like a function that takes them to stay in and return some stay out Just automatically inherit the transactional properties because it's it's it's I didn't put its state it's stateless, right? So we can rerun it we can automatically sort of put that in now as we get into the higher level So going back to this other the other question I received appeal sequel and procedural logic That's where it gets a little bit more tricky and that goes back to the last time I gave a talk here with Bailey We talked about wazid data and wazid data was the higher level like talking about the story of Basically bringing the transactional layer up into the wasm where you can actually have like just your rust code say like start transaction and Actually do like stuff that looks like almost like transactional memory at the application layer And we wanted to be able to do that type of stuff as well