The Changelog: Software Development, Open Source - RethinkDB, Databases, the Realtime Web (Interview)

Episode Date: November 7, 2015

Slava Akhmechet joined the show again to catch us up on RethinkDB and the awesome progress they've made to power the realtime web. We talked about innovation in databases, compared and contrasted to pub/sub, Pusher, NoSQL, and even The Next Big Thing™ in databases.

I'm Slava Akmechet, and you're listening to The Change Log. Welcome back, everyone. This is The Change Log, and I'm your host, Adam Stachowiak. This is episode 181, and on today's show, we're joined by Slava Akmechet. 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 rethink db is doing for databases in this reactive real-time web world we're living in we had four awesome sponsors code ship brain tree harvest and also digital ocean our first sponsor is code ship longtime supporter and huge fans of the changelog. 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 up your test commands and speed up your test suite. And out of the box for the first two weeks, they they're gonna give you a complimentary set of 20 parallel testing pipelines to speed up those builds and get that code of production so much faster obviously after it's tested use our coupon code the change law podcast to save 20 off any plan you choose for three months head to codeship.com slash the change law to get started and now on to the show all right everyone we're back we 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 butcher it so do me a favor and tell us your last name it's's Slava Akhmichet. Okay.

I'm going to call you Slava. That's cool. Jared obviously is here on the call today. And this is, Jared, 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. Which is kind of interesting. Yeah. So Andrew did that show back in December of 2013.

Slava was there. Yes, of course. But you and I were not, so we'll be catching up on lots of stuff. And Slava, you are the co-founder and CEO of RethinkDB, and that's an open source database. For those who didn't catch 114, give us an intro to who you are. Well, hey guys, thank you for having me on the show. You already introduced me. My name is Slava. I'm one of the founders at RethinkDB. RethinkDB is an open source 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 I love building things for people who build things. And now I'm in California, Mount of View, California. I moved here to start RethinkDB about five years ago. So that's a very short summary of, you know, the past 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. But first, you know, you've, you have a blog, which is a deaf macro.org. And I like your writing style. You're the kind of person who 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 um the first one is from hey about the same time you're on the show december of 2013 you get a post called learn to code like it's 1996 oh yeah this was when you're you're kind of sounding 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 but you had a unique perspective on that with regard to the Russian immigrants in New York City. Can you tell us about it?

Yeah, so I think one advantage of having been in the industry for a while is that you start seeing patterns in things. So the blog post Learn to Code, like it's 1999 that you're referring to um is about is about this learn to code movement the idea that everyone should be learning to code and um 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 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 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, they teach you how to 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 immigrants, immigrant communities was doing it too. I mean, it was immensely 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 in, 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.

It's just an American Russian like television channel. And there would be these ads for hacker schools that they play, you know, every half an hour. So that's that's how, you know, I just remember when people started talking about, oh, everyone should learn to code. I just remember that movement. And I decided to write a post about it. Yeah. So that movement didn't 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,

after that was over, 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 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, these were the first jobs to get cut, 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, I think round two seems to be going a little bit 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 the 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 fallacy 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 was it part of some sort of movement where someone else was

advocating to to get people to go? 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 of the boat doesn't have a job and then the next scene is he's sitting at 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 internet was just getting started so i wish i could find clips of that for you guys i can't i so actually when i wrote 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 um interesting so i think it was way it was not even borderline

okay okay well i was trying to be gracious. Yeah, so flat out pandering. Yeah, definitely an interesting perspective and one that I had no idea that that even took place. Me either. These unique moments in history. But speaking to the boom and the bust, you're also a startup guy. Obviously, RethinkDB is your startup.

Yeah. And you have another post, which is more recent 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 i you know a lot of our audience is engineers we also have uh solo developers and a lot of people who, you know, both develop and are business people. Right. You know, 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 some just pick out some maybe takeaways from your post, how to pick startup ideas and share them with the audience. Yeah. So that was, that was a big 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 RethinkDB, we started it in 2009. And I was, you know, 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, you know, we didn't know anything about that. And as we think DB evolved and as we learned 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, OK, now that I feel like I understand this a little bit, I can go out and share this with people. So the pulse was pretty big. But I think the most important thing in it is that when you jump into this completely new discipline, or you're trying to learn something completely new, it's a huge field. 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'd like go to school, and there's a curriculum and people teach you stuff and picking startup ideas picking business ideas it's so 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 um 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 all 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 the physicist, okay, what is, 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, is 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 big, 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 post 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? Does that make sense? I'm not sure if I'm doing a good job

articulating the summary of the post. Yeah, let me reiterate and make sense? I'm not sure if I'm doing a good job articulating the summary of the post. 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'd 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'd think, OK, why is it that these two people or three people can make batteries five times as efficient when there's been billions of dollars poured into this industry? And there are huge battery manufacturers with R&D 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 missed 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 how to, not how to pick startup ideas, but how to kill startup ideas because you, yes, but it really is.

Killing startup ideas is a fundamental part of picking good startup ideas. You don't want to, you know, we're like, if life can exist, it was just basically go anywhere. Yeah, right.

It's, I mean, it's basically an ecosystem and the biological ecosystem is if, if life could arise, it would have already. And it's 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, how do you pick new ideas? And they, and the general,

the general thrust there is that the world is changing all the time. Like for example, some states legalize marijuana. 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. It's seven years old now. Take us back to that seven years ago, I guess, when you guys spawned the idea. What advantages did you think you had or what technological change was happening that you thought you could latch onto and then 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 are now. They didn't exist in laptops. They didn't exist in most 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 seeks. So unlike rotational drives, you can read from any location in a solid-state drive without paying this huge penalty. So when we started Rethink, 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 seeks. They were designed entirely around the 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 for 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, so 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. You know, 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. It turned out that with a few small changes, most databases just out of the box are really good in SSDs. And there wasn't a whole lot we could have done there. So there were also lots of other companies that were doing databases for SSDs. 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 as you set 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 it then it turned out that no one wants to like lift their phone and stare at it so there was not a whole lot you could build right for that market. What's funny too is now all the cloud providers, especially this show here where this show is sponsored by DigitalOcean. So everything out there now is SSD only.

Yes. 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 rotational drives versus SSD drives and that, that whole problem of the database is being 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, from the break, Jared, just kind of answer that question. Maybe. Yeah. Well, that's a good break then.

Not really a perfect break, but a good break. We do have this 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 lives 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. Enjoy simple, secure payments that you can integrate in minutes, and developers, they've got you. Don't worry about taking days to integrate your payments, but Braintree is done in minutes, and if, they've 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 seven languages, .NET, Node.js, Java, Perl, PHP, Python, and Ruby. And their documentation is comprehensive and it's easy to follow. To learn more and for your first $50,000 in transactions fee-free,

go to BraintreePayments.com slash changelog. All right, 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 era where it is SSD only. So if you had been able to innovate, it would have been perfect or 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 so the thing with ssds another another kind of reason why it wasn't it was a good idea but not a great idea and i can start so now in hindsight i realized 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 a 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 designed for Celeste drives, and it's still running in RethinkDB. It's still the fundamental kind of underpinning of RethinkDB. 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 SSD, 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 could 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 kind 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 this storage engine. It's a really great piece of technology, but it's not a great product. And 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 kind 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 on 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. Now, 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 and were ready to have that as a product? Yeah, so I think 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 the real-time functionality just kind of happened that way, that 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 RethinkDB can do. And under the hood, it was all this reactive, it had all 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 RethinkDB that does this is called Change Feeds, and it allows people to subscribe to any query that they write. And 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 a real-time database for real-time applications, RethinkDB like really took off. So in the last few months, we've been growing at 30% month over month in just, you know, developers using RethinkDB. 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 been because the more people adopt adopt the technology the more different things they want to do with it especially with databases because it's so horizontal right so yeah i don't

know if it will ever be finished i think it's it's always going to be there's always going to be more to do well said yeah i was i meant finished as in like the transition had changed and finished oh i see i'm sorry i think yeah that was um, that was... Jared likes to ask that question. When are you shipping it? Yeah, when are you done? Yeah, I think we realized we should do something around maybe mid-2013 that we should ship these real-time features and redesign the whole database around the real-time web

and make it easy 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? Are there 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, so 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 could 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 is Node.js. There is 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 life 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 provide, 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 document sync. So that's one example of when it's happening outside of the database. 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. So 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 Googlized? Googlized. 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, you know, 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 sign up with Google. You can sign up for it with Google, but it doesn't seem like it's been Googlized, as you said, Jared. I think they did 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 is 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.

So they don't let you do it. For example, if you wanted to do a leaderboard and say, what are 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 a 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 pub knob are are doing a really good job offering a service to businesses where they solve a lot of problems in that space so okay how about compare it a little bit to perhaps

more traditional database or even a key value store that has pub sub as a feature i know postgres has pub sub as a feature redis has pub sub as a feature. I know 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 know, you have people subscribe, you have clients subscribing to channels. So let's say you have a chat application and you have a channel in that, you know, a have clients subscribing to channels. So let's say you have a chat application and you have a channel in that, you know, a room or a channel.

You have different people who are in that chat. They subscribe to the channel. And then 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 RethinkDB 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 you 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'd have to write it to the database

and push it into this PubSub feature. And then the clients, when they start up, they'd 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 RethinkDB, 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 write a query that says, okay, I'm interested in chat message, get me all the chat messages in this channel, and then keep sending me information anytime the results have changes, right? 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, this is the stuff I'm interested in. I'm interested in, you know, this analytical query, like let's say dashboard, I'm interested in this chat room stuff I'm interested in I'm interested in you know this analytical query like let's say 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. How are they different? You don't have to build all the infrastructure yourself. It's 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 fat clients and your data store? Well, you have JavaScript clients that run in the browser and mobile, then you have your Python and 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 trailing behind but i do have

maybe it may be a clarifying question so for the developers out there that are like used to using something like pusher or pub sub what are the yeah it sounded like you said some of the advantages but i guess it's maybe there's more you know there's a there's obvious advantages so what are the advantages yes if you use pusher um or pub knob or any kind of a pub sub system um you have to do two things you have to write data to your database and then you have to send messages out to other users so you're kind of splitting your code and then the moment you're doing something more complicated than just sending messages you have to start querying the database and do long polling.

And in a naive application, when you poll the database every few seconds, it turns out OK. 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 with just 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 polling and multiple infrastructures and things like that. And the benefit of RethinkDB 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. So just the fundamental process of building real-time apps on top of RethinkDB 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 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, as a service, whereas RethinkDB 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 PubNob 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 down to 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 sub-queries.

So it's a very good full-featured 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 And then I want to make this bit of it real time. So it's kind of they do it piecemeal. 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 just, 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 are you going to jump all in and go with a front-end framework you know that's hidden that json api or are you going to have a traditional html rendered page that just has as dhh calls it javascript sprinkles um 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 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 RethinkDB can be used. If you're not sure, it can be used as a traditional data store, but it's there for you in the case that you either switch to a real-time app or 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, GHH is really good at coining some of these phrases. Yeah, it's one of these terms that is 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 or 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 transport layer things that have come up this year.

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 back end. And I want to talk about how Rethink 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 time is going and billing for that time they even have built-in reporting that lets you know how much time your projects took so you can use that information to make better estimates in the future not only will you 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. Netflix has its Falcor, which, by the way, Adam, we need to get Netflix on here. Talk about Falcor. We do. Making a note right now. Yeah, just write that down to get Netflix on here. Talk about Falco. We do. I'm making a note right now. Yeah, just write that down. Jot it down.

I'm doing it. 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 call them protocols thank you with with kind of de facto implementations yeah i was gapping 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 rethink db is that we're you know we're completely open source but it's not just a matter of keeping the source code out in public. We do all of our development in public. It's all on GitHub. If you go to GitHub. 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 Felcore came out, people immediately, so our users immediately opened issues

on the issue tracker saying, hey, it'd be great if, you know, we think 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 that you can share with our viewers or listeners. I'm on your issues now and I see this

one. It says support Facebook's GraphQL and there's like 60 some responses and there's deep, deep conversations going on here. So this seems like that's the one. Yeah, that's the one. So RethinkDB definitely fits into that paradigm. And the reason why, you know, so just to kind of a brief introduction to GraphQL and FileCore, the idea is if you're building modern single page applications with React or Angular, then what happens is that 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 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, you know, 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. And the idea between GraphQL and Filecore is that you kind of unify that and replace REST with this new protocol that's composable, declarative, so every component can specify the kind of data it needs. You can do one round trip instead of multiple. You could do things like optimistic updates. So it really fits better into the new paradigm of web development. And Rethink UB would work really, really well with GraphQL and Falcor because you can do bidirectional communication. So GraphQL has some provisions for that and Falcor is adding it. And in general, just 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 it's difficult sometimes. We talk about Rethink, 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 open source um one thing that comes up with open source especially with data

stores and you know large infrastructure is licensing and maybe now is a good time we can talk about what what is rethink the Rethink the open source project. And then as part of that, what's the licensing story? Okay, so RethinkDB is a venture-funded company. It's really a corporation. But our product, RethinkDB the project, is the way in our business model right now is we provide client services to a lot of our users who use RethinkDB in production. And the services we provide is development support as people build apps. We provide production support.

So when the apps on top of RethinkDB are deployed, we help people in case something goes wrong and we give them that security. You know, if 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 we also provide on-site training to help come out, train their developers on how to build these types of apps, how to use Rethink, things like that. But RethinkDB, the open source project, is 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 bits, the kind of libraries you use in your Node.js or Python or Ruby or whatever programming language to connect to RethinkDB. They're all Apache licensed.

So basically, you know, 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 gave you money for a reason, they want a 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 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. Like that just wouldn't be possible because nobody would adopt it. So everything to 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. Like no one's going to pay, no one's going to use a fundamental piece of infrastructure if it's a closed source software and, you know, pay for licenses. So old style companies like Oracle and Microsoft can get away with that because they have, you know, huge infrastructures that they've built up. They have existing customers, but you can't, I don't believe you can build a new company that builds a fundamental piece of open source, fundamental piece of infrastructure software targeted at the 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 the company commercially successful. And the way to do that, so 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 to take many of those patterns, operationalize them, productize them, and then ship those as kind of software services as opposed to client services that are provided by humans. So that's the balance. That's our approach for building a commercially viable company. But as far as we think it'd be project itself, there's no balance there. It's open source. It's always going to be project itself there's no balance there it's it's open source it's always going to be open source um i don't think there's not a whole lot of discussion internally about this at all i don't mean balance on the up i know the i guess i know that rethink is open source and

there's no change i guess if you're trying to commercialize which we just had the same word come up with we talked to mitchell uh from hashi the same word 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 happened to the company. I'm not saying that, but so long as your mission and the open source mission is kind of in line, it's easy to balance, it sounds like.

Yeah, it's very easy. I think fundamentally there are things that people will pay for and things they won't pay for. And that's one of the laws of economics, right? You can't sell people something they don't want to pay for. 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 solve and that we solve for them, we now 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 out there that are listening to this and thinking, okay, that's cool, you got 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, so 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, Yes. their colleagues, and then it 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 deployment. People have their cloud provider, they have their internal cloud, and they have to figure out how to deploy RethinkDB. RethinkDB 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 U.S. How do we even set this up?

So that challenge of figuring out how do I 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 that 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 solve these problems in the click of a button. But instead of 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 software as a service as part of your business model is interesting because when I first heard that 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, and this just hunches and me putting things together, I feel like a support company, a services company, makes a lot of sense for a bootstrapped company, one with little expectations, like you've got to 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 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. I'm a developer and I always think as a developer even though I do a lot of other jobs now. When you look at code and you have two pieces of code that look kind of similar and you think, man, I've got to abstract that away into a function. 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.

Every time I hear someone explain something to a customer twice, I'm like, okay, this should be like a library. We shouldn't have to do this over and over and over again. So 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 extract 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 you 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, since we're talking about VC funding and open source, and we just had this

conversation last episode with 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 like you are and uh 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 it, but very often people set up this like 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.. You inherently think it's a bad thing. So people inherently think it's a bad thing. They always think like, oh, there's going to be this pressure. They think there's this like evil capitalist conspiracy or something like that. Like 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 kind of believe in us and support us and the reason why is that um it's sort of like 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 like 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 to them as consultants. So, yeah, I don't feel, you know, 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 DBA is 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 like 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 RethinkDB, that'd be pretty hard just because it took, you know, it took like three years to get version one out. It kind of goes back to your how to pick a startup idea and the innovation process where you, because of the 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 didn't want to ask that question in a negative way. If it came out that way, I was thinking like informative to those out there that are like you.

So the next Slav, the next Mitchell, who's like, I want to build this open source software for the good of the open source community and just technology in general. But how the heck do I get there? And did I need to make that choice that I made to take 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 new 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 and stuff to kind of bolster their business.

And they didn't, I don't know if they took VC funding or not, but just kind of hoping you can share some experiences back. That was my- Yeah, totally. I'm sorry. I apologize if it came out, if my answer came out a lot. No, no, I wanted to apologize. I didn't want to seem like-

I didn't mean to do that, but- You're all good good don't worry about apologizing with you're always in the right here don't worry about it well not always but i feel like i should apologize too all right you should do it so you're sorry i have uh let's i have a new question let's let's let's shift to this here so we're talking you know funding. Let's talk about sales with regard to convincing developers, convincing companies. We're all developers. We know how we are. We're very stuck in our ways. We're also very fickle, which is kind of an interesting combination.

We switch often, but we also get stuck in our terminals. I'm stuck on my Postgres, have been for years, but still interested. And I'm sure it's been kind of hard to convince people, especially with their data. A data store is 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 been here for six years, you've shifted and you're still being successful. And now you had, what do you say, 30% per month growth or something like that. So you probably had 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 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 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 and 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 were 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 or 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, it's called NextGXDX. They use 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 is kind of, you know, to pick therapies, it's kind of the future, but it turns out to have been happening for a while.

But the marketplace is very inefficient, and what NextGXDX 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 rethink to be is used um 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 rethink to be now is fidelity investments so you know the 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 GetNarrative. So it's a camera that people just wear all the time and they store metadata in RethinkDB. And now I believe that camera is used in many police departments around the world. So that's really cool because it's an interesting technical use case, but it also really helps improve police officers' lives and 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. The detraction kind of just picks up because people start seeing these examples. Nice. All right, well, let's do this. I want 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 neckbeards out there and I'll just play one and I'll say it's OK to experiment new technologies. You have to stay up to date. But with your data and your data store at 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 NoSQL 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 Slava address that on the other side. DigitalOcean has expanded their reach even further into Canada's startup and developer scene with the launch of Tor1. That's

T-O-R-1, their first Canadian data center in Toronto. Head to digitalocean.com and use the code CHANGELOG to get a $10 hosting credit when you sign up. Again, digitalocean.com, use the code CHANGELOG to get a $10 hosting credit when you sign up. 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, you know, newfangled data stores, especially with your production data. What do you say to 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 toward 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 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. Polyglot storage is a thing and specialized tools is definitely the trend. And I think that definitely addresses 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 this specific use. And then I suppose over time you'd 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 was hoping for something yes you'd be more divisive for us please all this level-headed

answers are i'm just kidding well i think old school long polling databases are absolutely terrible and they should never be used for any reason um you know and you should clearly use real-time reactive databases for everything even even when it doesn't really make much sense. You're here. 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 will never probably ask this question again unless we have a database expert on the show.

You know, Jared and I like to hypothesize about the future when we have somebody like you on the show that can help us depict 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 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 even 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 okay do you remember that like when you type when you start typing your query and it suggests yeah that just blew me away also Google Maps was probably

the closest second one 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. I'm easy to please. Let's talk about open source radar. Slava, if you had a free weekend and it was 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'd want to dig in, read it, play with it? What's on your open source radar right now? So I'll tell you what I have been digging into over the past few weekends. So I'm really, really excited about new language advancements. So I've been looking at C++. So C++ 11 came out

a while ago, but now people are talking about C++, you know, 14. It's getting kind of better support and 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, you know, 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, you know, 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 our super secret question. So what's something super secret no one else knows about something that either you rethink is doing um something that not many people know about or no one knows about that you could share here on the show today so the one thing that we're doing at rethink db that not many people know about which i think will blow people away is we're building a layer on top of rethink db that will allow people and it's 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 backend 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. Like 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 backend code. And then as their app gets more complicated and they need more functionality, they need to do more, they can start incrementally adding backend code. And because it's built on top of RethinkDB, they'll get a full feature database to keep extending their application. So we've been designing this with some of our community members. It's in progress right now.

We'll hopefully ship it in about eight weeks. We're super excited about it. This project, it doesn't sound too impressive because it doesn't even have a name yet. But I think when it comes out, people will be really excited about it. So I'm really looking forward to it. Is there anything we can put in the show notes for a link? Anything to share yet on the web? Yes, actually, the GraphQL issue at the end

of it, there's a bit of a discussion about this. And I can give you a link to the specific comment that covers this. Okay. But there's not a whole lot of information there. It's being designed. It's not designed openly yet. Awesome. I'll make a note that we definitely have the support Facebook's GraphQL support issue in there. So we'll put it in the show notes and we'll add the comments as well that talks about that. Okay. Sounds cool, man. Well, Slava, it's always good to have a repeat guest. Getting a chance to catch back with you.

Like we said early in the show, Jared and i weren't on the original show so andrew if for some reason you're listening to the show i don't i don't know if you listen to the change log anymore or not but uh episode 114 was awesome so thank you for that and thank you slava for coming back on the show to to not just catch us up with rethink and what you're doing there but also all the wealth of knowledge you bring to uh software development databases open source, and even your CEO hat, where you kind of help us navigate the waters of the evil VC. Thank you guys so much for having me. And obviously we thank our sponsors, CodeShip, Braintree, Harvest,

and DigitalOcean for making this show possible. And we would never, ever end a show. And maybe we have in the past, but we're never going to do it again without thanking our awesome listeners. Without you, it wouldn't be possible to do this show possible. And we would never, ever end a show. And maybe we have in the past, but we're never going to do it again without thanking our awesome listeners. Without you, it wouldn't be possible to do this show. So we really appreciate your support. Also our members, we appreciate your support. And that's it.

So let's say goodbye. Goodbye. Goodbye. Goodbye. The dramatic pause you