MemSQL

MemSQL INTRODUCTIONMartin: Hi, today we are in beautiful San Francisco in the MemSQL office. Hi, Eric, who are you and what do you do?Eric: I am the CEO and co-founder of MemSQL and its good to have you over.Martin: Great, awesome! What is MemSQL?Eric: MemSQL is a real time database for transactions and analytics. It’s core infrastructure and it is designed basically to help businesses optimize their real time operations.Martin: How did you come up with such an idea?Eric: So I worked at Facebook a few years ago, prior to starting MemSQL and my co-founder and I were seeing the tip of the spear of big data problems being solved at Facebook. And it really was an inspiration for us to depart and start a new company.Martin: And what did you see working there at Facebook and what things did you take of that and said, “Ok, now we would like to offer this to the world”?Eric: As you know Facebook is one of the largest web destinations on the internet. It was at that point and still is scaling with a lot of infrastructure and system design to support a billion for people every month. So a lot of the big data problems internally were about volume but there were also new challenges arising around real time analytics. How do you actually change Facebook quickly so that you can adapt it to certain geographies or certain different user demographics? And what we saw was basically a lot of early work around real time processing systems, not just the standard batch systems like data warehouses or Hadoop. We realized that this would be very useful for the rest of the IT industry, so it was one of the reasons why we left, to bring it to everyone else.Martin: Did you validate that this idea that it is working for other companies as well before you left Facebook?Eric: My background at Facebook was working with some of the Facebooks key partners. I was a partner engineer and I saw a lot of those partners basically choke on the Facebook social graph, just so much data was available. So we saw that other companies obviously try to consume that data and they invariably had database problems, the bottleneck in the database chair. So it was both seeing what was happening internally at Facebook as well as some of our partners where it was a lot of validation. And then of course you look at the broader industry at large and data volume and velocity is always a problem. That’s why it’s called big data, it’s a big, big problem to be solved.Martin: And walk me through the process. Once you’ve left Facebook with your co-founder, what did you do? Did you just right away built a new database or did you first try to find funding? Did you first try to find customers?Eric: So we were accepted into an accelerator program called Y Combinator and that provided a great pathway for us to leave Facebook and basically get started in a two bedroom apartment in Menlo  Park. Two guys and a dog. We basically had given up our salaries, all the great perks for what was $20,000 in s tartup capital. And to answer the question, I mean Facebook is a very special place. It’s a great place but we also knew when we left that we will be working from scratch on everything. And when you decide to build an enterprise company especially one in database infrastructure there is no ability or expectation that you would start with something, you are starting from scratch. So the first step was obviously to begin fundraising, to build a team that could deliver the software, and that’s what we did. So we spent two months at Y Combinator and graduated the program and concluded with a 2 million dollar seed round which gave us the capital to build a team of engineers to really release the first MVP â€" minimal viable product in the system.Martin: So you only first release the first database for MemSQL after you got the 2 million and had engineers working on that?Eric: Yes, the databases are not easy. It took us about two years of stealth mode to deliver the first MVP and that was basically only a stepping stone for us because actually the full product was not released until April of 2013. So it took a lot of effort to deliver the product but now that we have it out in the market, on the wild it has been phenomenal to see all the customers using it. So building a database is not for the faint of heart and it takes a lot of money and you need basically good alignment between funding and team to deliver something like a database. Typically though for startups you want to have far shorter response times on your own MVP; for application stack you should be thinking in terms of weeks to months, not years.Martin: Did you do any startup before MemSQL?Eric: it’s my first startup.BUSINESS MODEL OF MEMSQLMartin: Good. Let’s talk about the business model of MemSQL. So what are the specific customer segments that you are targeting?Eric: Sure. At a high level the business model is focused on delivering software to our customers via term based subscription model. S o it is basically a commercial software license that our customers subscribe to. It gives them an ability to expand as they need. A lot of the industry in our space will price by core or by server. We price by capacity, which means that our customers are encouraged by us to use as much CPU as they want. So this means that they can get more performance out of the system irrespective of the number of cores that they want to use. They can always add more cores to the database.Martin: There are so many different databases like SQL, no SQL databases and one of those non-SQL databases, there is MemSQLâ€"Eric: We are very much SQL. We are not noSQL. We are a relational database.Martin: Really?Eric: Of course. It is in our name. Actually it’s a great thing to touch on because I think a good name is so critical that you want to be very prescriptive about what it does. So our name comes from the fact that Mem stands for memory and SQL stands for structure query language, so it lets any deve loper know immediately what we do. And best of all we paid 6 dollars for domain name. It was just available.Martin: Awesome. And so what is the big difference then between a normal SQL database and MemSQl databases?Eric: Like A normal relational database?Martin: Yes.Eric: The biggest difference is that it is designed to be on distributed system, so most disk based databases are single box, ours is a multibox design. And then of course Mem for memory means that most of the first operations are held in memory and then of course we put them on disk for the customer. So the biggest difference is that we are very, very fast and we are analytically focused, so you can use the scale of the architecture to basically compute faster.Martin: Can you name some use cases that some customers did based on MemSQL?Eric: Sure. All of our customers use us effectively for optimization around their businesses. Within financial services we do a lot of fraud detection, trading analyses, risk exposure anal yses, ledger consolidation, a lot of things that are just around the concept of very fast processing.Within ad tech we do real time bidding and attribution to our customers as well as real time segmentation. Basically the ability to segment our users based on some profile characteristics.We have a very great expertise with IoT data; internet of things. So we track a lot of smart devices for our customers for the likes of ComCast with XFINITY, Samsung with their Smart TVs and some other great customers that use us for various devices as well.Martin: And walk me through the process of how it typically works. Is it like, just an assumption, that you build for example a Kafka Flume chain for the ingestion part, pump the data that you need for a specific use case in a MemSQL database and then how do you get this out?Eric: Yes, that’s a great question especially because it lines up exactly what we are doing with our latest product called Streamliner. So when you described around a chain with Kafka connecting to something transformation like Spark, going to MemSQL is like a new product that we launched last month called MemSQL Streamliner for Spark. What it effectively give you is an ability to copy and paste the Kafka URL into the manager dashboard of MemSQL, subscribe to a topic and then low and behold the data is readily available for analysis in MemSQL. So we support semi-structured data with JSON and that Kafka feed is basically pipelined into JSON data type â€" JSON column in a MemSQL table. At that point you can use SQL to traverse it, analyze it, index it, join it â€" whatever you want. But that’s a real time use case that is extremely exciting because are so many customers are actually getting onto the real time data pipeline use case.Martin: For analytics I totally get it that you are close to real time.Eric: We are very much real time. So we can consume millions of events per second and the way we designed the system; an insert will never block a selec t, a select will never block an insert. So this means that you can be inserting data and reading across, scanning across billions of records at the same time. So there actually is no delay in the analytics so you can get as close as you can down to the last transaction down the last one.Martin: What is the secret sauce of competitive advantage that keeps you ahead? For example we met in another company that was in database, they said, “We are the leaders currently in the database, that’s why we have the biggest ecosystem. This is our competitive advantage”. What’s yours?Eric: Well, at the end of the day as a core technology company our competitive advantage is the software that we build and how we’ve built it. Certainly how we built the software is worth sharing a bit It is very hard to build, b-filed patterns and you get talks and you go to database conferences. But at a high level we do something to how we store the data so we use lock free data structures in memory. If you are familiar with database data structures, a b tree is a typical data structure for disk based system that has no need in memory. So the analog for in memory system is a skip list and that skip list lets us do very rapid scans.We have a lock free hash tables for these quick value look ups.We also have a distribute query optimizer so the fact that our query optimizer can take a query that a user might send to the system, we will break it down to smaller pieces and then push it out to other machines for computations. How we actually do all this is obviously the core part of MemSQL but on top of that in our execution engine, we also actually will convert your SQL query into machine code. So this is an amazing improvement, because you no longer bottle necking on I/O and we are now optimizing as best as we can around CPU. So by removing interpretation from a hard code path we can effectively squeeze the CPU for even greater performance.So it is a combination of a lot of different t hings but we have the ability to work with data very quickly and part of what we designed and built the execution engine and the storage engines.Martin: How do you acquire your customers? Are you having a direct sales force or are you using some kind of distribution partner?Eric: Sure, in the early days when you get started you always have to be the chief sales officer as a founder. That’s what I did in the early days. Now we do have a field team, we have direct sales teams and inside team and typically you want to work with customers that have a problem and you can segment them in terms of who is going to be likely to be a customer. So there are certain industries that we don’t sell to â€" like insurance, which is a very slow moving industry but you have to know who your customers are and then as soon as you do you can start working basically with sales teams to acquire them. We have a community edition, we have a free version of the product that anyone can use for free forever . And that has been a great source for us to build our relationship with those customers.Martin: And why are you not selling to insurance companies? Only because their adoption rate is so slow or?Eric: No, no, there are certain industries that just don’t have a need for fast computation. So insurance is a very well architected or very well understood I should say industry. For example there are some things called actuarial tables that tell you pretty much accurately when someone is going to die. And the whole business model in that industry is basically doing a very simple risk model around how to optimize that function. So those are certain industries that, they probably fine with batch analytic processing. When we come into play with real time it is around faster moving industries â€" things like financial services, ad technology, telecom, online business. Those are the sort of industries that benefit from faster information processing.Martin: What is your assessment of the tren ds in the database landscape, where you see the relational and not relational databases? What is your perspective on that?Eric: I think there has been general recognition that noSQL as a category will effectively dissolve into the larger category of databases in general. And I say that because most NoSQL vendors are actually effectively adding SQL back into the mix. But you also have relational vendors like MemSQL and Oracle and PostGres that are also adding a little bit of noSQL into the mix. So I mentioned earlier that we have that JSON data type. That’s an unstructured or semi structured feature that our customers love to combine with relational algebra. So what Garder is predicting is that noSQL as its own category will exist over next few years base anything that have meaningful value will eventually have SQL, especially in analytics. You need to do a join in analytics â€" you need SQL for that calculation. So what we have seen in the market is a lot of the vendors add SQL ba ckend somehow or someway. Over time we’re going to find what is going to resolve is what is called a multimodal database, and a multimodal database is just a way of saying that everything has multiple means of interacting with data.Martin: And is it really realistic to have a database where is multipurpose because I have seen a lot of databases that are for a specific type of usage like graph databases.Eric: Yes. There is always I think a specialty databases that are well suited like graph databases for example, something like document database can have good use cases sometimes. But generally any data that is useful to a business will be structured at some point so it’s always matter of when that data is either deleted or structured.Martin: What is your opinion then on the Hadoop world so to speak? Is it also one way we can store data and batch it in real time?Eric: It fills exactly into the need of two things around the relational or SQL question versus batch processing. At hig h level Hadoop is a great way of storing data. HDFS is really what it is all about and if the cost of storage is zero, and it is, then something like Hadoop should exist and I am glad it does. Of course what you see in the Hadoop space is a general disconnect between the storage which is HDFS and the execution which today has been MapReduce. The MapReduce has been proven, everyone agrees, it is very, very up toes, it is very hard to work with. And that’s why you are seeing a lot of innovation with SQL Hadoop like Impala and Presto coming up to play. And that exactly fits the thesis at least or the hypotheses that SQL is going to carry the day in the enterprise. And certainly even in the big data market SQL is going to carry the day. So Hadoop is great for batch processing, but we need real time, using some in memory apps are critical which is why patchy Spark is so exciting because adding an in-memory execution environment to the Hadoop ecosystem.ADVICE TO ENTREPRENEURS FROM ERIC FRENKIEL In San Francisco (CA), we meet CEO and Co-Founder of MemSQL, Eric Frenkiel. Eric talks about his story how he came up with the idea and founded MemSQL, how the current business model works, as well as he provides some advice for young entrepreneurs.INTRODUCTIONMartin: Hi, today we are in beautiful San Francisco in the MemSQL office. Hi, Eric, who are you and what do you do?Eric: I am the CEO and co-founder of MemSQL and its good to have you over.Martin: Great, awesome! What is MemSQL?Eric: MemSQL is a real time database for transactions and analytics. It’s core infrastructure and it is designed basically to help businesses optimize their real time operations.Martin: How did you come up with such an idea?Eric: So I worked at Facebook a few years ago, prior to starting MemSQL and my co-founder and I were seeing the tip of the spear of big data problems being solved at Facebook. And it really was an inspiration for us to depart and start a new company.Martin: And what did you see work ing there at Facebook and what things did you take of that and said, “Ok, now we would like to offer this to the world”?Eric: As you know Facebook is one of the largest web destinations on the internet. It was at that point and still is scaling with a lot of infrastructure and system design to support a billion for people every month. So a lot of the big data problems internally were about volume but there were also new challenges arising around real time analytics. How do you actually change Facebook quickly so that you can adapt it to certain geographies or certain different user demographics? And what we saw was basically a lot of early work around real time processing systems, not just the standard batch systems like data warehouses or Hadoop. We realized that this would be very useful for the rest of the IT industry, so it was one of the reasons why we left, to bring it to everyone else.Martin: Did you validate that this idea that it is working for other companies as well b efore you left Facebook?Eric: My background at Facebook was working with some of the Facebooks key partners. I was a partner engineer and I saw a lot of those partners basically choke on the Facebook social graph, just so much data was available. So we saw that other companies obviously try to consume that data and they invariably had database problems, the bottleneck in the database chair. So it was both seeing what was happening internally at Facebook as well as some of our partners where it was a lot of validation. And then of course you look at the broader industry at large and data volume and velocity is always a problem. That’s why it’s called big data, it’s a big, big problem to be solved.Martin: And walk me through the process. Once you’ve left Facebook with your co-founder, what did you do? Did you just right away built a new database or did you first try to find funding? Did you first try to find customers?Eric: So we were accepted into an accelerator program calle d Y Combinator and that provided a great pathway for us to leave Facebook and basically get started in a two bedroom apartment in Menlo  Park. Two guys and a dog. We basically had given up our salaries, all the great perks for what was $20,000 in startup capital. And to answer the question, I mean Facebook is a very special place. It’s a great place but we also knew when we left that we will be working from scratch on everything. And when you decide to build an enterprise company especially one in database infrastructure there is no ability or expectation that you would start with something, you are starting from scratch. So the first step was obviously to begin fundraising, to build a team that could deliver the software, and that’s what we did. So we spent two months at Y Combinator and graduated the program and concluded with a 2 million dollar seed round which gave us the capital to build a team of engineers to really release the first MVP â€" minimal viable product in the system.Martin: So you only first release the first database for MemSQL after you got the 2 million and had engineers working on that?Eric: Yes, the databases are not easy. It took us about two years of stealth mode to deliver the first MVP and that was basically only a stepping stone for us because actually the full product was not released until April of 2013. So it took a lot of effort to deliver the product but now that we have it out in the market, on the wild it has been phenomenal to see all the customers using it. So building a database is not for the faint of heart and it takes a lot of money and you need basically good alignment between funding and team to deliver something like a database. Typically though for startups you want to have far shorter response times on your own MVP; for application stack you should be thinking in terms of weeks to months, not years.Martin: Did you do any startup before MemSQL?Eric: it’s my first startup.BUSINESS MODEL OF MEMSQLMartin: Good. Let’s talk about the business model of MemSQL. So what are the specific customer segments that you are targeting?Eric: Sure. At a high level the business model is focused on delivering software to our customers via term based subscription model. So it is basically a commercial software license that our customers subscribe to. It gives them an ability to expand as they need. A lot of the industry in our space will price by core or by server. We price by capacity, which means that our customers are encouraged by us to use as much CPU as they want. So this means that they can get more performance out of the system irrespective of the number of cores that they want to use. They can always add more cores to the database.Martin: There are so many different databases like SQL, no SQL databases and one of those non-SQL databases, there is MemSQLâ€"Eric: We are very much SQL. We are not noSQL. We are a relational database.Martin: Really?Eric: Of course. It is in our name. Actually it’s a great thing to touch on because I think a good name is so critical that you want to be very prescriptive about what it does. So our name comes from the fact that Mem stands for memory and SQL stands for structure query language, so it lets any developer know immediately what we do. And best of all we paid 6 dollars for domain name. It was just available.Martin: Awesome. And so what is the big difference then between a normal SQL database and MemSQl databases?Eric: Like A normal relational database?Martin: Yes.Eric: The biggest difference is that it is designed to be on distributed system, so most disk based databases are single box, ours is a multibox design. And then of course Mem for memory means that most of the first operations are held in memory and then of course we put them on disk for the customer. So the biggest difference is that we are very, very fast and we are analytically focused, so you can use the scale of the architecture to basically compute faster.Martin: Can you name some use cases that some customers did based on MemSQL?Eric: Sure. All of our customers use us effectively for optimization around their businesses. Within financial services we do a lot of fraud detection, trading analyses, risk exposure analyses, ledger consolidation, a lot of things that are just around the concept of very fast processing.Within ad tech we do real time bidding and attribution to our customers as well as real time segmentation. Basically the ability to segment our users based on some profile characteristics.We have a very great expertise with IoT data; internet of things. So we track a lot of smart devices for our customers for the likes of ComCast with XFINITY, Samsung with their Smart TVs and some other great customers that use us for various devices as well.Martin: And walk me through the process of how it typically works. Is it like, just an assumption, that you build for example a Kafka Flume chain for the ingestion part, pump the data that you need for a specific use case in a MemSQL database and then how do you get this out?Eric: Yes, that’s a great question especially because it lines up exactly what we are doing with our latest product called Streamliner. So when you described around a chain with Kafka connecting to something transformation like Spark, going to MemSQL is like a new product that we launched last month called MemSQL Streamliner for Spark. What it effectively give you is an ability to copy and paste the Kafka URL into the manager dashboard of MemSQL, subscribe to a topic and then low and behold the data is readily available for analysis in MemSQL. So we support semi-structured data with JSON and that Kafka feed is basically pipelined into JSON data type â€" JSON column in a MemSQL table. At that point you can use SQL to traverse it, analyze it, index it, join it â€" whatever you want. But that’s a real time use case that is extremely exciting because are so many customers are actually getting onto the real ti me data pipeline use case.Martin: For analytics I totally get it that you are close to real time.Eric: We are very much real time. So we can consume millions of events per second and the way we designed the system; an insert will never block a select, a select will never block an insert. So this means that you can be inserting data and reading across, scanning across billions of records at the same time. So there actually is no delay in the analytics so you can get as close as you can down to the last transaction down the last one.Martin: What is the secret sauce of competitive advantage that keeps you ahead? For example we met in another company that was in database, they said, “We are the leaders currently in the database, that’s why we have the biggest ecosystem. This is our competitive advantage”. What’s yours?Eric: Well, at the end of the day as a core technology company our competitive advantage is the software that we build and how we’ve built it. Certainly how we built the software is worth sharing a bit It is very hard to build, b-filed patterns and you get talks and you go to database conferences. But at a high level we do something to how we store the data so we use lock free data structures in memory. If you are familiar with database data structures, a b tree is a typical data structure for disk based system that has no need in memory. So the analog for in memory system is a skip list and that skip list lets us do very rapid scans.We have a lock free hash tables for these quick value look ups.We also have a distribute query optimizer so the fact that our query optimizer can take a query that a user might send to the system, we will break it down to smaller pieces and then push it out to other machines for computations. How we actually do all this is obviously the core part of MemSQL but on top of that in our execution engine, we also actually will convert your SQL query into machine code. So this is an amazing improvement, because you n o longer bottle necking on I/O and we are now optimizing as best as we can around CPU. So by removing interpretation from a hard code path we can effectively squeeze the CPU for even greater performance.So it is a combination of a lot of different things but we have the ability to work with data very quickly and part of what we designed and built the execution engine and the storage engines.Martin: How do you acquire your customers? Are you having a direct sales force or are you using some kind of distribution partner?Eric: Sure, in the early days when you get started you always have to be the chief sales officer as a founder. That’s what I did in the early days. Now we do have a field team, we have direct sales teams and inside team and typically you want to work with customers that have a problem and you can segment them in terms of who is going to be likely to be a customer. So there are certain industries that we don’t sell to â€" like insurance, which is a very slow moving industry but you have to know who your customers are and then as soon as you do you can start working basically with sales teams to acquire them. We have a community edition, we have a free version of the product that anyone can use for free forever. And that has been a great source for us to build our relationship with those customers.Martin: And why are you not selling to insurance companies? Only because their adoption rate is so slow or?Eric: No, no, there are certain industries that just don’t have a need for fast computation. So insurance is a very well architected or very well understood I should say industry. For example there are some things called actuarial tables that tell you pretty much accurately when someone is going to die. And the whole business model in that industry is basically doing a very simple risk model around how to optimize that function. So those are certain industries that, they probably fine with batch analytic processing. When we come into play with real time it is around faster moving industries â€" things like financial services, ad technology, telecom, online business. Those are the sort of industries that benefit from faster information processing.Martin: What is your assessment of the trends in the database landscape, where you see the relational and not relational databases? What is your perspective on that?Eric: I think there has been general recognition that noSQL as a category will effectively dissolve into the larger category of databases in general. And I say that because most NoSQL vendors are actually effectively adding SQL back into the mix. But you also have relational vendors like MemSQL and Oracle and PostGres that are also adding a little bit of noSQL into the mix. So I mentioned earlier that we have that JSON data type. That’s an unstructured or semi structured feature that our customers love to combine with relational algebra. So what Garder is predicting is that noSQL as its own category will exist over n ext few years base anything that have meaningful value will eventually have SQL, especially in analytics. You need to do a join in analytics â€" you need SQL for that calculation. So what we have seen in the market is a lot of the vendors add SQL backend somehow or someway. Over time we’re going to find what is going to resolve is what is called a multimodal database, and a multimodal database is just a way of saying that everything has multiple means of interacting with data.Martin: And is it really realistic to have a database where is multipurpose because I have seen a lot of databases that are for a specific type of usage like graph databases.Eric: Yes. There is always I think a specialty databases that are well suited like graph databases for example, something like document database can have good use cases sometimes. But generally any data that is useful to a business will be structured at some point so it’s always matter of when that data is either deleted or structured.M artin: What is your opinion then on the Hadoop world so to speak? Is it also one way we can store data and batch it in real time?Eric: It fills exactly into the need of two things around the relational or SQL question versus batch processing. At high level Hadoop is a great way of storing data. HDFS is really what it is all about and if the cost of storage is zero, and it is, then something like Hadoop should exist and I am glad it does. Of course what you see in the Hadoop space is a general disconnect between the storage which is HDFS and the execution which today has been MapReduce. The MapReduce has been proven, everyone agrees, it is very, very up toes, it is very hard to work with. And that’s why you are seeing a lot of innovation with SQL Hadoop like Impala and Presto coming up to play. And that exactly fits the thesis at least or the hypotheses that SQL is going to carry the day in the enterprise. And certainly even in the big data market SQL is going to carry the day. So Hadoop is great for batch processing, but we need real time, using some in memory apps are critical which is why patchy Spark is so exciting because adding an in-memory execution environment to the Hadoop ecosystem.ADVICE TO ENTREPRENEURS FROM ERIC FRENKIELMartin: Eric, imagine your younger sister comes to you and says, “Hey, Eric, I would like to start a company.” What advice would you give her?Eric: At a high level I will assume that she is a recent grad from college. Maybe she has just finished her degree in computer science and she is thinking about doing a company.And the very first thing I would tell her would be, “Don’t do it yet”. I would say, “What you want to do is spend a couple of years minimum in an industry you really care about and work at a big company so you can understand how big companies work and basically absorb a key part of that industry or that vertical. Once you have basically been able to learn a lot about that space, then you can start thinking about joining or starting a company. But I feel that it is so in vogue to start a company in your dorm room and you will find that all of the most successful companies that do start that way are by definition anomalies. When Mark Zuckerberg stared Facebook he didn’t intend to start Facebook. It was just a side project, a hobby and he only left college because it had to be built into something bigger and he was feeling the pressure to do that. So you really can’t force it in your dorm room or even right after college. You really have to figure out an industry you care about and learn about it. And then you can start thinking about innovating there in your own start up.”My own career has the same path. I worked at enterprise companies, consumer companies and then Facebook â€"another consumer company and I was able to learn a lot in my few years working and say “I am ready to start something like MemSQL”Martin: Totally agree. You need to have some domain knowledge. If it is like dating you don’t need to work at some other company, maybe you just go to the discotheque. But if it is like you want to disrupt the insurance world then maybe you should work at an insurance company.Eric: And also, of course young people are always encouraged to be trained and learn. So it’s always up to a company to provide that training. I would say that probably the biggest benefit there of course is that you get to learn how to be a manager. If you stay enough time you will eventually be able to learn how to manage people. And that is the hardest thing to do, because you just can’t read that in a book, you have to practice it and all the better if you can actually learn those techniques and learn how the corporate serves the management by working at a larger company that needs someone like that. And when you are ready to do it you get a chance on your own.Martin: What other advice would you give to your sister?Eric: At a high level beyond that, let’s say when you f ast forward a couple of years and maybe she doesn’t want to start her own company but she wants to join a startup, I would say that the easiest way to go about it is to do your research on all of the best companies back by tier one venture capitalists and just piggy back on the hard work of those other VCs to validate what are the good startups, and what are the ones most likely to succeed. So just as there are tier 1 and tier 2 Universities there are certainly strata at VC. And you will find that all of the most competitive companies are backed by the most competitive venture capitalists. And it is really great to join a series A or series B company when you are young because there is so much to do and you have a lot of freedom inside to basically work and contribute.My advice after a couple of years is of work or whatever have you beis find a company backed by a tier 1 venture capital firm that will benefit from someone with your skill set. It could be in computer science, it co uld be at marketing, it could be in sales, but you learn a lot more in an early stage company at a series A or series B level than you would if you join a larger company at a D, E, or sort of late stage company.Martin: Great. Eric, thank you so much for your time.Eric: My pleasure. Thanks for coming over.Martin: Sure. And next time if you want to really start a company think about it twice, because if you don’t know there is a big problem that needs to be solved maybe you should just start and work in a company like MemSQL or another series A or series B financed company. Thank you so much.