I'm Slava Akmichet, and you're listening to The Change Log. Welcome back, everyone. This is The Change Log, and I'm your host, Adam Stikowiak. This is episode 181, and on today's show, we're joined by Slava Akmichet.
Slava is the co-founder and CEO of RethinkDB. And before you think this is Founders Talk, another show I've done in the past that you may have listened to, this is not Founders Talk, this is The Change Log, but Slava is a co-founder, he's also a CEO, and Slava is also a software developer. And it was great having Slava on. We talked all about databases.
We talked about what RethinkDB is doing for databases in this reactive, real-time web world we're living in. We had four awesome sponsors, CodeShip, Braintree, Harvest, and also DigitalOcean. Our first sponsor is CodeShip, long-time supporter and huge fans of The Change Log. And CodeShip wants you to focus on your code and automate all the things that are involved in delivering your application to the server.
And also, with CodeShip, you can run your tests lightning fast using Parallel CI, an awesome feature that allows you to split your test commands and speed your test suite. And out of the box for the first two weeks, there's going to be a complimentary set of 20 parallel testing pipelines to speed those builds and get that code of production so much faster, obviously, after it's tested. Use our coupon code, TheChangeLogPodcast, to save 100% off any plan you choose for three months. Head to CodeShip.com slash TheChangeLog to get started, and now, on to the show.
All right, well, we're back. We've got a catch-up show here for you, Slava. And Slava, I didn't ask you how to say your last name, and I think even if I tried, I might vote you. So do me a favor and tell us your last name.
It's Slava Akmichev. Okay. I'm going to call you Slava. That's cool.
Jared, obviously, is here on the call today. And this is a catch-up show. This is kind of a tail-off to episode 114, which you and I weren't even on. That's right.
Yeah, so Andrew did that show back in December of 2013. Slava was there, but you and I were not, so we catch up on lots of stuff. And Slava, you are the co-founder and CEO of RethinkDB, and that's an open-source database. RethinkDB is a scalable database for building real-time applications, and I'm sure we'll get into some of the stuff and talk about the project and what it's for.
But just a little bit about myself. I was born in Ukraine. I moved to New York City with my parents when I was 13. I basically grew up in New York or spent half my life in New York.
I am a computer scientist and a programmer. I love building things. That's my passion. I love developer tools.
So, you know, I love building things for people who build things. And now I'm in California, Mountain View, California. I moved here to start RethinkDB about five years ago. So that's a very short summary of, you know, the best 32 years of my life.
Well, we're definitely going to get into RethinkDB, and we'll have plenty of time to just talk about that. It doesn't write very often, but then when you do, it seems like very well-thought-out long pieces. So I thought we'd maybe just camp out there a little bit and talk about a few of your posts, because you have some interesting things to say. The first one is from, hey, about the same time you were on the show, December of 2013.
You had a post called Learn to Code Like It's 1996. Oh, yeah. This was when you're kind of spouting off on the code school movement. This was about the same time that Obama said all Americans should learn to code or something like that.
You had a unique perspective on that with regard to kind of the Russian immigrants in New York City. Can you tell us about it? Yeah. So I think, you know, one advantage of having been in the industry for a while is that you start seeing patterns in things.
And so the blog post Learn to Code, like it's 1999 that you're referring to, is about this Learn to Code movement, the idea that everyone should be learning to code. And so I remember I moved to the United States. I moved to New York in 1996. I was 13 years old.
And at the time, we were in the middle of the dot-com boom, right? And I distinctly remember how – so my family moved to New York City from Ukraine. And my uncle, my aunt, and a lot of other people, you know, they moved to this new country. They barely spoke English.
And they had to figure out how to make a living. And one of the most popular ways for the immigrant – for the Russian immigrant community in New York at the time was to go to these hacker schools. Except they weren't called hacker schools at the time, but it was something very similar. I forget what they were called, but it was basically, you know, the teacher-hunter program.
It was a short course. It was about – most of them were about, you know, maybe six weeks to 12 weeks or something like that. And I remember back then, like, literally everybody was doing it. You know, it was people who had backgrounds in engineering and math.
It was people who had no backgrounds in any kind of engineering disciplines whatsoever. And everyone in the Russian community was doing it. And I remember at the time everyone in other immigrant communities was doing it, too. I mean, it was immensely popular.
And there were tons of these schools. And I remember in New York – so I lived in Brooklyn, New York, and there was this Russian TV channel that's – you know, it's in America. It's produced in America, and it's designed specifically for American immigrants. So people don't watch it in Russia.
So that's how – you know, I just remember when people started talking about, oh, everyone should learn to code, I just remembered that movement, and I decided to write a post about it. Yeah, so that movement didn't end so well, right? No, that one didn't end so well. So it wasn't a complete failure.
So my uncle, for example, I mean, he – after that was over, so he was working in a furniture factory, making furniture, like sofas and beds and stuff. And at night he'd go to this hacker school, and after it was over, he did get a job, and he's been working, you know, in the field for years, being kind of very productive about it. But for most people, it didn't work out well at all because after the dot-com bubble burst, basically all of the – these were the first jobs to get caught, right, because people learned a very narrow, very specific set of skills. But the moment they have to expand out of this narrow skill set, it's very, very hard for them because they don't have the basics and the fundamentals.
And that's kind of what I really remember about the Learn to Code movement version one, is that people learn narrow skills but not the fundamentals, and it turns out to be very hard to maintain gainful employment if you just don't have the basics of computer science. Yeah. Yeah, I think round two seems to be going a little better. Of course, we haven't had the bubble bust like last time around.
Yeah, well, I'm not even sure – you know, I'm not even sure if it's worthwhile to make a parallel, like, oh, the first one didn't go so well, so the second one isn't going to go so well, too. Like, it's a very common policy to make arguments like that. But it is really interesting. It's kind of suggestive, like, you want to look at it and at least think about it a little bit.
Who were these ads from that were on the TV? Were they from the schools themselves or were they from – you know, was it part of some sort of movement where someone else was advocating to get people to code? Was it true advertisements? So it was true advertisements from the schools themselves, and there were lots of different schools like that.
And the ads were – I mean, they were out of this world. It was like – the ads were literally like this immigrant coming to the ass off the boat, doesn't have a job, and then the next scene is he's sitting in a pool in, like, his giant mansion with limos and stuff. I mean, it was really that bad. Like, I wish that YouTube didn't exist and the internet was just getting started.
So I wish I could find clips of that for you guys. So actually, when I brought the blog post, I was looking for the clips, but I couldn't find them anywhere. But, yeah, they were really ridiculous. Yeah, that's borderline pandering.
Interesting. I think it was – it was not even borderline pandering. Okay, okay. That's kind of gracious.
Yeah, so flat out pandering. Yeah, definitely an interesting perspective. I had no idea that that even took place. Me either.
These unique moments in history. But, so speaking of the boom and the bust, you're also a startup guy. Obviously, everything to be is your startup. Yeah.
And you have another post, which is more recent, I think it was this year even in February, about picking startup ideas. And, man, you went deep on this one. You had lots of thoughts. So you've obviously put a lot of thought into this.
And a lot of our audience is engineers. We also have solo developers and a lot of people who both develop and are business people. Right. Even last week, we had Mitchell Hashimoto on.
Another one of those hybrids. And so I thought maybe you could share with us some of your findings and just pick out some maybe takeaways from your post, how to pick startup ideas and share them with the audience. Yeah, so that was a big post. Right?
There was a lot there. Absolutely. But the impetus for the post was – so when we started Everything to Be, we started it in 2009. And I was – at the time, I was in grad school.
And I was a pretty good – well, I want to say I was a pretty good engineer. I don't know. I guess the jury's still out. And my co-founder was the same way.
But we never started companies before. We never started a business before. So we didn't know anything about that. And as we think to Be evolved and as we learn more and more and more about what works and what doesn't work, I just kept thinking about it really hard because it's important for our business to succeed.
And then every once in a while, things kind of start clicking in place in my mind. And I figured, okay, now that I feel like I understand this a little bit, I can go out and share this with people. So the post was pretty big. But I think the most important thing in it is that – so like, okay, when you jump into this completely new discipline or you're trying to learn something completely new, it's a huge deal.
Like let's say, you know, nothing about chemistry or physics. And you're just jumping into physics. Like there's so much to learn, right? And you don't always know where to get started.
So typically for physics, you go to school and there's a curriculum and people teach you stuff. And picking startup ideas, picking business ideas, it's a soft science, right? It's not like physics, but it is complicated. It's extremely complicated.
There's a lot of laws about how markets behave that you can't really learn. Like you could get an economics degree. That would probably be the closest thing to it. But generally, like it's very hard to learn how this stuff works.
You kind of have to see it for a while. But in physics, if you wanted to just get – you know, if you ask a physicist, okay, what is it like – if I needed to know the one thing that would really help me, what would it be? And I think there are certain laws that – so for example, like conservation of energy, right? It's the kind of thing where – by the way, I'm going somewhere with this.
So conservation of energy is this thing where if you're trying to solve a problem and it's really complicated, just knowing about conservation of energy and how it works will kind of guide you to the right solution without necessarily understanding all the forces involved and all the math involved, right? So once you learn about conservation of energy, you can kind of navigate your way through physics a little bit without understanding all this other stuff and you can start catching up and start learning other things, but you can kind of make correct decisions. So I think for startup ideas, that law is the efficient market hypothesis. If you understand the efficient market hypothesis, I think you can make a lot of correct decisions without really knowing the details about everything else that's going on.
And the basics of the efficient market hypothesis, I mean, anybody could look it up, but it's essentially this idea that the markets are efficient and if you think you're going to do better than other people, you're probably wrong because there's lots of other people looking at the same thing. There's lots of other people that have information that you don't, things like that. So that generally – just having that knowledge about the efficient market hypothesis will help you make correct decisions. So, for example, many – you know, oftentimes people think of like conspiracy theories.
They'll say, oh, you know, we already have – like you could cure cancer with cucumbers or something, but like big pharma wants to keep that away from you. And if you understand the efficient market hypothesis, you just wouldn't make that mistake because it's fundamentally not how the universe works. So most of the polls is about, okay, how can I take this idea of the efficient market hypothesis and apply it to making correct decisions about picking startup ideas. Like, does that make sense?
I'm not sure if I'm doing a good job articulating the summary of the polls. Yeah, let me reiterate and make sure that I'm following you. So the efficient market is the idea that markets are efficient. So if there is a valid market, then there would be other competitors in it, there would be people trying it.
And if you find one that's completely wide open and no one's trying it, like cancer curing via cucumbers, it's probably a bad idea. Yes, that's right. And there's a lot of – so you could look – you know, if you start analyzing businesses, you could look at startups and kind of tell whether it's going to work out. Like, for example, if someone – let's say someone proposes a startup where they say, we're going to make batteries, like, five times as efficient as they are now.
Well, then you think, okay, why is it that these two people or three people can make batteries five times as efficient when there's been, you know, billions of dollars poured into this industry and there are huge battery manufacturers with our IT departments that try to research this for years and years and years. How come is this small company can make that better? What do they have that no one else has? And usually the answer is nothing, right?
Every once in a while something will happen where people just miss something obvious, but it's extremely rare. And if you're starting a business, it's probably not going to happen to you. It seems like not how to pick startup ideas, but how to kill startup ideas. Yeah, right.
I mean, it's basically an ecosystem. And the biological ecosystem is if life could arise, it would have a rate. And similarly in startups, if a startup could arise to solve a problem, like if the market could support it, it probably already would. So the question is, okay, how do you pick new ideas?
And the general cross there is that the world is changing all the time. Like, for example, some states legalize marijuana, right? That's a huge – that gives you a huge opening to start a business. So just generally, the way change happens is societies get more liberal, laws get more liberal, that opens up possibilities.
Certain technological advancements, they start out as quantitative advancements, but over time, they become qualitative, and that gives you opportunity to build new technology on top of that technology, right? So you always have to look at what's changing about the world rather than, oh, like I'm going to pick this idea because I'm better than other people, because that generally doesn't work. This makes me think about RethinkDB and your startup idea. I'm seven years old now.
Take us back to that seven years ago, I guess, when you guys spawned the idea. And what advantages did you think you had or what technological change was happening that you thought you could latch on to and has that paid off for you? Yeah, so RethinkDB has gone through a couple of iterations. I think we're six years old now.
But when we started at the beginning, this was in 2009, we were looking at solid-state drives. And at the time, solid-state drives weren't nearly as popular as they're now. They didn't exist in laptops. They didn't exist in all servers.
They were just taking off. And everyone was on rotational drives. Solid-state drives were about maybe five times as expensive, but they were like 20 or 30 times faster. And they didn't have Cs.
So unlike rotational drives, you can read from any location in a solid-state drive without paying this huge penalty. So when we started, we thought, okay, this is going to be a new technology. It was kind of obvious, at least to me. I don't know if it was obvious to a lot of other people that everyone's going to adopt SSDs for high-performance applications.
And we thought databases were designed entirely around Cs. They were designed entirely around limitations of rotational drives. And now this new solid-state technology is coming along. What can we do to design a new database product to kind of, like if we were doing it from scratch, and now we've got these solid-state drives, what can we do?
So that was the impetus of starting RethinkDB. And right now, so today, RethinkDB is very, very different from what it was back then, and maybe we'll talk about it in a little bit. But just going back to picking startup ideas and efficient markets, this idea was pretty good because there was this new change, new technology that was happening. But we should have thought a little bit more about how to explain, okay, there's already existing vendors that make database software.
What is it that we can do that they're not going to be able to do? And in practice, that's actually what happened. And it turned out that with a few small changes, most databases just out of the box are really good on SSDs. And there wasn't a whole lot we could have done there.
There were also lots of other companies that were doing databases for SSDs, and they kind of had the same fate where they just couldn't build a product that was really compelling to people. Because ultimately, if you take MySQL or Postgres or Oracle and put it in an SSD, it worked really, really well. That's interesting. I remember your initial sales pitch all those years ago because it definitely caught my eye.
SSDs, like you said, they were coming into mass production and use, and nobody had really designed data stores. for an SSD, and so when I heard you guys say that fact, I was like, okay, that makes sense, and now we're going to create a database specifically designed with this technology in mind, I thought, that's a good idea. It's interesting that you thought it was a good idea, I thought it was a good idea. It turns out there weren't that many things that you could leverage or change to differentiate yourselves.
Yeah, it was definitely promising, and it felt like there was something there, but it just started out to build out the technology and the product. It turned out that there's just not a whole lot you could do. And I think it's interesting how it turned out. I don't know how often that happens when there's a new change.
So actually, maybe another example of this, I don't know if you remember this idea of augmented reality. Like back when smartphone first came out, people had this idea that, oh, I could lift a phone and move it around and see all kinds of augmented things. And there were lots of companies getting started trying to do that, and it felt really promising, but then it turned out that no one wants to lift their phone and stare at it, so there was not a whole lot you could build for that market. What's funny, too, is now all the cloud providers, especially this show here, this show is sponsored by digitalization, so everything out there now is SSD only.
And so you're now in a market where, you know, six years ago when you were producing RethinkDB and trying to solve this problem of rotational drives versus SSD drives, and that whole problem of the database has been designed for rotational drives. I mean, so what has happened, I guess, since maybe that's something we can do when we come back from the break, Jared. Can I answer that question, maybe? Yeah.
Well, that's a good break, then. Not really a perfect break, but we do have the show. It's sponsored, so we have to take a break. Now, this is the time we take that break, so let's break real quick.
We'll come back and we'll dive deeper with Slava. Braintree is all about making Developer Live simpler with code for easy online payments. If you're searching for a simple payment solution, check out Braintree. For mobile app developers out there, the Braintree B.0 SDK makes it easy to offer multiple payment types.
Start accepting PayPal, Apple Pay, Bitcoin, Venmo, traditional credit cards, and whatever's next all with a single integration into a simple, secure payment that you can integrate in minutes, and developers that got you, don't worry about taking days to integrate your payments, but Braintree is done in minutes, and if you don't have time, give them a call and they'll handle the integration for you and walk you through it. Braintree supports Android, iOS, and JavaScript clients. They have SDKs in several languages, .NET, Node.js, Java, Perl, PHP, Python, and Ruby, and their documentation is comprehensive and it's easy to follow. To learn more after your first $50,000 in transactions fee-free, go to braintreepayments.com slash changelog.
Alright, we're back from our break, and my jacked up kind of question prior to that break wasn't really a question, but you guys had a slogan change. Obviously, you couldn't really innovate in this area, but the point I was trying to make was that now we're in an area where it is, so if you had been able to innovate, it lived in a perfect world for rethink, but you had to rethink your own thing, so your slogan now is the open source database for real-time web. Yeah, yeah, so the thing with SSDs, another kind of reason why it wasn't, it was a good idea but not a great idea and I can restart, so now, in hindsight, I realize that is that it didn't start with the customer, right? The idea was, well, something changed in the world, there's this new technology, what can we do around it?
But it was very much, it was very much like technical, almost academic undertaking. We never really looked at, okay, what can we do for the customer and how can we actually build something that's valuable to other people? So what ended up happening is SSDs are everywhere now, right? We built a storage engine design for solid-state drives and it's still running in everything-to-be, it's still the fundamental kind of underpinning everything-to-be, but then we found out that, very quickly, that if you just take a normal database, like a traditional database like MySQL, and put it in SSDs, it works really, really well, and there's been some tweaks that people made to make MySQL faster in SSDs, but it was pretty relatively simple to do, right?
So we couldn't, so, you know, having a database designed for SSDs wasn't very much an advantage, but at the time we had this technology and the storage engine was really, really good, or we thought it was really, really good, and we thought, okay, what else can we do? Can we do anything with this technology? Should we keep building or should we go on to do something else? And what became obvious to us is that the world, so there was another change that was going on at the time, and we're in the middle of it right now, and the change is that the world is moving towards real-time applications, reactive applications with engaging experiences.
So, for example, if you ever use Google Docs, when you're editing a document in Google Docs and someone else makes a change to it, you see that change right away. So that's an example of what we call a reactive real-time application. Another example is Slack. If people are familiar with it, it's a chat for teams, and Slack is an extremely engaging product because it's just messaging on some level, but on another level it's very engaging, you can send images, you can send videos, you can hop on and off between devices, you see everything right away, it's very snappy, it's an extremely engaging experience.
So we saw that people are building these apps but in order to build a real-time application, you have to push data to the browser in real-time because things change very, very quickly. And traditional tools weren't designed around that, right? They were designed around HTTP and HTTP is all request response. So what we saw happening is that on the front end, people started building reactive software with things like Angular and React.js, where everything is event-driven instead of request response-driven.
And the same thing happened in middleware with Node.js, but no one was doing that for the database. So we thought, okay, we've got the storage engine, it's a really great piece of technology, but it's not a great product, and people are building, people want to build these real-time applications, but it's hard because they have to pull the database all the time, it brings it down, it's hard to scale. So we decided to keep going and we built a distributed database. It's designed for the web entirely, it's designed for real-time.
And the way it works is that instead of querying the database, getting the data and then having to query it over and over again, the developer specifies, okay, this is what I'm interested in. I'm interested in this query or this data or this computation. And then anytime something changes in the database, the database pushes information back to the user. And what it does is it makes building reactive apps like Google Docs or Slack or multiplayer games or real-time analytics just dramatically easier than it would have been with a traditional database.
So that's the change that happened over the last few years. And when did you guys start that change and then when would you consider it finished? Like when were you actually, you had moved to real-time we started thinking about it probably around the time when we did the last podcast but it wasn't announced yet. And the reason why is that, so the real-time functionality just kind of happened that way, but that's how the storage engine was built.
And then we built a distributed database, we added support for a query language, there's a lot, you know, there's distributed joins, there's a lot that we think we can do. And under the hood, it was all this reactive, it had the reactive technology, but it took a while to expose it to people in a way that's consumable. So I'd say that the first, and by the way, so the feature in we think it does this is called Change Feeds and it allows people to subscribe to any query that they write. I think the first version of Change Feeds we shipped it maybe, I don't remember, but I want to say about a year ago, maybe a little bit less than a year ago.
And as far as when it's finished, so when we started, when we shifted to this notion of real-time database, real-time applications, ReThingDB like really took off. So in the last few months, we've been growing at 30% month every month in just, you know, developers using ReThingDB. It's number one document database on GitHub right now. It's really started taking off.
And when a product or a project starts taking off, it's like almost never finished, right? Because our feature list is longer than it's ever been because the more people adopt the technology, the more different things they want to do with it, especially with databases because it's so horizontal. So yeah, I don't know if it will ever be finished. I think it's always going to be, there's always going to be more to do.
Well said. Yeah, I meant finished as in like the transition had changed. Oh, I see. I'm sorry.
Yeah, that was, so Derek asked that question. When are you shipping it? Yeah, I think we realized we should do something around maybe mid-2013, that we should shift, you know, we should shift these real-time features and redesign the whole database around the real-time web and make it easier for people to build real-time applications. And I think it took about six months before we had the first release that provided value to people that was usable.
Nice. So this seems like more of a differentiator, but do you have competition with other databases that do push-based architecture? Okay, so the real-time space is really exciting right now because there's a lot going on. So there aren't a lot of other databases doing it because just kind of going back to the conversation we had about startup ideas, so this is something that's super valuable to customers, super valuable to users because everyone wants to build these real-time apps.
The world has really changed in this direction and it's kind of obvious that it's not going back. But if you look at other database vendors, having this push functionality where you can subscribe to queries, that's really, really hard to do. You kind of have to bake it into the architecture and you can't just take an existing database and overhaul it to support this. That's really hard.
So there's a lot going on in the space in general. So, you know, I already mentioned React and Angular. There's Node.js. There's Meteor.
And I don't know if you're familiar with it, but Meteor is a real-time app development framework. And the way they do real-time is they build a really complicated layer called Light Query on top of the databases. On top of databases that they run on top of Mongo and they listen to Mongo's, what's called Uplog. And they try to provide similar functionality, but because it's not baked into the database itself, it's very, very hard.
There are certain things you just can't do. Like you can't do scalability. You can't do advanced computations. You can only really do documents.
So that's one example of when it's happening outside of the database. And another example is Firebase. And Firebase is also kind of similar. It's a service that does document sync and it's a really, really great service for what it does, but it's also fairly limited in the sense that it's not a general purpose database.
There's an enormous amount of stuff you can't do. You can build relatively simple applications, but it's hard to kind of get outside of that and build more complicated apps. So there's a lot going on in general, but there isn't like a traditional open source database vendor that's doing the same thing. Firebase, you mentioned.
Acquired by Google, right? Yes. So are they leaving them alone? Is it being Google-ized?
Google-ized. I like that. I don't know. As far as I can tell, Firebase is still shipping things.
It's still running. I don't think... I think they're integrating it with the Google Cloud services. But yeah, from what I understand, they operate almost independently.
On the site, it doesn't seem like it's very Google. It does say something with Google. You can sign up for it with Google, but it doesn't seem like it's been Google-ized, as you said, Jared. It's actually a little bit of integration, but yeah, it feels like they're operating independently.
What about Pusher? That's another service that I'm familiar with that seems to provide this type of feature. Oh yeah, so there's another class of services. So Pusher is an example.
There's another one called PubNub, and I don't know if you're familiar with that company. So that's also an example of what's happening in the real-time space. So what these guys do is they provide messaging in what's called the network edge. So they don't deal with storing of data.
For example, if you wanted to do a leaderboard and say, we're the top 10 players in my game. So Pusher and PubNub, they don't let you solve that problem. But what they do let you do is once you know what you want to push out to different clients, they provide kind of like a message queue or PubSub as a service. And it's very, very useful when you have millions of concurrent clients that all have to send messages to each other.
Pusher and PubNub are doing a really good job offering a service to businesses where they solve a lot of problems in that space. Okay, how do I compare it a little bit to perhaps a more traditional database or even a key value store that has PubSub as a feature, and Postgres has PubSub as a feature, Redis has PubSub as a feature. Compare everything to that. Okay, so PubSub is something relatively narrow.
So it's extremely useful in a wide range of use cases, but it's a relatively narrow feature. And the feature is you have clients subscribing to channels. So let's say you have a chat application and you have a channel in that room or a channel. You have different people who are in that chat, they subscribe to the channel, and every time anyone pushes information to the channel, everyone else sees that.
So that's what PubSub generally lets you do. And it's, of course, useful for a lot of other things. What everything QB lets you do, it really takes the abstraction down to the database level. So people who are building these apps, they don't have to think about PubSub at all.
You don't need a separate, so you don't need to have a separate piece of infrastructure to distribute messages to clients and a piece of infrastructure to compute information. So for example, even if you had a chat application, so what typically would have to do with PubSub in something like Postgres is, if you want to provide chat history, anytime someone writes a message, you have to write it to the database and push it into this PubSub feature. And then the clients, when they start out, they have to read from the database and subscribe to PubSub. So you're fundamentally dealing with two different technologies, they just happen to be in one project and one piece of infrastructure.
And by contrast, in everything QB, the way it works is, you don't think of PubSub and data as two separate things. You just say, you know, I have a table with chat messages, and you say, you write a query that says, okay, I'm interested in chat messages, get me all the chat messages in this channel, and then keep sending information anytime the results have changes. So you just write, you still think of it in terms of database queries, but these are live queries that send you updates. And every client that connects can say, hey, this is the stuff I'm interested in, I'm interested in, you know, this analytical query, like with a dashboard, I'm interested in this chat room, I'm interested in, you know, maybe all the players in my game within a certain location, like within a mile next to me, things like that.
And they get, so they get the data, and then they get all the updates. So you don't even, so you as a developer, don't even have to think about PubSub versus database hardly different. You don't have to build all the infrastructure yourself, which is, it kind of comes, is the right abstraction. It's a different abstraction for real-time apps.
Does that make sense? I think so. So from an application developer's perspective, are you removing the need for the server side? I mean, are you actually writing your app logic against RethinkDB, or do you still have that middleman between your, you know, say your 30, you know, JavaScript fact clients and your data store?
Well, you have JavaScript clients that run in the browser in mobile, then you have your Python or Ruby or Node.js application, that communicates with the browser via WebSockets, and then the Node.js or Python app or whatever communicates with RethinkDB. So it's a pretty standard three-tier architecture right now, the way it works with other databases. It's just that your server side doesn't need a query for updates, it's just receiving them on the fly as Rethink receives them, basically. That's right.
Okay, I am following you. Adam? I'm obviously falling to a degree. I'm truly behind, but I do have maybe a big bit clarifying question.
So for the developers out there that are, like, used to using something like Pusher or PubSub, what are the, it's not like you said some of the advantages, but I guess maybe there's more? You know, there's obvious advantages, so what are the advantages? Yeah, so if you use Pusher or PubNum or any kind of a PubSub system, you have to do two things. You have to write data through your database, and then you have to send messages out to other users, so you're kind of splitting your code.
And in the moment you're doing something more complicated than just sending messages, you have to start querying the database and, you know, do long polling. And in a naive application, when you poll the database every few seconds, it turns out okay, but as you get more and more concurrent users, that turns out to be extremely hard to scale, because you start bringing down your database, which is constant polling of all the users. So what happens in practice is people's infrastructures for real-time apps become progressively more and more and more complicated as they start dealing with the scalability challenges and the code complexity challenges of having, you know, polling and multiple infrastructures and things like that. And the benefit of everything to be is that it takes the abstraction down to the database layer, where the user just specifies, okay, this is what I'm interested in.
And you don't have to do long polling, you don't have to write code that writes to two different pieces of infrastructure. When your app reaches a certain degree of complexity where you want to do more complicated real-time queries, you can do that without any change. Right, so just the fundamental process of building real-time apps on top of everything to be becomes dramatically easier, because the database was designed for this kind of a use case. It almost seems like PubNub, and I'm not going to call these people, you know, workarounds, but it almost seems like hearing what you're saying that Rethink is a direct path, while these others are more of a workaround.
Yeah, a little bit. So I think something like PubNub, so first of all, it's a service where Rethink is an open-source product. So it's very, very useful if you're doing simple, like, it's very good at what it does, which is pushing messages and routing messages around clients. But routing messages is only a small, it's like a tip of the iceberg of what you might want to do with a real-time application.
So you still have to deal with storage, you still have to do a lot of different things, you still have to do complex computations. So PubNub is, it's very, very good at what it does, but it's a very... small part of the solution for a full-blown real-time app. You really need to bring it onto the database to make building these things dramatically easier and accessible to every team.
So you said that it was, you know, real-time focused, but you did say that Rethink is a general purpose data store. Would you only use it if you're building a real-time app, or could you possibly use it for more traditional request-response web apps? So you can use RethinkDB for request-response web apps. So if you don't want to do anything real-time, RethinkDB just looks like a traditional NoSQL database.
It still has pretty important advantages. It's very easy to scale. It does server-side joins. It does complex computation softwares.
So it's a very good full-feature general purpose database. And the reason why we designed it this way is very often people, they don't just start building a real-time app in its entirety, right? They'll say, they have an app, and then they'll say, oh, I want to make this bit of it real-time. And then I want to make this bit of it real-time.
So it's kind of a good piecemeal, right? And right now people are starting to build full-blown real-time applications on day one where everything is real-time, and that's wonderful. But very often when you already have an app and you want to start making changes, it's not something where you'll just make, you'll change everything. You start adding these piecemeal features.
And that's why it was really important to give people the smooth migration path from, oh, I already know how to build a traditional request-response application, and now I get to start adding these features really easily. I think that's well said, and I think that's true that, you know, people a lot of times will start off traditional and then just have, you know, it's kind of the same thing with JavaScript, is where you're going to jump all in and go with a front-end framework, you know, that's in the JSON API, or you're going to have a traditional HTML rendered page that just has, as JHH calls it, JavaScript sprinkles, which is both a good thing or a bad thing depending on who says it. It seems like here it's kind of like, do you have WebSocket sprinkles and, you know, real-time sprinkles, or do you know that you're building something from the ground up that needs to be real-time? And it seems like everything can be used, if you're not sure, it can be used as a traditional day store, but it's there for you in the case that you just switch to a real-time app where you know that you need one.
Right. Real-time sprinkles is actually a really good way to put it. I didn't know about this phrase, JavaScript sprinkles, but, yeah, JHH is really good at coining some of these phrases. Yeah, it's one of these terms that it's a term of derision by some people, and it's a term of endearment for those that are for it and those that are for it against it, but both sides seem to like it.
So it's one of those interesting words. Let's see here. I want to talk to you about a couple of transport layer things that have come up this year. You know, we have typical REST APIs, the old SOAP APIs, RPC APIs, and it seems like Facebook and Netflix are kind of trying to change the game with how you speak to your backend, and I want to talk about how everything fits into that story.
If it does, let's take a break, and we will pick up with that on the other side. All right, listeners out there who are working solo or on a team tracking time for your projects and billing for invoices. Imagine this scenario. You thought you were wrapping up a project and the client asked for a new feature at the last minute and they got questions about time spent on the project.
Well, do you know how much time you're spending on every feature tweak or bug fix to give them that feedback? Well, Harvest is a time tracking tool built just for that for understanding where your time is going and billing for that time. They even have built-in reporting to let you know how much time your projects took so you can use that information to make better estimates in the future. Now that we understand how much time you're tracking on your client work, you'll also be able to turn those billable hours into invoices in minutes.
Create a free 30-day trial today at getharvest.com. After your trial's over, enter our code changelog to save 50% off your first month. So one interesting new trend, it seems like this year, 2015, has been the introduction of alternate ways of sending data back and forth between your JavaScript clients and your servers. Facebook has its GraphQL, and Netflix has its Falcor, which, by the way, Adam, we need Netflix on here.
Talk about Falcor. Make some note right now. Yeah, just write that down. RethinkDB seems like it would fit somewhat into that story.
Is it complementary to these? These aren't really technologies. They're more thoughts or patterns. Well, they're protocols.
I think I called them protocols with kind of de facto implementations. Yeah, I was gaping the word. That's definitely what I would call them. So yeah, does it play well with these protocols or is it against them?
Yeah, so what's really interesting, so one thing about RethinkDB is that we're completely open source, but it's not just a matter of keeping the source code out in public. We do all our development in public. It's all in GitHub. If you go to RethinkDB, if you go to GitHub slash RethinkDB, you'll see everything that's going on.
And on the issue tracker, we always collaborate with our users on pretty much everything, on every new feature, every design decision, everything that's going on, that lets us build a really wonderful product. And when GraphQL first came out and then when Falcor came out, our users immediately opened issues on the issue tracker saying, hey, if it seems like it's a really good fit for GraphQL or it's a really good fit for Falcor, it would be wonderful if you guys had an implementation. So we started thinking about this about six to eight months ago when Facebook and Netflix first started promoting these technologies. And actually on that issue, there's a little bit of a back and forth with the creator of GraphQL who's on the Facebook team right now.
So it's a really interesting issue. I'll send you guys a link to this one. It says support Facebook's GraphQL and there's like 60 sound responses and there's a deep, deep conversation going on here. So this seems like that's the one.
So RethinkDB definitely fits into that paradigm. And the reason why, so just to kind of a brief introduction to GraphQL and Falcor, the idea is if you're building modern single page applications with Reactor Angular, then what happens is you start dealing with a couple of challenges. You have to create all these endpoints where most of the code you're writing is just boilerplate code. On the browser, you have to do multiple requests to the server to render anything.
So to render one component which has subcomponents, you might have to do multiple network round trips which slows everything down. So there's challenges like that. You can do one round trip instead of multiple. You can do things like optimistic updates.
So it really fits better into the new paradigm of web development. And RethinkDB would work really, really well with GraphQL and Falcor because you can do bidirectional communication. So Facebook, so GraphQL has some provisions for that and Falcor is adding it. And in general, it's the way the structure, the way the data is laid out works really well with Rethink's data model.
So we are working on an integration and we're very excited about it. It's hopefully going to come out pretty soon. That sounds excellent. So you mentioned the, you know, it's difficult sometimes when we talk about Rethink, you know, the company Rethink, the open source project, comparing you with Pusher, which is a service and this is an open source project and you pointed that out that this is like in the open source.
One thing that comes up with open source, especially with data stores and, you know, large infrastructure is licensing. And maybe now's a good time we can talk about what is Rethink, the company versus Rethink, the open source project. And then as part of that is like, what's the licensing story? Okay, well, so RethinkDB is a venture funded company.
So it's really a corporation. But our product, RethinkDB the project is completely open source. So what the company does is the way, you know, our business model right now is we provide client services to a lot of our users and security. You know, they have a mission critical application running on top of RethinkDB.
It's very important to them to be able to pick up the phone and call somebody and make sure their problems get solved. And also provide inside training to help come out and train their developers on how to build these types of apps, how to use Rethink, things like that. But RethinkDB, the open source project, it's licensed under AGPL and it was really important to us to protect the project in such a way that anytime someone uses it and improves it, they have to release the changes to the community. And then the drivers, so these are the kind of libraries you use in your Node.js or Python or Ruby or whatever programming language with RethinkDB.
They're all Apache licensed. So basically, you can use RethinkDB for free for any reason. If you make any changes, you have to release them to the community. But yeah, there's no restrictions on how you use the project.
It's just like any other piece of open source software. How do you balance being venture funded and your product being open source having services that obviously the VCs give you money for a reason they want to return? Right. How do you as a developer and a CEO balance the direction of the product which is open source and the direction of the company which needs to make money to ultimately feed the people that are giving you money?
Well, so to be honest, it's not much of a balance because if you're building a developer tool, if you're building a database in particular, it's a fundamental piece of infrastructure and in 2015, you just couldn't build that as a closed source project. That just wouldn't be possible because nobody would adopt it. So everything could be, I mean, we use a lot of software but we don't pay for any closed source software. It's just not something that we do and we assume other developers don't do that either and that's where the world is going.
No one's going to use a fundamental piece of infrastructure if it's a closed source software and pay for licenses. So old style companies like Oracle and Microsoft can get away with that because they have huge infrastructures that they've built up. They have existing customers but I don't believe you can build a new company that builds a fundamental piece of infrastructure software targeted to developers. I don't think you can build a new company that makes it closed source.
So for us, it's not much of a balance. We think it has to be open source. We're all open source developers. I don't think it would ever be successful if it were a closed source.
So it's very, very simple but of course, the flip side of that, we have to figure out how to make a company commercially successful and the way to do that right now, we're providing client services to people. We're also learning a lot about the kind of patterns that our customers run into and now we're building products that take many of those patterns, operationalize them, as far as we think the project itself, there's no balance there. It's open source. It's always going to be open source.
I don't think there's not a whole lot of discussion internally about this at all. I don't mean balance on the other. I know the, I guess I know that everything is open source and there's no change. I guess if you are trying to commercialize, which we just had the same word to come up with when we talked to Mitchell from HashiCorp was commercializing software.
When you're trying to commercialize your company and those things, I guess as long as your revenue path and the open source product you are kind of committed to maintain, it's always going to be open source and the community can take over if something happens to the company. And I think people just don't want to pay for infrastructure software targeted at developers. I mean, we expect it to be free now for better or worse and I think it's for the better because we've seen this enormous amount of innovation in software. So yeah, the revenue path for us though is when we look at the patterns, the problems that our customers sell and that we sell for them, we don't take them and productize them and we're going to be shipping a lot of services around productizing those patterns.
So that's our revenue path and for now it's client services. So the future is very bright. It's very, very exciting. But yeah, it's not, you know, it's not very difficult to balance surprisingly.
What can you share with people often listening to this and thinking, okay, yes, can we get some services? What can you share about how you developed out those services and what actually you consider revenue generators? What can you share about that? Well, for revenue generators, I guess that's things people pay for.
Yes. Yeah, but the way we're developing it is we look at, so, you know, the way people buy client services for everything to be right now is, you know, a developer in some organization picks, we think, builds a prototype and then he or she shows a prototype to their colleagues and then starts turning into a real commercial app and then when it gets to deployment or as they're building the application they realize, hey, we need client services. So they give us a call and they say, okay, here's the kind of stuff we're interested in and we tell them about what we offer. And then as we work with these customers we learn a lot about the challenges that they're facing.
So fundamental challenges are often, you know, deployment. Like people have their cloud provider they have their internal cloud and they have to figure out how to deploy everything to be. Everything to be right now is very scalable and it's very easy to scale but very often people need some guidance for complicated setups like they'll say, you know, we want to run this in three data centers. Two of them are in Europe, one in the US.
How do we even set this up? So the challenge of figuring out how they set up my database, that's a huge thing. There's things like auditing, monitoring, just all kinds of challenges you run into when you start having a really big enterprise deployment. And what we're doing is we're taking all of that and we're advising them that our support team is basically giving human services like client services and we're building products and services around it where people can now do these problems in the click of a button.
But instead of, you know, talking to a human they get to pay monthly for this service that helps them solve all these problems. I think the addition of these productized, you know, software as a services as part of your business model is interesting because when I first heard you're doing client services I thought, can client services really drive a VC-backed company to where they're trying to go all on their own? It seems like, expectations like you gotta pay salaries and make a profit but you're VC-backed you have other people's money that are hoping for returns on those investments. Has that pressure or that expectation to not just pay yourselves and pay your workers but to actually have huge growth has that driven you towards some of these additional revenue paths?
It has, but I think, so I think if we weren't VC-funded and we didn't have any expectation of huge growth I think we'd probably still arrive at the same conclusions because, so, you know, I'm a developer and I think, I always think as a developer even though I do a lot of other jobs now and it's like, you know, when you look at code and you have two pieces of code that look kind of similar and you think, man, I gotta abstract that away into a function like that just doesn't feel right. It's the same thing when you're running a company and you have people picking up the phone and it's like, every time I hear someone explain something to a customer twice I'm like, okay, this should be like a library, right? We shouldn't have to do this over and over and over again. It's a very, very similar thing where you start seeing these patterns and you're like, okay, how can we turn these patterns into software and abstract them away so we don't have to do the same thing over and over again?
So I think having VC funding is the kind of thing that definitely guides it in that direction where you start building software as a service and products like that but I think ultimately we would have done the same thing because it feels very natural. It feels very natural to me as a developer when I see the same problem being solved multiple times over and over again. I'm like, okay, how do we turn this into software? In hindsight, this is about VC funding and open source and we just had this conversation last episode with Mitchell and I'm thinking for those out there like Mitchell that are developing open source talented enough to be in the lead like you are and develop this technology, I'm wondering if in hindsight you can think back and say, did you really need VC funding to accomplish this mission and if you had to do it over again I guess maybe that's not the question I want to ask but more so do you think the VC funding was required to be where you're at today or could you have done it a different way and be exactly where you're at with maybe less commitments or less ties?
So I think very often people, I'm kind of going to go a little bit around your question to answer but very often people set up this almost adversarial model in their mind so they say, oh I'll raise VC money and I'll be pressured to do things I don't want. You inherently think it's a bad thing. So people inherently think it's a bad thing they always think oh there's going to be this pressure or they think there's this evil capitalist conspiracy or something like that. I haven't experienced that at all.
I am extremely grateful to everyone. First of all, we're in Silicon Valley, and I'm extremely grateful to everyone I met here. I'm extremely grateful to investors that invested in our company and believe in us and support us. And the reason why is that if you want to make movies, you've got to go to Hollywood at least for a little bit to learn what they've learned.
These industries are very crafty, and people in these industries know an enormous amount of stuff, and they're perfectly happy to share that knowledge, not just for free, but they give you money and then guide you. Otherwise, you'd have to pay an enormous amount of money for them as consultants. So yeah, I don't feel, I certainly feel, I wouldn't call it pressure, it's more like an expectation of doing something important and meaningful, but I don't think it's a bad thing at all. I've learned an enormous amount from these people, and I think it helps our users because our users are, the more successful we think to be as an open source project and as a company, the more successful our users are because there's a bigger ecosystem, they can learn from each other, the product gets better, right?
So I think it's kind of everyone, it's one of those things where it's not a zero-sum game, it's like everybody benefits. So could we have done it without VC funding? I think for a database it's extremely hard because it's a very complicated piece of software, and it takes years to get it to a point where it's useful to people. And in the meantime, you know, you have to pay people and you have to kind of sustain yourself and pay rent and stuff.
So for our particular project, it would be very, very hard, if not impossible, without VC funding. I think for other projects where you could build something that can start generating money very quickly because it's useful to people very quickly, that's probably easier. But for a thing to do, that'd be pretty hard just because it took like three years to get version one out. It kind of goes back to your idea and the innovation process where you, because of VC funding and because databases are the way they are, you really had to innovate to get to where you are today with Rethink and the solution that it solves and the way it tackles the problem itself.
Yeah, I think greatness comes out of pressure, almost. Does that make sense? Totally. I don't want to ask that question in a negative way, if it came out that way, I was thinking more informative to those out there that are like you.
So the next slot, the next Mitchell, who's like, I want to build this open source software for the good of the open source community and just in general, but how the heck do I get there? And did I need to make that choice that I made to make VC funding? Was it actually bad for us and could we have gotten there differently? And I think more like you've been down this road and can you share some experiences with those that are potentially in your shoes, maybe in your shoes, because someone may listen to this podcast a year, two years later from today and be in a similar situation with brand innovations and be thinking, should I approach VC funding for these reasons or should we find another model, which is what Jared was talking about earlier, like React as another database that did support stuff to kind of bolster their business and they didn't, I don't know if they're VC funding or not, but just kind of hoping you can share some experiences back.
That was fine. I have a new question. Let's shift to this here. So we're talking, you know, funding side.
Let's talk about sales with regard to convincing developers, convincing companies. We're all developers. We know how we are. You know, we're very stuck in our ways.
We're also very fickle, which is kind of an interesting combination. You know, we switch often, but we also get stuck in our terminals and I'm stuck in my Postgres. I've been for years, but still interested. And I'm sure it's been kind of hard to convince people, especially with their data.
You know, data stores, like you said, it's critical infrastructure. So I'm guessing you've had some troubles convincing people to try Rethink. I'm guessing you've had, you know, you've been here for six years, you've shifted and you've still been successful. And now you've had, you know, what do you say, 30% per month growth or something like that.
So you probably have some wins along the way, both personally and as a team. I'm curious if you can share some of those big wins, like what was a customer that you brought on, whether they were even, you know, hiring you for your client services, but just users of RethinkDB, big companies or cool companies or people that you respect that you've convinced or have become RethinkDB users over the years. Yeah. So we actually haven't had to do a whole lot of convincing because an open source, open source really helps with that because when we first launched RethinkDB, there was a lot of, you know, because people are building these real-time apps, there was a lot of interest.
But of course, when you're in a bigger company, very often people are like, oh, this is a new technology. It's hard to convince people. But what happened over time is, so some developer in some organization will just download RethinkDB without asking for permission, just because, you know, they like playing with new technologies. They like playing with new software.
They like learning things. And they'll build a prototype on top of Rethink. And sometimes that prototype doesn't go very far. And that's okay.
You know, people have learned and experimented and then maybe they'll use it again. But every once in a while, what would happen is that they show the prototype to their colleagues or to their boss and people are like, wow, that's amazing. Let's productize it. And after that, so in those cases, when that happened, it was very, very easy for us because we didn't have to convince anybody or sell anybody, right?
It was very organic. And once that happens, if they already have an app and they've built on top of this technology, very often, so someone, usually in DevOps operations, they have to make sure that when it goes live, you know, it stays up. And so someone has to wake up at night if something goes wrong. And then at that point, it's people just like, hey, we need to buy, you know, we need to buy commercial services.
So as far as really cool companies that use RethinkDB that we're very happy with, there's lots. So there's lots of exciting companies using it. So one example, I'll bring up some that I really love. So one company I met with them recently is called NextGFCS.
They use RethinkDB. RethinkDB to provide an efficient marketplace for genetic testing. So for example, someone has a disease, they go to their doctor, their doctor needs to run a genetic test, which by the way, it's a very common thing now in medicine, which I didn't realize until I even talked to them. I thought genetic testing, you know, to pick therapies, it's kind of the future, but it turns out they've been happening for a while.
But the marketplace is very inefficient. And what NextGFCS does is they scout all the different genetic testing labs and provide like a unified marketplace with all the information that you need for doctors to make a good decision. So that was really, really cool because RethinkDB is used, you know, it's used in a way that legitimately makes like people's lives a lot better. So we were very happy with that.
Another company that uses RethinkDB now is Fidelity Investments. So, you know, this big Fidelity that we know that manages people's pension funds and stuff. So they rebuilt their website to kind of be a little bit more modern and they use RethinkDB to back, you know, tens of millions of users. That was really, really cool.
Another company is called Gap Narrative. So it's a camera that people just wear all the time and they store metadata in RethinkDB. And now I believe that cameras use the many police departments around the world. So that's really cool because it's an interesting technical use case, but it also like really helps improve police officers' lives and, you know, regular people's lives.
So when we see people pick up RethinkDB for these cool technical use cases and they build products that people use and love, that's always been very cool. And then once that happens, it's very easy. You know, the detraction kind of just picks up because people start seeing these examples. Nice.
All right, well, let's do this. I'm going to set up a question for you. I'm going to give you the break to think about it. I'm going to have you address a naysayer.
So, you know, there's a lot of naysayers out there and I'll just play one. And I'll say, it's okay to experiment new technologies. You have to stay up to date. But with your data and your data store, that's the last place you should be experimenting with new technologies.
You should pick boring technologies, things that will persist your data reliably. And, you know, any no SQL solutions or any new databases is just bad news. So I like to address that concern because I know it's out there. And I'll give you the break to think about it and we will have to address that on the other side.
All right, we're back. Slava, before the break, I set up a question for you. The naysayer who does not want to experiment with their data store, that's the most precious thing that we have is our data. And he says, you know, you really shouldn't be trying these newfangled data stores, especially with your production data.
What do you say is that concern? Well, we work with a lot of users who use all kinds of different technologies. And we have a lot of friends who don't use RethinkDB, but, you know, they all build software. And one thing I can say about just the general trend of where software is going is that it's going towards more specialized tools.
So I've never seen an environment that was built in the last five years that uses a single database. Like, so back, you know, in the 90s, you'd very often just pick Oracle and everything would be built in Oracle and that would be it. But in modern environments, because the apps are getting so sophisticated, there's lots of different, you know, technologies in general, but also database technologies that are used for different reasons. So, for example, people use RethinkDB for the real-time functionality as a platform to build their real-time apps.
They use Elasticsearch for fuzzy matching. They use Hadoop for, you know, for analytics. So there's a lot of different database technologies that people will use. And, of course, they'll use a traditional relational database like Postgres for things where that makes sense, for asset compliance, you know, for financial stuff.
So the thing I'd say is that seems to be really where the world is going. It's going towards microservices. It's going towards, you know, using different technologies and different tools for the job where it makes sense. And, of course, caring about the data and data consistency is extremely important.
So what people very often do in real environments is they'll have one authoritative source of data, which is a technology that they're really comfortable with. So it could be HBase or HDFS. It could be Postgres. It could be whatever they want.
And then they take these specialized databases and build around that authoritative source of information to help them build their apps. And then if something goes wrong, they still have their authoritative source of data. So that's what I see happening. It's becoming very, very common.
I haven't seen an environment where people don't do that. And I think that's kind of the market's response to this very valid concern of, hey, I really care about my data. I want to make sure everything goes right. I think that's a good response.
I agree. You know, polyplot storage is a thing, and specialized tools is definitely the trend. And I think that definitely is the concern of, well, I'm not going to put my most precious data in this thing that I don't trust yet. And it's like, well, you don't really have to.
It can be a secondary storage or it can be for the specific use. And I suppose over time you build up trust for that particular technology or lack of trust, and then you move on to the next one. Yeah. I think that's pretty level-headed.
I'm hoping for something that can be more divisive for us, please. All those level-headed answers are just kidding. Well, I think old-school long-falling databases are absolutely terrible, and they should never be used for any reason. You know, and you should clearly use real-time reactive databases for everything, even when it doesn't really make much sense.
Perfect. So for those who listen to the show regularly, they know we have some good closing questions. And today we've prepared a special one literally just for you. We'll never actually ask this question unless we have a database expert on the show.
So, you know, Jared and I have to hypothesize about the future when we have somebody like you on the show that can help us to pick what that might look like, we ask questions like this. So what is the next big thing in databases? The next big thing in databases? I think that, so the polyglot storage is a huge, you know, huge trend that we see in every infrastructure.
But what's going on is people very often, so the databases, different databases don't interoperate very well yet. So people very often have to solve that problem themselves. So I think the first thing that will happen in the short term is there will be much better interrupt tools between different databases. So it will be much, much easier to build these kinds of environments.
The second thing I think that will happen is many, many more vendors will start offering real-time features. Because, like, once you experience a real-time app and once you see an infrastructure that uses real-time tools, it's, I don't know, it's sort of like if you remember when Ajax came along, like, once you used a website that used it and really took advantage of it, it was hard to imagine what it would be like to go back. And I think the same thing is happening with real-time. So I really fundamentally believe that many more tools will be built around solving problems for real-time apps.
And I think everything will shift to real-time applications on the web in the next few years. Side question. This one is for everybody. Do you remember the very first Ajax interaction that wowed you?
And what was it? Yes. Gmail. Oh, Gmail.
Okay. So Gmail wasn't that. Gmail was definitely impressive, but the one I was most impressed with is Google Suggest. That just blew me away.
Also, Google Maps was probably the closest second one. That's true. Google Maps, too. I must be easy to please, because I remember way back in the day when Dig would let you upvote without reloading the page.
Like, that was my very first Ajax. I was like, why didn't the page reload? I had no idea what had happened at that point. And that's when I knew Web 2.0.
I knew Web 2.0 was here. But definitely not as impressive as any of those things you all got impressed by. So I'm easy to please. Let's talk about open-source radar.
So, Slava, if you had a free weekend, and you and your text editor and you had some code out there, it wasn't your code, someone else's code, what would it be that you want to dig in, read it, play with it? I've been looking at C++. So C++11 came out a while ago, but now people are talking about C++14. It's getting kind of better support in the next few iterations.
So I'm really excited about that. I've been playing with that. I'm excited about ES6 and ES7. Although ES7 is still in planning stages.
So if you're really interested, there is a wonderful cross-compiler called Babel that will take kind of future ES6 or 7 code and compile it to ES5. That's been super exciting. I've been playing with that a lot. And it's a lot of fun because it makes JavaScript code dramatically easier.
And the last thing, so I haven't actually played with this, but I've been watching it forever, and I really want to just carve out a weekend and build something, is the programming language called Rust, which is supposed to be the next-generation systems language that will kind of maybe hopefully replace or augment C++. So these would be my picks, and I guess I'm always a programming language guy. I really like programming languages and playing with them and experimenting. So that's what I typically look at.
All right, next question for you. We actually introduced this question maybe for the first time on the show last episode with Mitchell. So since you're similar in nature to Mitchell, we'll ask you the same question, which is, we call it a super secret question. So what's something super secret no one else knows about, something that either you, or you think, is doing, something that not many people know about or no one knows about to share here on the show today?
So the one thing that we're doing at RethinkDB that not many people know about, which I think will blow people away, is we're building a layer on top of RethinkDB that will allow people, and it's an open source layer, that will allow people to build real-time applications without building any back-end code. And we're super excited about it because RethinkDB is very easy to get started with. It's easy to build real-time apps. But there's still quite a bit of boilerplate people have to figure out.
They have to figure out, how do I hook up my Node.js to RethinkDB and WebSockets in the browser? How do I do identity management? How do I do authentication? Like, all these really common questions.
So we're building a platform that will make that dramatically easier, and people will be able to get started and build their React or Angular apps that are real-time, super-engaging experiences without writing any back-end code. And then as their app gets more complicated and they need more functionality, they need to do more, they can start incrementally adding back-end code. And because it's built up RethinkDB, they'll be a full-featured database to keep extending their application. So we've been designing this with some of our community members.