Operationalizing ML/AI with MemSQL

Bandwidth for changelog is provided by Fastly. Learn more at fastly.com we move fast and fix things here at Changelog because of Rollbar. Check them out@rollbar.com and we're hosted on Linode Cloud Servers. Head to linode.com changelog this episode is brought to you by DigitalOcean. Digital Ocean's developer Cloud makes it simple to launch in the cloud and scale up as you grow. They have an intuitive control panel, predictable pricing, team accounts, worldwide availability with a 99 point uptime SLA and 247365 world class support to back that up. Digital Ocean makes it easy to deploy, scale, store, secure and monitor your cloud environments. Head to do co changelog to get started with a $100 credit again.co changelog. Welcome to Practical AI, a weekly podcast that makes artificial intelligence practical, productive and accessible to everyone. This is where conversations around AI, machine learning and data science happen. Join the community and Slack with us around various topics of the show@changelog.com community and follow us on Twitter. We're at practicalaifn.

Welcome to Practical AI. This is Daniel Whitenack. I'm a Data Scientist with SIL International. Normally I would be joined by my co host Chris Benson who is a principal AI AI strategist at Lockheed Martin. But he's in the midst of some family health related things so he's taking the time that he needs. But we're definitely excited to chat about a really interesting topic today actually in our Slack channel. I remember some conversation a couple of weeks ago where we were discussing the issue of hey, I trained my model, it works great on my data, I evaluate and it all seems good. But then when I try to integrate this into code, the performance is actually really terrible and it's kind of a mismatch between production things and I think that we're going to be able to get into some of those things today. Today we have as our guest Nikita Shamgonov who is the CTO of MemSQL. I'm really excited to talk to you today Nikita. Welcome.

Happy to be here. Like Daniel said, my name is Nikita. Actually I'm co CEO and founder of MemSQL. I don't mind the confusion. I started as the CT and I took over as CEO in 2017.

Gotcha.

And recently about a year ago brought a co CEO Raj Verma with the thinking that we're going to take the company public.

Gotcha. On that note, why don't you give a little bit of maybe the Background first of yourself. And then we can get into maybe a little bit of the background of memsql. I think that would be great context, definitely.

I've spent my career in data management and databases. Specifically. I came to the United States after finishing my grad school in St. Petersburg, Russia and joined the SQL Server engine team. Went from very research oriented life and work to basically system engineering. When you build databases, it's actually a very different cadence versus using databases. When you use databases you think about things like performance, you think about SQL as the API to the database and then you think about reliability and uptime. And when you build a database, you think about quality, you think about the life of somebody who is using the database and how you make that lives easier. And obviously you think about performance and scalability and how the database user or developer can achieve that performance and scalability.

It sounds like an interesting transition from the sort of academic world to the systems engineering world. Was it a hard shift for you or was that sort of focus on the user and reliability? Was that something that you were already kind of passionate about going into that work?

I was very passionate about engineering in general. What I loved about building databases that the product. The database engine is like a computer science in a box. It has algorithms, it has data structures, it has system engineering. You interface with networking, IO, CPU caches. You need to be aware of the computer architecture in order to build world class software. So that certainly resonated a lot. And that was the core premise of why I wanted to start working on world class industry products. And then from there the passion to the user came in. And over time, just that curiosity about building new things and breaking ground and entrepreneurship came through the years while working at SQL Server. Mind you, during that time Microsoft was going through a cloud transition. Everything that we're seeing today at scale, at that time, all of that stuff was being born, being conceived and major architectural choices were made. Some of them were right, some of them were not right. So that's my big company background. And then I switched and joined Facebook. And in fact one of the premises of me joining Facebook was not to make a lot of money or because that was a pre IPO 2010, actually move to the Silicon Valley and meet the kind of people I will later start a company with. And what happened is that as I walked into Facebook on day one, I met my future co founder Eric. And relatively shortly after, just within six to eight months, we started MemSQL and I left Facebook.

Oh, that's a wild ride, I guess moving to a total new place, experiencing Facebook and that culture, especially at that sort of stage, and then founding something. So maybe describe a bit how that happened so fast. The idea from MEMSQL and the sort of motivation that this was something that was really needed. How did that occur?

Yeah, so distributed systems at SQL Server, we always knew that was the future, right? Especially as you go into the cloud transition at the time. Back in 2008, 2010, Microsoft had a flagship product, SQL Server, which is a single node database system. Very, very good, very, very powerful. Really proud. I worked on this one. The main competitor, Oracle had distributed systems at its disposal. Oracle Exadata and Oracle rac. And the way the database market is structured is that the top tier workloads that have high performance requirements, high availability requirements do require distributed systems. And Microsoft didn't have that. And so that top of the market Microsoft was losing to Oracle then. Actually, I think they mostly caught up right now. But then architecturally, single node databases are very hard to change and make turn them into a distributed system. That was some of the kind of moonshot projects that my co founder and CTO Adam worked on at Microsoft. And that moonshot project didn't succeed. When I walked into Facebook, the need for distributed systems became apparent because every Facebook workload is that high level, high end workload. And sometimes it's from the reliability standpoint, sometimes it's from the scale standpoint. Most of the time the scale standpoint, because back in 2010 I think Facebook was on the march to cross a billion active users. So that was on everyone's mind, that was everyone's goal. How can we cross a billion active users? And obviously history shows that Facebook had blown through that goal quite successfully.

Were they trying to architect something internally to deal with that or was it sort of an open problem when you were there?

It's more than one system for something that is so big as Facebook turns out that all the data workloads are split into categories, some of them are data lakes. And Hadoop basically got a lot of advancements at Facebook. Some of them are operational powering facebook.com and multiple data management technologies are on the critical path between typing facebook.com and actually seeing the newsfeed. There's a separate data management solution for messaging, newsfeed and List Goes on. And within that also there's a whole bunch of kind of point solutions for various analytical workloads. Right. One is for time series. In fact, there's a startup called SignalFX who took some of the ideas and then the Folks from Facebook left started that company that was recently acquired by Splunk. And then there was a system called Scuba that gives you real time analytics and a lot of ideas that influence mean SQL roadmap as well. So long story short, lots and lots of data management systems and data management workloads inside Facebook, but each and every one is a distributed system. And so that pervasiveness of distributed system were captivating it like really validated the thinking that the future of database systems is distributed. And that's how we started mte.

Awesome.

And we started this as a memory, hence the name.

Yeah.

Now in fact the name is kind of limiting because MEMSQL is evolved way past being in memory and memory only. It's the version one that was in memory and single node. But very quickly we expanded to a distributed system built tiered architecture from memory to disk and now we expanded it to S3 or other object stores.

Yeah, I'd be interested to hear a little bit about. I mean you kind of gave a sense of the initial founding and some of the initial ideas. I'd be curious as far as right now with memsql, could you just give a sort of high level view of the sorts of things that people are turning to MEMSQL for kind of the consistent things that you see really people getting value out of and then maybe some of the newer things that are enabling maybe new sorts of workloads that you didn't even anticipate in those early days.

Definitely. So first of all, databases are very long game. The most successful database products on the planet, which are Postgres, MySQL, SQL Server and Oracle are all 30 plus years old and we still use it today, which is basically if you turn into any other piece of technology, that's not the case. Technology is very transient. We're building something and something new comes in and completely disrupts what's there before. But database seems to stay for a long time.

Yeah, I think in my experience from working at the different places I've encountered postgres, a lot I've encountered. Right now I'm working on a team that's using SQL Server for certain things. Of course I've encountered certain things like Mongo or other databases that are like the NoSQL or those sorts of databases. But I think like you were talking about the user experience, it always seemed like to me the natural user experience. And you gain a lot of power with that SQL interface to the database Relational.

Yeah, for sure. The vision is a single pane of Glass to all your data and all your workloads. But when you start peeling the layers and understanding what would it take to deliver on that vision, you start understanding how you scale storage, how you scale compute, and how you scale both storage and compute for your low latency operational workloads. Think about powering your apps and loading a web page and the results need to come back to you. And ideally sub 100 milliseconds to running what is called big, expensive analytical queries that scan large volumes of data to give you insights. Those insights could be reports, those insights could be information, analytical information, which is also called decision support. You need to make a decision, so you need to know what works, what doesn't. You need to know how your sales are doing in this state versus the other state, this product versus that product. And so that is a continuous process of evaluating and looking at data and understanding, driving insights out of data. So the interesting piece about what I just described is that for your operational needs, you need a SQL database like Postgres, like MySQL, like SQL Server. I mean, you don't need it. I mean, you can use a MongoDB, you can use a NoSQL database, but you need an operational database. Right. Let's just put it this way. And for the majority of workload today, people are using relational databases that speak SQL. And for a smaller part of the market, they use no SQL databases, which is more preference and user experience and whatnot. And then for an analytical system, people use data warehouses, Teradata, Snowflake, BigQuery. And the interface to those databases is also SQL. Yeah, and what you just started the podcast with is like, oh, I trained my model against the data that sits in the data lake or a data warehouse, and now I need to put it in production. And my, you know, I have data quality, data consistency issues. My performance is not the same. A lot of that comes from the underlying data management. And if you like really peel the layers, it comes from the fact that you run this very same model on top of data and data management systems that are different.

Yeah.

And one can argue that while they're different, they got their reasons for them to be different. But there is a more contrarian viewpoint here. That is, we live in the world of clouds, where things are abstracted away from you and that gives an opportunity to build, ideally a serverless interface that speaks SQL and that gives you access to all your data and gives you access to all your data for reporting capabilities, for low latency capabilities, for operational workloads. And that would allow you to never leave your data universe as you go and move from one workload to another. And that can be huge, right? That can be huge. Because whatever data you trained, for example, your example, whatever data you use to train the model, lives in that ocean of data and that data is easily accessible to you. Then you train the model. So now you need to convert new data that is incoming or you know, marry new data to an old data and convert it into pixels, which is your app or a website or whatever. And that can be done right there off of the same data set you've been operating on, which is certainly not the case today. Today you have a data lake, a data warehouse and a number of operational databases that can be integrated by a third piece of software like ETL tools or integration tools, which just generates a lot of complexity and a lot of that can be simplified. If you imagine a world of having a serverless SQL low latency API to all your data, that's the vision where we driving towards and this is a multi year, probably multi decade, memsql is 9 years old today. So it's going to be a multi decade kind of life's work. But the workloads that we see emerging and the new workloads that are enabled by a system like this are real time analytics and real time decision support. When you need to kind of go back and look at the history of what was happening to make a real time decision and do it at scale as well. So that is something that we see a lot in financial markets. MemSQL is a give or take $40 million run rate company with 70% growth. We just had an article on TechCrunch where revealed our numbers and good amount of that revenue is coming from financial markets. And if you think about it, that's what happens there. There's constant stream of information that's coming in, modifying that data state that you have. And you need to make decisions about buy sell, you need to make decision in wealth management, you need to make decisions in portfolio management and trading. But also you need to make decisions in various systems that for example monitor something that's very, very large. So in Morgan Stanley, for example, it's a trading system and we monitor this trading system providing decision support to, oh, should we provide some sort of maintenance, should we reroute our trades, you know, all of those things. That's what memSQL is used for today. And that's new. Like we didn't have a system on the market that had those capabilities before.

I'M Jared Santo, JS Parties producer and one of nine regular voices you'll hear on the show. We are a party themed podcast, so fun is at the heart of every episode. One way we keep things fun is by mixing it up and trying new things. We play games like JS Jeopardy.

This gives you access to an outer function scope from inside an inner function. Oh, I think that Nevermind.

Global scope.

Incorrect.

Yeah, I didn't think so.

Debate hot topics like should websites work without js?

I'm going to appeal to authority and read some quotes at this time.

Okay, I've lost complete control of this panel. Go ahead, Ross.

The first quote. No code is faster than code.

Discuss and analyze the news.

Yeah, this reminds me of when you're.

Playing Pokemon and you have like, you.

Know, an electric Pokemon versus a water Pokemon and you try like an attack.

Share wisdom we've collected over the years.

To be honest, a lot of what we rely on is pretty garbage. And like, I mean, I wrote some of it, so it's okay.

Like I can say this interview amazing devs like John Resig and Amelia Wattenberger and a whole lot more. Oh, and did I mention we record the show live? We do. You can be part of the hijinks each and every Thursday@changelog.com live. This is JS Party. Please listen to a recent episode that piques your interest and subscribe today. We'd love to have you with us.

I definitely liked where you're going in terms of describing the sort of single window to all of your data via the SQL interface. And I know that we talked a little bit, so we kind of touched on the AI and machine learning elements of this and how they fit in. You're talking about going on this journey to create the single window of single interface to all of your data. How did AI and machine learning workloads start to cross your path at MEMSQL and start to be something that you felt like needed to be part of the strategy of how you were building out the system?

Yeah, this is a great question. When we did our analysis, we discovered that about 20 to 30% of all the workloads that memSQL support have some sort of machine learning or AI angle to this.

Oh, wow.

So this is a very large number. And when we looked at it, we always wanted to have AI dedicated AI capabilities in the system and we certainly use AI internally to make certain decisions around workload management, query optimization. But the fact that the modern workloads and obviously people put modern workloads on then SQL have a lot of AI and ML capabilities was eye opening to us.

Yeah. In those cases that you noticed, was it like people that were like you were saying using memsql to do kind of large queries to prepare their training data for an AI model?

Actually both.

Both. Okay.

And like two specific examples. Well we have a great integration with Spark. So we have a Spark MemSQL spark connector that allows gives you very fast data exchange between MemSQL and Spark. Fast mean multi cluster to cluster. So like a multi channel bus between the two. We noticed that people put all their data into MemSQL, grab it through Spark store models somewhere else. So we don't take part in hosting models. So this is the first part. What people like about memsql is that two way path for data exchange between MEMSQL and Spark. You have something in Spark, you can persist it in memsql you have something in memsql you can pull it into Spark. And MEMSQL is a world class party processing engine so you can send SQL query to it to do the kind of the first pass and slice and dice data before it gets fed into training algorithm which MEMSQL itself doesn't support. It's just the backbone for that data. And the second use case that we started to see being pronounced is well people build apps on top of memsql and those apps have models, evaluate models real time and they need to usually there's some sort of an SLA for an app, either displaying this information to the end user or the app is completely kind of back office and they just crunching data and for that they need to pull data from somewhere, run this data against a model and based on the results that you see from that model, do something. Typical examples fraud and we do in transaction fraud detection for some of the major banks where the SLA is 40 milliseconds to make a decision if that particular transaction is fraudulent or not. And in order to make that decision you need to go, you know, you have a model that's model's already trained, then you need to grab some data for that specific account, go back and look at the previous, you know, thousand transactions, feed those transactions against the model and then the model will tell you it's a fraudulent transaction or not. So MEMSQL is supporting use cases like this.

Yeah, that's really interesting.

So again both sides of the spectrum, both just providing basically a data lake or data warehouse capabilities, put all your data in one place, let Data scientists play with that data and use whatever data science tools, the tools du jour. Should it be Spark?

Most talk SQL.

Yeah, yeah, yeah. Should it be Spark? Should it be Pandas? Should it be TensorFlow or PyTorch? Whatever. We provide very, very fast data exchange to whatever frameworks you use. And the second one is, oh, I want to put my model into production, so I'm going to register that model somewhere in my, you know, either in Kubernetes, SageMaker, you know, there are tools for that now and it's a rapidly evolving space, but it all starts with data anyway. So you need to have a data backbone and you need to have data management system with system of record capabilities in order to provide uptime, low latency, all of those things. And where it's going is we're thinking to keep building world class integrations with systems that both data scientists use for training and engineers use for putting models into production to enable that exchange. From a push button standpoint, given you have a model, put that model somewhere, tell MIMSQL about that model and you'll be able to consume that model either from SQL through user defined functions or through an application query. The model query the data and the application provides the glue.

Okay, so yeah, I was curious about that piece. So it sounds like right now this sort of workflow is you have an application like a Python application or whatever it is, you load your serialized model into memory and then when it's time to fulfill a user request, then you make a SQL query against memsql, get the data you need, run it through your model and respond to the user. Is that about right?

Yeah, that's how it works today. And where it's heading is this will still be probably 50% of the use cases because certain things you still want to control and write very, very custom logic. Yeah, but we want to make MEMSQL aware of models that are stored in a particular repository and being able to through SQL to run data through those models and return results back into memsql.

Yeah, that's really interesting.

The reason that's useful is that sometimes you want to run that model against a very large volume of data. If your application, row by row pulls data from a database, runs it against the model, gets the results, potentially stores it back in the database, that is an extremely inefficient way. But what you can do is you can establish a similarly to Spark Connector, a multi channel bus with optimized data formats. You know, we're thinking Apache Arrow or something like this where running a model against a billion records should be, you know, one or two second proposition.

Yeah, that's awesome. I'm thinking of a facial recognition use case or something like that where you may want to run compare the embedded representation of this image against thousands and thousands and thousands or maybe even millions of records that you have in your database that are reference faces from your facial recognition or something like that. Am I following the right sort of path here?

You are. And we have use cases like this where people store feature vectors in the database. In a way, people run this use case in memsql from the do it yourself kind of way. MemSQL supports Vector Tensor operations as a built in. And obviously facial recognition models not all the time, but often is represented as kind of tensorflow dag, I would say that evaluates and the individual nodes in the DAG are vector map. Right. They're not something that's spectacularly complex. It's a vector dot product, also known as a scalar vector multiplication. Right. So MEMSQL does that and we have customers that in production do facial recognition over millions of faces to enable things like somebody walks into a supermarket and I want to custom tailor the experience for that person, or security systems and airports. And what happens is there's a camera. The camera looks at the next phase, the feature custom logic extracts a feature vector out of the new face. And then you run a query against MEMSQL that says give me all the records where vector product of feature vectors stored in the database multiplied by the vector you just received is, you know, between 0.9 and 1.

Yeah.

And that gives you all the similar faces. And because MemSQL is a distributed system, even though it's, you know, it's a brute force way of doing it, there's no index. You just go literally run the dot product against, you know, millions of faces stored in the database. But because everything is so tightly optimized, you can still run this within 50 to 100 milliseconds.

Yeah, that's crazy.

And that's running in production, right? It's running in production. And like I said, for both kind of government security use cases as well as things like walking into a grocery store and the system suggests, oh, grades that they usually buy are not in the system right now, but go buy this something else.

Gotcha.

Yeah.

So I was curious as we were talking and we were talking about, I guess that's a computer vision use case. And I'm thinking about like the types of data that are involved in Machine learning and AI workloads and we've got, you know, of course imagery and video. We've got a lot of natural language processing going on these days. And you know, some of these types of data I've dealt with in SQL databases before, of course, numbers and strings and that sort of thing. But I wouldn't typically think of like, oh, I'm going to store this image or video or like an audio file or something in, in a database. So are you thinking that in the longer term a good workflow around this is that you're storing the sort of feature vectors or embedded representations of maybe text or audio or maybe like spectrograms of audio via like the tensor built in or those sorts of things? Or are there other ways around that?

This is a great question to me. It's what it is now and what is it going to be as we go? And I will give you a very kind of product centric answer to this question. What would a product manager think? And they always start with the user. The user in this particular case is again data scientists from the training standpoint and an engineer from building an app standpoint. I think today data scientists and with the tools that the data scientists use, it's a lot more natural to store this data in a data lake, basically in S3. Yeah, just it's bottomless, it's files, it's cheap and all the tool sets work out of the box. And the reason to put that data into a database is only when you get some sort of additional benefits to that. When you put structured data, the benefits are obvious, the aggregations. So it enables low latency access to that data and enables very fast aggregations and reporting. So you can slice and dice that data in the database before pulling the data out and use your custom tools to provide reporting for unstructured data. The only benefits that I see are governance Database can provide that unified access layer to all your data, but it doesn't give you any compute benefits over that. Right. You get a kanika and say wash. So that's the way we think about it right now, as well as exploring, I think what's going to happen in the future that databases just like MEMSQL will give you an option to access that data that's stored in the data lake and in the file system through the database API with the benefit of marrying that data and like really understanding metadata, potentially building a full text like index against that data so you can marry that data with the rest of your enterprise data, which is usually relational. Gotcha but do not yank the direct access to the file system because that's what data scientists do every day and they would be confused if you remove that access pattern from them.

Yeah, I guess on that side of things, we kind of talked a lot about the operationalizing of models. On the training side, now we're kind of talking about access to files and all of those things. And you were saying you have the One interface or the integration with Spark. You know, for me, a lot of times I store everything in S3. Like you're saying, it's very natural for me. I just like, say I want this file and I'm going to use it. But there's definitely issues that come up very quickly on that front too. I know Even like this morning, like trying to like deal with, you know, like 200 gigabytes of audio data and like the. I was just sitting around for a while and making coffee is not very productive or, or fun to deal with those sorts of things. When you say, like, I guess on the training side of things, you have maybe people that are used to the Spark interface can do that. Are there other ways with MEMSQL that like. Like, if I want to access my audio files in S3, is there a way to do that with memsql outside of Spark? Are there other sorts of interfaces I can use?

Not at the moment.

Okay.

But I will share some of the thinking. Right?

Yeah.

So right now there's a lot of technology we're building around just relational data and providing that single pane of glass window into all your relational data. That's where we kind of the strongest when we think about S3, we think how we can offload all the data that's not currently touched by the system into S3. We call this thing bottomless and making databases bottomless. Like if you think about Postgres, Postgres is not bottomless. Right. It's bound to the amount of hard drive that you run Postgres on. But we want to make it completely bottomless and very, very cheap. And S3 is probably one of the cheapest way to store data in the cloud. And we have things like MINIO that is one of the cheapest way to store data on premises when specifically around that pattern that you described. I have an audio file and it's 200 gigabytes, and it's a pain to go and transfer that file from one device to another, and it's a pain to Download it from Ms. 3 to your local storage and all those things. So the thinking There is again is through integrations, if memSQL is aware that here's the file in that particular format stored in S3, and then you want to somehow either bring computation to data, or you want to access to a subset of that file, and only that you want to bring into your training environment also either running on the cloud or somewhere else. So we want to enable those things. That's where it stops so far. That's where our thinking stops so far. We certainly aware of the scenarios and we're aware of some of the pains that people go through. The place where we think MEMSQL can add value is versioning, because you oftentimes need to run and rerun experiments. And the model, it's not just the model, it's the model and the data that has been trained on that's really the unit that is consistent. And if the data changed, the model might be rendered obsolete, might not be. So just versioning makes a ton of sense from the ability to run experiments, verify experiments, share and exchange the models and data across data scientists. So I think that's where we can provide a nonlinear amount of value over time. Foreign.

News is the best way to keep up with the ever changing world of software. We track, log and contextualize the coolest projects, the best practices and the biggest stories each and every week. Make changelog.com your daily destination, or hit the snooze button and subscribe to our weekly newsletter that hits inbox boxes on Sunday mornings. Join more than 15,000 enthusiastic readers. It'll cost you exactly $0, and you can subscribe right now@c chainsaw.com weekly.

All right, well, turning now a bit, I think, from sort of AI and ML integrations maybe to more sort of analytical workloads. I know that when we were talking before the show and in conversations leading up to the show, it sounds like that, you know, there's some pretty interesting things going on in terms of memsql being used during the COVID 19 pandemic. And of course there's interesting, you know, tracing work going on and, and all of those things that I've heard about, but I haven't really heard about how some of those things are being enabled. So I'd be curious to hear a little bit more about that.

Definitely. So let's step back for a second and think about what different parts of the world and different companies and governments, what do they fundamentally want to accomplish as we go through the pandemic? The first one is simple. How do we stop the spread of the virus and okay, well, maybe we cannot really stop it. Or let's say we put our actions and efforts to do that. But since it's spreading and it's a matter of fact, what else can we do and how we can drive our decisions based on data? What kind of decisions? Well, could be capacity planning for ventilators. We know that there's an outbreak there and we will likely have our healthcare system overrun. And we need to provide extra capacity to the healthcare system. But how much capacity? So all of those questions require answers, and the answers are in data. That's where data science comes in. And that's where, just starting from collecting the data, putting in one place, organizing the data, and feeding this information to people who have the levers of power. Second one is like, who owns the data? We have obviously Apple and Google, who own the data because they have a device. Every individual on this planet, not every, but most of them now own a smartphone. So you can tap into that stream of data and getting information about who is at which location at any point in time and then marry that location with migration patterns and marry that location with individual tracing. Given that we know that this person has COVID 19, who are all the people that this person came across in the past two weeks, so we can go reach out to them and say, hey, you probably want to be tested. The second entity that has that data, obviously maybe government, but I don't know about that. But certainly telcos. Telcos have this information maybe not as accurate because they don't have a GPS on the device. Well, actually they do GPS on the device, but they may not be able to tap into the gps, but they can triangulate the location based on cell towers. So we're working with some of the largest telecommunication operators here in the United States as well as around the world. And I think the one that's public is true digital, one of the largest telcos in Southeast Asia. And we do both. We do the migration patterns where if you go back to, you know, March, February time frame, we already knew that there was an outbreak in China and there was an outbreak in Italy, and we already knew how bad that was. And looking at the flights from Italy and like tracing individuals that land and then starting to see this pattern of people getting sick emerge, you can start driving decisions off of this and you can start putting policies in place that can stop the spread. You can start do capacity planning. You can start manufacturing masses and ventilators and distribute them into places based on the patterns that we're observing. And so that's how data management solutions are helpful to companies that have the data and also the insights that those systems generate are useful for people with the levers of power to drive policy and to drive decisions. Yeah, Google and Apple, well, especially Google has the technology, but you know, telcos don't. And that's where we partner and give them those abilities.

Yeah. It strikes me that the things you're discussing, there's definitely a lot of potential and value there earlier on in the episode about facial recognition and a lot of things that are possible there on a sort of large scale. I think that as people are now in this pandemic and kind of layered on top of that, all of the climate that's in our country and around the world around injustice and policing, there's a lot of people asking really good questions about actually data management and security and privacy. And I'm curious, with you being in a position to have so many conversations with different types of entities around how they view data management, how that's changing as we think about these powerful applications of large scale analytics, but also the potential concern with privacy and tracking and all of those things. I'm just curious to get some of your thoughts on how large organizations are starting to view data management and security maybe now a little bit different than they might have in the past, given that all of the things that are going on in our world.

Definitely it's a multifaceted question. It starts with data management to highlight everything that's going on and the big problems that we face and big issues that we face as a nation. How can data management help here? And I think one of the answers to that of many. Right. There's so many things that would go into solving these big issues that you raised. But one of those things where data management can actually help is with data sharing and data consumption. Imagine the police data was given by the government to the whole world in the easiest way from the consumption standpoint. And it's completely real time. So if you have an arrest, and that arrest by regulation has to be a part of a public record that is in the system in 10 seconds after that arrest happened, that information is just live, real time for everyone's consumption. And with our vision of a single pane of glass towards all your data and all workloads, we will be able to enable those things, enable anybody to log in into our cloud service and consume that data, assuming the provider is willing to publish that data. Imagine that climate change data is available to anybody in real time and it's live and it's easy to consume. So where we live today is a lot of data sets are public and a lot of data sets are public and there's regulation that forces them to be public. But they are published in a non standard, obscure way.

Yeah, they're not discoverable.

They're not discoverable. So to consume that data set is. It's a project. It's like going to a library or going to a court and like asking for permission and they will like bring these papers and put it on the table. I'm inspired by rewatching rather Spotlight, when they got access to some sensitive data that had to by law be public and they had to jump through hoops. But imagine all that data is discoverable, it is at your fingertips and that data is up to date. So you don't have to think about it like, oh, like I downloaded from last month, what changed between last month and and today? So it's just there. That can make a lot of things easier, more transparent and we'll be living in a better world. We need to think about the implications of that from the, like, you know, what if bad guys had access to this data? But that's a policy question, that's not a data management question. I think data management should enable us to live in a world like this. And the technology is already there.

Yeah. And I imagine that if you have this sort of single way to interact with data that's centered around SQL and people are familiar with that, they're able to use it. There's also, in addition to the sharing of data, there's sort of the sharing of methodologies that can happen. For example, even in our last episode that we recorded, we talked about some tooling that's out there around fairness and bias and other things. It's a little bit like you have to read a good amount of documentation, you have to figure out how to use these things. I wouldn't say it's seamless and easily integrated into your workflow at this point, but I could imagine, for example, if a suite of tooling that is easily accessible via certain SQL workloads that look for bias in your data on certain features, or highlight certain things in your data set and all of those things, and whether you're using, like you say, whether you're using TensorFlow or PyTorch or Spark or whatever, you could potentially have access to those things in terms of people sharing their methodologies because things are centralized in terms of the SQL language. Do you see that? I'm wondering, you know, what's the memSQL community like, I guess in terms of, you know, people working on projects built on top of memsql. What's that community like? And do they share certain things like that or certain things available that are maybe open source that are built on top of memsql that people can work on in a collaborative way.

The community is on the forum.memsql.com and then there's a community of mostly enterprise developers actually, because that has been our focus so far that are sharing through MemSQL events and conferences. Where we going is now that we've gotten here and we opening up the platform more and more to the community, we're thinking a lot in terms of free and how we can make a lot of the things that got us here to get us to the 40 million run rate with 70% growth. How can we take some of that and open them up? And by opening up, providing certain set of features and capabilities to the world for free. So on our dime, you go in the cloud, you log in and there's this free tier of stuff that you can do. That's our current thinking so far and I'm actually going to be personally overseeing that effort here at memsql.

Yeah, that's really exciting. I'll be excited to kind of dig in and play around with those things. One other thing that I guess is Covid related and also related to our changing world is I guess people's just workflow and productivity during this time. I'm just curious, with memSQL growing so fast and obviously a lot changing, a lot happening, how has that been for MEMSQL and how do you see kind of, I guess tech work from home and productivity sort of stuff moving forward from your perspective as a CEO?

Yeah. So first of all, we are in the uncharted territory. MemSQL wasn't the company that was born remote first. Even though we're global and we have office in San Francisco, Seattle, Lisbon, Kyiv, Ukraine, India, I think it's Bangalore and sales offices all over the place, there's still concentration in each location and usually a particular concentration of a component that people work on within an individual location. We weren't impacted from our performance standpoint. It's been 1/4 of COVID basically just finished our Covid quarter. We demonstrate tremendous results. We're very happy and excited about the future and we obviously shifted all our workflows into working from home workflows. Now the worry that I have and I'm being paid to be paranoid is that it works fine so far because we are tapping into the social capital that we've built over the years. And a quarter of COVID is we spending that social capital. And all this social links are established between people and they fill them while working at a particular location and looking into people and AI to their friends and colleagues. So that's gone. Right. So every meeting is a formal meeting. If you think about it, we're missing on hallway conversations.

Yeah, I guess I hadn't thought about it that way, but it's.

Yeah, yeah, we're missing out on hallway conversations. We're missing out on, you know, grabbing coffee together and having this like nice positive experiences. Brainstorming while walking towards a nice coffee shop and grabbing a latte. So I want those things to be back. So hopefully this will happen relatively soon and we'll have a dent in the social capital that we've built and then we'll kind of fill up that dent by getting back together. Yeah, so that's my hope. Obviously we can control that. The situation controls us a little bit.

Yeah, it's interesting. I mean, so I've been working remote previous to Covid. I've been working remote for I think maybe about three or four years now. And I definitely get what you're saying. I've had to intentionally over time develop relationships with local data scientists or technical people that are maybe not so they're not working at the same organization that I am. But it's a chance for me to get together with those people and just talk about things. Because sometimes I wonder, just sitting at my computer, I brainstorm a lot of things and sometimes I wonder if I'm crazy because I'm just. I'm not talking about those things to anyone except in when I'm like presenting them to my supervisor, I'm presenting them to a group and I'm supposed to, you know, sound like I know what I'm talking about, hopefully a little bit. So, yeah, it's not that sort of informal environment. And that's very interesting observation. I hope that some of that can come back.

Definitely.

Yeah. As we wrap up here, I'd love to give you a chance to just let people know. Obviously there's memsql.com we'll have the links in the show notes. But as like a data scientist or AI sort of person, are there ways that people can kind of play around with memSQL and get a little hands on and see what it feels like and how to do certain things? Where would you Recommend that they start getting onboarded.

Definitely. So if you want Free Forever, we have our software and we give our software to up to four servers. Like I said, it's a cluster software to install whenever you want and run forever. So we call this our software Free tier. It grew three times over the past year. From the active user standpoint, it's basically one of the best column stores on the planet. So data is highly compressed, stored on disk, very fast reporting, everything is updatable, transactional system of record. And so where other companies like I don't know that run on premises, you know, the verticas, the green plums, they want to charge you for that. You know, you get it free and you can put billions and billions of data points in the system and get very, very fast SQL response from it in the cloud. Our free tier is time based so I encourage people to log in and you know, you can play around with the system. That would allow you to not use any software and consume everything as a service. But because we're running it on our infrastructure, we're limiting access to Free for a period of time. We'll be announcing more changes there. We'll give the system for you for Free forever for a limited usage. But that hasn't come out yet. So that's something we're working on. So that would be probably the best places to start. And of course go to forum.memsql.com to learn about the system.

Awesome. Yeah, we'll have those links in the show notes. Really appreciate you chatting about everything today. I think our listeners will really enjoy the content and hopefully check some of these things out. And yeah, thank you so much for joining us and hope to have one of those hallway chats with you at some point when, when things are actually open up.

Well, if you're in Silicon Valley or I'm there, I will make sure to ping you and we'll hopefully make that happen.

Yeah, definitely. Yeah. Thank you so much.

Bye. Daniel by.

Thank you for listening to this episode of Practical AI. People ask us all the time. They say, hey, how can I support your work? One easy way is to leave a five star review on Apple Podcasts. Tell folks why you listen and why they should too. It only takes about 30 seconds and believe it or not, those ratings and reviews really do help us rank higher in AI related search results. Practical AI is hosted by Daniel Whiteneck and Chris Benson. It's produced by Jared Santo, that's me. And our music is brought to you by the one and only Breakmaster Cylinder we are sponsored by amazing people at companies who get it. Thanks again to Fastly, Linode and Rollbar. Did you know we have a master feed of all Changelog podcasts? We do. It's your one stop shop for everything we produce. If you like this show, you'll love the Changelog Brain Science and go time. Check it out@changelog.com master or search for Changelog Master in your favorite podcast guest app. You'll find us. That's it for now. We'll talk to you again next week.