 Hi, I'm Kanan, and I'm chief architect of Ion Xtreme. So let me start with some little bit of introduction, actually, so I'm one of the world, almost extinct breed of traditional database guys who treated relational normal form as a religion, and followed that with the new changes and new distributed databases didn't get me until I saw the asset properties in a distributed database, actually. So finally, I was like, OK, I'm on board. Now I want to get into the distributed database kind of thing, actually. So Ion Xtreme is a part of Ion Xtreme so we've been around for 15 plus years, and we've been in the database development and support kind of work, actually. So right now, we've been focusing more on foundation DB, and mainly our focus is on developing data stores for AI and for different models, actually. That's what our focus is right now. We've been creating data stores for creating models, deep learning models, and our go-to database has been foundation DB now, actually, for so many other reasons, and one of them is the flexibility in the design of the schemas and stuff, actually. So that said, I want to go over one example of what we are doing right now, how we are using foundation DB. So we've been developing this application for one of our incubation startups. So it is for a swim app, actually, in our mobile app, when you record a swimming using AR and AI, so it gets all the statistics of a swim, right? Or it directs the strokes, and it gets the velocity of the swim in instantaneous velocity of the swim, and it gets the strokes, and all the basic statistics of a swimming by just recording it, right? So this, we developed it, and we started creating a model for it, right? We used FDB to store the data, because there's a lot of extensive data in it, so we want to use that to train the model. We've been using Tuuri Create to train the model, and the model become really huge, because we are trying to capture all the scenarios possible for a swimmer, right? But swimmer here, swimmer in Japan, swimmer in Europe, they are different. Their swimming styles are different. Things are different. We only tried to build one model for them. It was too hard, and also we want to keep the model on a mobile device, so we can't have a bulky model size as well. So we ended up creating micro models, basically, right? So where we put in a basic model which works like 80% for a swimmer, and then when they record, when they see the strokes, when there is minor changes to it, they can manually adjust the strokes or adjust the data. And we capture that change every night, and when they sign up for it, basically. So it sends back to the cloud those data, and we spin out a one docker setup, right? Because we don't want that to attach to be shared by any other data. We don't want to mix it with any other data. So we create one stream of process, basically takes the images and data and trains the model and validates the model as well. So we have a set of data to validate it because we don't want to create a model just because somebody sent the data, right? So we want to validate it and then send an updated model back to that device. And then that cycle goes on until it gets perfect. We have validations saying, hey, you know what, the success rate is so high, so we don't have to train anymore, or when the changes happen, then we train again. So this is the model we've been using right now, so where we use FoundationDB for the orchestration, and also as lower footprint of FoundationDB in the docker setup to use it to train the models, actually, right? So this is the one scenario we've been using and it's been effectively working for us in a way. And so we have been, other than this, we've been using in Actek and Solar and the main things as well. Okay, so that's all I want to share today, actually. So we are a database support and services team, so if you need any help in development or support or even creating some POCs, please reach out to us and let us know in the end. Thank you. Thank you.