Long gone are the days of the web acting just like linked documents and glorified brochures.
Web apps of today are just that, rich interactive applications.
But unlike your average desktop app, these are apps with hundreds of thousands or even millions of concurrent users.
We expect these apps will instantly reflect changes to the data potentially made by any of these many users connected to the system while using them.
This has put a strain on the web servers, databases, and architecture in general of our web apps.
Technology has responded by delivering amazing real-time capabilities with things like web sockets and signal R at the client layer and event-driven systems on the web servers.
But what about the database? Could it be events all the way down?
That was the goal of RethinkDB's co-founders when they pitched it to Y Combinator.
Now it's time to hear the story of RethinkDB with Slava Akshmet.
This is Talk Python to Me, episode 65, recorded June 22, 2016.
Welcome to Talk Python to Me, a weekly podcast on Python.
The language, the libraries, the ecosystem, and the personalities.
This is your host, Michael Kennedy.
Follow me on Twitter where I'm @mkennedy.
Keep up with the show and listen to past episodes at talkpython.fm.
And follow the show on Twitter via at Talk Python.
This episode is brought to you by Hired and SnapCI.
Thank them for supporting the show on Twitter via at Hired underscore HQ and at Snap underscore CI.
Slava, welcome to the show.
Thank you. It's good to be here.
Yeah, it's really excited to talk about my favorite kind of databases, which are document databases and NoSQL databases.
So we're going to dig into RethinkDB today.
And you guys have such a cool story and such a cool community that you built up.
And we'll get into that.
But before we do, let's start at the beginning.
What's your story?
How do you get into programming?
Well, so I was born in Ukraine.
And when I was maybe seven or eight years old, my parents got me a machine called ZX Spectrum, which was this tiny computer that plugged into a TV and a cassette player.
And they got it for me to play games.
But when you booted it, it had a basic interpreter.
And somehow, I don't know what happened, but the basic interpreter was more interesting to me than the video games.
And I just kind of started learning basic and learning, you know, learning how to type commands and what they do.
And eventually I wanted to make games.
So, you know, I used the basic interpreter's graphing library.
And it was really slow.
So that's how I got into assembly because I realized I could speed things up.
And, yeah, and that was the beginning.
That's a bit of a jump, right?
It was.
It was a bit of a jump.
And at the time, like, there was no internet.
So I had to work off of a manual that was kind of printed on a criminal printer and half the stuff was missing.
But that's how I got into it.
And I just never stopped.
Yeah, that's awesome.
I've also made that jump from high-level languages to assembly for a little bit of time.
And, yeah, I kind of left that behind.
But those were basically the options in the early days, right?
Basic and assembly.
You could pick your extreme and go to it, I guess.
Yeah, on the ZX Spectrum, there were really two options.
It was the built-in basic interpreter and assembly.
There were no compilers.
Like, you couldn't get.
I don't think you could get a different language on it.
So, yeah, it was just those two things.
And I figured out how to mix and match them and, you know, do all kinds of cool stuff on that machine.
Yeah, I probably learned, like, 75% of everything I know now about programming, just, like, tinkering.
It was the ZX Spectrum.
And it was the kind of a computer that's similar.
I guess it's similar to the Atari.
But we couldn't get that in Ukraine.
So, you know, I was stuck with that, like, four kilobyte of memory, you know.
I couldn't save anything.
Couldn't save anything.
So that's how I got started.
Wow, that's cool.
You said it connected to a television.
What do you think the resolution in pixels of that thing was?
Oh, man, so I don't remember, but I think it was, like, 120 pixels vertical or something like that.
It was really small.
Probably.
Or, you know, it didn't feel that way at the time.
No, it felt amazing at the time, right?
It felt amazing.
Yeah, it was amazing.
I'm sure it wouldn't be fun programming it now.
Yeah, it's probably a thing better left to nostalgia.
Yeah, I was actually thinking about buying it on eBay.
Oh, nice.
Because they're available and they're pretty cheap, but I never actually got around to it,
and I don't know if I ever will.
Yeah, nostalgia.
How interesting.
So let's talk about something a little more modern.
You built a pretty amazing database, a document database called RethinkDB,
and your tagline is it's a database for the real-time web.
What is RethinkDB?
Well, so RethinkDB is a NoSQL scalable real-time database.
When you start out using it, it's fairly similar to MangaDB in the sense that you could store
and retrieve JSON documents.
You could scale it out to multiple machines or multiple data centers.
But that's pretty much where the similarities end.
What's unique about RethinkDB that you can't get in any other database that I know of right now
is that it's designed for real-time applications.
And the way that it works is in a traditional database, you send a query and get a response,
and then you're done.
And if you want an update, you have to send another query.
And in RethinkDB, you can subscribe to queries.
So you could say, I'm interested in the top 10 selling books in my bookstore.
And then any time the data in the database changes in the way that updates that results,
the database pushes the notification to the application.
So if you're building any kind of a collaborative application or a multiplayer game where things
change all the time or some analytic software where you need updates right away,
RethinkDB is a really, really great database for that.
And it's unique, I think, because no one else does that.
Where your application is designed around this event-driven model where anytime something
changes in the database, you get an event saying, hey, the relevant results that you're interested
in are now different.
And that makes it dramatically, dramatically easier for people to build real-time apps.
Yeah, that's really cool.
And that is quite a unique capability.
I'm quite sure that MongoDB does not have that.
You've got to ask the question over and over to get new answers.
In modern databases that aren't RethinkDB, you can kind of fake this by doing various things.
Like you could poll and you can ask the same question over and over again.
You could subscribe to the replication log.
There are things users can do to get a semblance of this functionality.
But it's really different when it's baked into the product or project on day one.
Because it just opens up a whole world of possibilities.
And when it's a higher level feature that you can run on most queries or almost all queries,
it opens up so many possibilities that you can't really do by faking it in other systems.
Yeah, I totally agree.
That sounds great.
I recall you telling a story.
I heard it somewhere.
You sort of talked about the progression of real-time systems, right?
So we have the front end being real-time with things like Node.js and SignalR and some of these things that happen on the server.
You can get real-time stuff there.
But then it kind of stops.
Can you maybe tell that story?
I think that'll help really cement what your value proposition is.
Yeah, so traditionally web applications were built around request response.
Like that's how HTTP works, right?
You type in a web address in the browser.
The browser sends a request to the web server.
The web server sends a request to the database to get some information.
The database responds.
The web server responds.
And then you render the page.
So that's how web apps were built traditionally.
And then things started changing because people realized that to have really immersive experiences,
they have to push information to the browser without reloading the whole page, refreshing the whole page.
So what started happening is that people started building applications around push functionality.
So JavaScript is fundamentally event-driven.
And people started building front-end frameworks like Angular and React around the idea of events and event-driven programming.
And then as that became available, you needed that on the back end.
And we have things like SignalR or WebSockets to allow push to the browser.
So on the back end, Node.js is this fundamentally event-driven programming model where you can respond to events.
But then when you get to the database, it still requests response.
And the idea behind RethinkDB was, well, let's make a full stack event-driven programming, environment programming model,
where you don't stop at Node.js, but the database itself is event-driven,
where you say, I'm interested in these things.
And then anytime something changes, we fire an event.
And then Node.js processes that event and pushes that to the browser.
And then the browser processes that event.
So what that does is it gives you a complete full stack event-driven programming model.
And now you don't have to fake events when you go from the Node.js layer to the database layer.
The whole thing is event-driven.
And that makes just real-time architecture so much easier to deal with and opens up so many possibilities for building apps
because things that took a week now take a couple of hours.
Yeah, that's really cool because those are hard problems to solve.
And if you can just plug the pieces together, that's wonderful, right?
Yeah.
So for all of these problems, you can kind of hack around them.
And people have done that for a long time.
I mean, people build real-time event-driven applications before everything could be existed.
But hacking around this problem, it takes a long time.
People solve the same problem over and over and over again.
It's really hard.
You kind of need the main expertise.
So you need a team of people that really understand this problem and got burned a couple of times by trying to solve it.
And the idea was like, hey, let's just abstract this so people never have to deal with this again.
Yeah, that's great.
Can you give some examples of some apps that people have built or the types of apps people have built?
Yeah, so RethinkDB has a pretty huge community.
So we have about 200,000 developers building applications on it now.
And it's doubling about every three to four months.
So people have built all kinds of apps.
People have built games.
People have built analytics apps.
Just anything you can imagine that can be built from mobile or the web.
One of our big examples is Fidelity Investments, which is a big investment firm, built a mobile app for their users to manage their accounts in real time.
So you open the Fidelity mobile app.
All of that is backed by RethinkDB.
I think that's probably the biggest use case I can talk about where RethinkDB backs basically like 40 or 50 million users that Fidelity has.
Some others like Rethink is used by NASA for some real-time updates on what happens with extravehicular suit activity.
So every time astronauts go on a spacewalk, there's a bunch of data that's being generated, being processed in real time.
So it's all over the place.
People use it for financial applications, for just web apps, for collaborative apps, and for things I personally wouldn't imagine like spacesuit activity.
Yeah, that's really awesome.
I would have never thought spacewalks would be one of the use cases, but yeah, that's really cool.
Yeah, we definitely did not design it with that in mind.
I would never think about that in a million years.
Let's see.
If we set up a VPN from the space shuttle, then...
No, just kidding.
Yeah, no, it's an SSH connection, probably.
Yeah, probably.
Okay, so let's talk about the origins of RethinkDB.
What gave you the idea that, hey, we should create our own database?
Like, that's pretty daunting, right?
Before we started, I was in grad school, and I was actually working on mammalian brain simulation on supercomputers.
So I knew a lot about just distributed computing, and I knew a lot about the idea of, like, real time.
Because in brain simulation, you generate a lot of data that you have to send between multiple machines,
and there are a lot of challenges in figuring out how to parallelize all that stuff, because the network is the bottleneck.
And my co-founder, who was also at the same university, he was more of a human-computer interaction expert.
Like, he basically was really interested in user interfaces.
And when we met, we just kind of got together, and we spent, like, hours and hours talking about computing
and the future of software and where things are going.
And it was obvious to us that the world is really becoming more real-time.
Like, there's a ton of data being generated.
We generate more and more and more data every day, probably exponentially.
And it was very clear that, like, these static user interfaces just aren't going to last very long,
and everything's becoming real-time.
So we looked at how applications are being built, how they're being deployed.
And it occurred to us that, like, there's a lot of innovation around real-time almost everywhere in the stack except the database.
And it was just the part we thought was very important to build to advance this mission of kind of unlocking real-time apps for anybody who wanted to do it.
Like, what we want to do, and it's our goal even now, is to make real-time be the default.
So when you build an app, it should be real-time by default, not static by default, and then people have to do a lot of work.
So that's how we got started.
And, yeah, building a database is a daunting process.
It's a very hard problem.
It's a lot of work.
But we were excited about, you know, we kind of, we didn't look at the downsides.
We mostly looked at, hey, what is this going to make possible?
And it was just really exciting.
So we never thought about how long it will take.
Yeah, sure.
And people are successful, right?
They have this dream and this vision, and it's like, we're going to make it through the challenging bits, and we're going to create this thing, right?
So it sounds like you were really driven to sort of solve that real-time problem.
We were.
I mean, to be honest, we also thought it would be easier than it was.
And we thought it would take a lot less time than it did.
So a lot of it was naivete, but it served us pretty well, I think, in hindsight.
Yeah, maybe it didn't let you get through.
Otherwise, it would have been like, well, that's too much work.
Forget it.
That's cool.
And one of the things you did pretty early on was you went through Y Combinator, right?
The accelerator.
Yeah, we did.
Cool.
So what was that experience like?
What year was that?
So we went through Y Combinator in the summer of 2009.
And at the time, me and Michael, my co-founder, we were in New York, and we were in school.
And we had this idea, and we applied to Y Combinator.
We got an interview.
So we flew to California.
The interview was like eight minutes.
We got in, and we knew we wanted to go to California and start a company.
So we just packed up our bags and moved here.
And Y Combinator for us was great because we were new to the startup world.
We kind of knew a lot about software, but we didn't know a lot about how to start businesses
and hire people and manage people and how any of that stuff works.
And Y Combinator would invite speakers who were successful in the startup world.
And every Tuesday, they'd have a new speaker who would talk about their story.
And just that process of listening to people who've built successful things before was extremely
useful because it got us in the mindset of what it takes to build something that people
really want to use, like build something that makes, that's valuable for a lot of people.
So that was great.
I mean, it was a phenomenal experience.
I'd recommend it to anybody.
Yeah.
I've never gone through an experience like that, but it sounds really cool and like it would
be very beneficial.
So, you know, I think when people are new and they're thinking about starting businesses,
they often think about the technology, right?
Like if we build this app and have the best technology, just this work, just the way that
it should solve whatever problem that solving, that's only like 30%, 20% of what it takes to
start launch and be successful with a technology business, right?
There's all the marketing and the growth hacking and the user outreach.
And like how much of those types of things did you learn at YC?
We learned a lot about that at YC.
It was, I'd say, so everyone who goes to YC is very competent technically.
And that was the whole premise of YC, that you get really technically competent people and
you teach them all these other things that they need to know to build something successful.
So technology itself, I mean, it permeated everything.
It was in the background of everything because obviously it's about tech companies, but it wasn't,
we didn't learn like how to program at YCM or anything.
It was all about how do you build a successful project?
How do you grow it?
How do you build a product that people really care about?
How do you think about markets?
Things like that.
It was very little of it was about the technology itself.
Like the whole thing was under the premise that technology is super important and technology
unlocks all kinds of possibilities for people.
But everyone at YC was already good at that.
So the bigger part, the much bigger part was around all these other things you mentioned.
Right.
Yeah.
So the technology is basically table stakes.
Like you don't even get there if you don't have that skill set.
But it's teaching you all the things you didn't maybe even know that you needed to know to
succeed.
Right.
Yeah.
I think the premise of YCM is if you take technically competent people, all this other
stuff, you can teach them.
Marketing and growth hacking and all these things.
Like it's hard, but it's not rocket science.
Like if you can build a compiler, you could probably figure out how to market your product.
That's the premise of YC.
And the idea was like, hey, there's a lot of information there.
It's not very hard, but it's hard to get.
So we're just going to teach people all this stuff and see what happens.
And I think the proof is in the pudding.
Like YC is really successful now.
This episode is brought to you by SnapCI, the only hosted cloud-based continuous integration
and delivery solution that offers multi-stage pipelines as a built-in feature.
SnapCI is built to follow best practices like automated builds, testing before integration,
and provides high visibility into who's doing what.
Just connect Snap to your GitHub repo and it automatically builds the first pipeline for you.
It's simple enough for those who are new to continuous integration, yet powerful enough
to run dozens of parallel pipelines.
More reliable and frequent releases.
That's Snap.
One of the cool aspects of RethinkDB is it's open source, right?
Like I can go to GitHub and get it.
I go to github.com/rethinkDB slash rethinkDB to get the database itself.
And it's really popular, right?
It has over 14,000 stars.
Yeah.
So you said that it was one of the biggest C++ open source projects on GitHub or something like that.
Is this true?
Yes.
It depends on how you measure.
So if you go to github.com/explore, I think they keep changing the interface.
I don't know if you can check this now.
But at least they used to be.
So you used to be able to look at trending projects.
I think that's still available.
And you used to be able to look at, like filtered out by stars, by language, by all kinds of things.
I haven't done this in a while.
But yeah, Rethink has been the biggest trending C++ project on GitHub for a long, long time.
Pretty much since we launched it, actually.
Yeah.
That's really cool.
When did you actually launch it?
You said you did Y Combinator in 2009.
When was there a thing that you let loose on the world?
I think it took about three and a half years to get the first version out.
My memory is a little hazy on this because it's been a while.
But yeah, it's a hard problem.
And it took a while to build the first version of the product.
How many people worked on it?
So right now we're 18 people.
But before the first version, I think the whole company was about seven.
Okay.
It's definitely a big project to undertake.
So yeah, very cool.
When I look at GitHub, it tells me that it's like 50% C++, 26% Python, some JavaScript.
What are the technologies inside?
Yeah.
So Rethink is pretty complex because it touches almost every part of the stack.
And on the bottom of the stack, it touches the operating system and all the APIs that we have to deal with.
To do disk access and network access and memory management and things like that.
So all of that stuff is done in C++ and even a little bit of assembly, actually.
And then around the core C++ database, there are a lot of technologies to connect it to users.
So the drivers are done in a lot of different languages.
Like there's a Node.js driver, a Python driver, a Java driver, Ruby driver, just drivers for all kinds of languages.
So that is written in whatever native language the driver is for.
Then there is a lot of code for testing different things, for testing the query language, testing the distributed system, all kinds of tasks.
So most of that is written in Python.
And then there's a lot of glue code.
You know, there are Bash scripts.
So we kind of, we try to minimize the number of languages and technologies that we use just to kind of keep it contained.
But it, so most of it is C++, but we really have, we have a lot of different things that we use.
I'd say the biggest ones are C++, Python, and Bash.
And then there are drivers for almost every language.
Right.
And you pretty much have to use those languages to write them usually anyway.
Yeah.
Okay.
Cool.
So when I think about NoSQL databases, you've got the document databases, you've got key value stores and those sorts of things.
It feels to me like document databases are the kind of database that you could use as your sole database for your app.
Right.
There's some things like Redis, DynamoDB, where you probably use it for like some particular use case, but it's not your only data store.
What do you think about this idea that document databases could replace your relational database rather than just be another thing that you use in parallel?
Well, so databases are fundamentally very horizontal technologies and you could use them.
They're applicable to a lot of different problems.
And I think that so relational databases used to be this Swiss army knife where you could use them for almost anything because most of the data used to be relational.
And now with modern apps, most of the data is not relational.
Most of the data is hierarchical.
There are a lot of fields missing.
You know, it's what we think of as document kind of base data.
So I think for most of the modern use cases, object oriented or document databases are really, really versatile and they could be used for almost anything.
Now there's still data being generated that's relational.
And just like with anything, like you could use relational databases to store document data.
You could use document databases to store relational data and it will work fine, but you'll have to hack around a bunch of problems.
So I think document databases will be used more and more and more as more data is being generated, more apps are being built, and those are fundamentally not relational data models.
So document databases are great for that.
I don't think they're going to replace relational databases personally because relational databases are just fundamentally better at storing relational data.
And, you know, some people decide to unify their infrastructure.
They figure, I don't want two pieces, two technologies managing things.
I want just one.
And they could put relational data in the document database and it will work just fine.
But it's not, you know, it's not ideal.
I think that you'd have to hack around a bunch of things.
There are some things you can't do.
So my view of the world is that people will continue using different specialized technologies for different use cases.
And there's always a balance.
Like if you use too many specialized technologies, it's too hard to manage.
If you use too few, you have to hack around a bunch of stuff and you have operational problems.
So there is a good middle ground there.
And that sort of feels to me like that's where the world is going.
That's what we see most of our customers use.
Okay.
Yeah.
That's a really interesting way to phrase it and to look at it.
So what kind of relational features does Rethink have?
Like does it have foreign keys?
Does it have joins?
Does it take transactions?
Does it take any of these kinds of things on?
Or does it lean more towards the MongoDB style where it foregoes those for other reasons?
Okay.
So RethinkDB does particularly distributed joins.
It does distributed subqueries.
So as far as the complexity of a given query, you can do almost anything in RethinkDB and sometimes more than you could in a relational database.
So we take on all of those challenges.
And particularly distributed joins are extremely useful in almost every use case, actually.
So we don't do transactions.
At least we don't do transactions for now.
There are some proposals and integrating them, but they're still on the drawing board.
We don't do foreign keys in the way they're understood in relational databases.
So for example, we don't do cascading deletes or things like that.
So RethinkDB is much, it has way more relational features than any other document database that I can think of.
Like certainly way more than Mongo.
But it's not quite as good for relational data as like say Postgres or Oracle or SQL Server or MySQL or one of the many relational database management systems.
Okay.
Yeah.
Very interesting.
What does it look like to use this?
And maybe you could give us, I don't know, an example from the Python driver, if you know it off the top of your head, or if not, just from any other of the drivers.
Like if I create a new project and I want to, I have Rethink running, how do I connect to it and get going?
Like what are the steps?
You don't have to say code exactly.
One of the biggest design goals that we had was Rethink is to make it very, very easy to use.
And we literally thought like every extra step that a developer has to go through will cut our user base in half.
So we just made it as simple as possible.
And we spent a lot of time doing that.
The easiest way, I mean, to figure it out is like if you go to rethinkdb.com slash docs,
there's like a 30-second tutorial that shows people how to use it.
But in Python, it's very simple.
You import RethinkDB, and it's just a Python driver for Rethink.
You say RethinkDB.connect, and then you run a query.
Like for example, it's a table users.insert.
You just put a document in there, .run.
That inserts the document into the database.
It's really, really simple.
It's just a couple of lines.
Yeah, and you guys have a nice fluent API where you say, I want to create a query, .filter by this, .limited by that, and order it by that, and so on, right?
You can chain them together in a really nice style.
Yeah, so that was inspired by jQuery.
So the goal of the query language was, first of all, to make it seem native in the programming language that people use.
So if you're using Python, the query language, I mean, it's just Python.
If you're using Ruby, it's just Ruby and so on.
And one of the biggest kind of challenges that people run into when they use SQL is if you look at Stack Overflow questions that people asked about SQL, they're kind of different from questions about any other programming language.
Like if someone's using Python and you look at Stack Overflow questions, the questions are like, I'm trying to do this.
It's not quite working.
I don't understand what's going on or how does this function work or things like that.
But in SQL, people ask weird questions like, I want to do this.
I don't know how to express it.
Like, how do I even do this?
Right?
And that's because SQL was designed for business analysts, and it's kind of like, it was sort of meant to be like English, but it's not really English because it's a programming language, of course, or a query language.
So it's kind of challenging.
And the goal with Requel was make it be, you know, really, really intuitive.
So you start out, and you can think of it as a data flow language, kind of like Bash and Pypes, where you start out with a table, and then you say,
I want to run this transformation, and then I want to run that transformation after that, and then you can keep changing things.
And it turns out to be really intuitive because people can write queries by just changing on things and seeing intermediate results and incrementally building up the query until they finally get to what they want.
So with Requel, it just becomes really, really easy to express what you want in a way that I think SQL could never allow people, just because of the fundamental differences in the design.
Yeah, it feels a little more written for programmers in a simple way rather than trying to create yet another language.
So yeah, that's really nice.
Yeah, for sure.
Yeah, that's really nice.
So one thing that you guys focus on a lot, and I think it feels like it's a little bit of the influence of your co-founder, Michael, is design and the way it feels to use software.
All of the design stuff and usability, that's mostly Michael's doing, and Michael really cares about the user experience.
And he takes it from, you know, I mean, it's not just how things look or how many steps you have to go through.
He thinks it through to the point of, like, what does the user feel when he interacts with a particular feature?
What does the user feel when he interacts with the product as a whole?
So he spends a lot of time just thinking holistically about the user experience and the kind of subjective experience the developers go through when they use the product.
And that permeates everything.
That permeates the query language.
That permeates, like, the install process, the art that goes into everything to be and goes into the documentation to make things easy.
You know, the website, the admin console, like, all of these things.
Yeah, I was thinking specifically the admin console because a lot of databases, the tools that use them feel not so great, right?
Like, sometimes you just have a command line interface to it.
You know, if you have a UI, it usually looks like it was created by a DBA.
You know, something like this, right?
It's not a great experience, but you guys have, like, a beautiful, simple-to-use web management interface for your databases, even for, like, sharding and replication and failover and all these kinds of things, right?
Yeah.
So our hypothesis was that, like, people spend—if you're running a web application, there's a lot you do on the front end, sometimes a lot on the back end.
But the database is at the core of the thing, so people spend most of their time writing database queries.
And if you think about, like, what's that like for the application developer?
Well, that means they spend, you know, six, seven, eight, sometimes more hours a day just dealing with the database product.
It's their life at work.
And it was very important that that experience is pleasant for them.
And that, for me, it's a lot of different things.
But one of the biggest ones is we thought that there needs to be almost like a development environment where people feel comfortable, that's easy to learn, easy to experiment with queries, easy to figure out what's going on, easy to test things, play around, easy to figure out what happens in your cluster.
So that was the goal of the web UI.
It wasn't an afterthought.
It was something we thought was very, very important for the people—for our users, right, for developers that are going to use Rethink.
Because they spend so much time in it every single day that not adding it or not building it and not thinking it through almost didn't really make any sense.
Like, we were really surprised that that doesn't exist in a lot of other database systems.
Because if you think about how much time people spend on them, that just seems like a crucial, crucial thing to do.
It would almost be like building a compiler without having a text editor.
Like, the text editor is a fundamental part of writing programs.
It's really, really, really important.
Like, you need a good compiler, but without the text editor, like, just the experience of using the compiler would be miserable.
Yeah, that's a good analogy.
It feels like you guys really focus on making, interacting with the whole system delightful.
Yes, that's very important.
Yeah, one of the things that really surprised me in a positive way was I heard that you guys have a full-time artist.
Like, if you look at your documentation, you have little, like, cartoon characters and stuff to make it feel friendlier.
You know, like, if, in particular, I have, like, rethinkdb.com slash docs slash quick start pulled up.
And there's, like, a little database walking up to this character.
Most database companies I think of are on the opposite spectrum of this type of experience.
This is really cool.
Yeah, definitely.
So, when we were first shipping everything, like, before the first version, we thought it was important to do just basic things that you do, like, you know, branding.
Just, like, kind of the things that every open source or every project does in general.
So, we hired an artist to do a lot of the work.
And Annie kind of came in and she did the original things.
But she also had an enormous amount of passion around art.
She brought that passion to the company.
And it became immediately obvious to, or, you know, very quickly it became obvious to Michael and I that Annie's work and her passion for the art can permeate a lot more than just the basic things, like, you know, the logo and some illustrations on the front page.
And she was very adamant about, like, hey, this could really change the experience of people interacting with the product.
And because Michael is a user-experienced person, like, he immediately grabbed onto this idea.
And Annie did a couple of things early on.
Like, she made the dog.
She made illustrations for the documentation.
And people started commenting on it.
Like, on Twitter, people would say, wow, that makes everything feel way more accessible.
She brought that passion into the company.
And then it was just obvious that it makes everything way better for our users.
And no one else does that.
So, it was also kind of differentiating for the company because people notice it.
She, like, added this whole new dimension of interacting with the software project that you don't often see in other projects.
Yeah.
I'm sure you guys are really delighted.
Like, wow, this really does make this so much friendlier.
It's cool.
I really like it.
It's a nice touch.
Yeah.
It's kind of unobvious at the beginning that that would matter.
But then when we did a couple of these things and, like, everyone started noticing and people started commenting, like, wow, this makes everything way more accessible.
We were like, yeah, we need to do more of this.
Yeah, for sure.
This portion of Talk Python to me is brought to you by Hired.
Hired is the platform for top Python developer jobs.
Create your profile and instantly get access to 3,500 companies who will work to compete with you.
Take it from one of Hired's users who recently got a job and said, I had my first offer on Thursday after going live on Monday and I ended up getting eight offers in total.
I've worked with recruiters in the past, but they've always been pretty hit and miss.
I tried LinkedIn, but I found Hired to be the best.
I really like knowing the salary up front.
Privacy was also a huge seller for me.
Sounds awesome, doesn't it?
Well, wait until you hear about the sign-in bonus.
Everyone who accepts a job from Hired gets $1,000 signing bonus.
And as Talk Python listeners, it gets way sweeter.
Use the link Hired.com slash Talk Python to me and Hired will double the signing bonus to $2,000.
Opportunity's knocking.
Visit Hired.com slash Talk Python to me and answer the door.
Can you talk about the community around RethinkDB?
It's grown really quickly.
You've got a very passionate user base.
You guys do a lot to engage the community.
Can you talk about some of the things you do?
Yeah.
So the user community is one of those things that's also the core of the company.
We thought it's very important to do good community building and connect with our users.
And usually what happens with open source is people, they'll build up for the idea that people have about open source is you build a software and you make the source code available.
But that doesn't make a community happen, right?
And actually, most of the work is done by Michael.
And we have someone here, Christina Kielan, who does a lot of community management.
She's absolutely amazing at it.
And so the way we approach the idea of building a community is everyone who uses RethinkDB or contributes to it in any way is kind of equal.
And we, the employees of the company, we just happen to be paid for our work, but we're also just members of the community.
And what that means is it's not just about publishing the source code.
It's about doing everything openly so that users could communicate with us.
Like, for example, we do all design discussions on GitHub.
And it's, you know, our employees comment on features and design proposals and things like that.
But they do it with our users because anybody in the world who's using RethinkDB can go on GitHub and say, hey, I think this should be done this way.
People can contribute.
So the whole thing is done in the open.
And that is huge for fostering a good community because people feel invested in the project and they feel like, you know, their opinions are really going to be heard and that they can kind of drive the direction of the project.
They can drive the direction of the features, how they're going to be designed.
So that's one of the things that we do.
The art is really important.
We do a lot of local meetups.
We try to engage everyone on social media, you know, on Twitter, Facebook, things like that.
So community is just, it's about as fundamental to RethinkDB as the software itself.
And we take it really seriously and we think through a lot of the interactions, you know, how users feel, how they interact with the project.
So it's been a pretty big deal for us.
And at the beginning, like, we didn't know whether any of this was going to work.
But then the community grew really, really quickly.
And, yeah, it turned out to be really important.
That's great.
It's one of the really cool aspects of open source, right?
And you guys have a successful, thriving business based on a thing that I can go to GitHub, click download as a zip file or a clone.
And I have the product, basically.
And so I'm really fascinated and delighted when I see companies making successful businesses out of open source projects.
Can you talk about what it's like to run a business where the main thing you have is sort of given away or out in the open?
Yeah.
Sometimes I talk to my dad about that and he still doesn't understand how this works.
He's like, okay, so you give away the product for free and anybody can get it for free, right?
Like, how does that work?
Yeah.
And so what happens with, particularly with RethinkDB is our goal was to make it available to anybody who wants it.
And if the product is good and the world is really going in the direction of real time, then eventually RethinkDB will be in most of the development steps.
So what we wanted is to make it accessible to anybody who wants it.
Like if it's a student who's building a new project or experimenting with new ideas or a hobbyist, they should be able to get it for free.
But with a product like a database, it's very easy to run it on your laptop and you don't need to pay for it.
You don't need any support.
But if you're a big organization that's deploying RethinkDB across five data centers around the world,
there are enormous amounts of operational challenges that these companies have to deal with.
And they're pretty risk averse too.
So, you know, they can't, you know, if you're deploying a big application across the world, like it can't fail.
You have to make sure you do health checks.
You have to make sure everything works right.
So for companies like that, we sell support and services.
And most of the revenue comes from that.
And that wouldn't work for every open source project.
Because, for example, if you're selling like a developer tool, like a text editor, there is no operational component in it.
But for open source projects that have a big operational component, like it has to run 24-7, people take that very seriously and they buy support, you know, in big organizations.
So that's how the business works.
And it's not applicable to every open source project.
It's only applicable to open source projects where there's a big operational part.
If there isn't a big operational part, there may or may not be open source business there.
I don't know exactly.
But for us, it's the big, large-scale operational component that makes the financial aspect of the company work.
Yeah, that makes a lot of sense to me.
I guess if you're building a product where you draw the architectural diagram and your product is on the bottom or if it's like a hub and spoke and your product is in the center, that's a thing that can't fail.
And databases cannot fail, not in the sense that it has a bug or something.
But, like, if somehow it goes down or you can't connect for it or it doesn't replicate, like, all sorts of bad stuff happens when the data stops flowing, right?
So you're right that you're in somewhat of a unique place where this is really something that people depend upon.
Yeah, absolutely.
And another thing about databases is that Rethink is really easy to use, probably about as easy as any other project you can think of, but, you know, with the same complexity.
But it's also, at the same time, databases are fundamentally complex and distributed databases are even more so.
So we make it very, very easy.
I mean, you can distribute everything to be in the click of a button.
But if you have enormous amounts of data and many, many data centers, people will pay for support just for the safety of knowing that if something goes wrong, they can pick up the phone and their problem will be solved.
And it's really, really important because their businesses depend on it.
So, yeah, for distributed databases like Rethink, that's what makes the whole thing work.
There are examples.
So, for example, with, like, web servers, they're relatively simple and they're really robust now.
So you wouldn't necessarily buy support if you use, like, Nginx or Apache.
So Rethink is definitely in a unique position.
I wouldn't necessarily take this lesson and apply it to every open source project.
Right.
But if you think it through a little bit, there are a lot of projects where this methodology applies.
Absolutely.
Every project kind of has to find its way.
You know, I had Pablo Hoffman from the Scrapey, the open source web scraping project on.
And what he ended up doing to sort of build a business around the web scraping library was to create web scraping as a surface and have, you know, one click, push your code to the cloud and we'll handle all the infrastructure and management and scaling.
I mean, there's all these different ways.
And I just found that to be fascinating.
There's all these different ways in which you can do it.
But I think giving everybody in the Python community, the open source community examples and a bit of a look inside is really cool.
So you talked about having your database be in the whole, basically the interaction with Rethink in general, being as simple as possible and easier than everything else.
Do you ever feel like, I guess, is there a tension between, hey, we could make this even easier and, oh, but if that's easier, we might get less support calls about this.
Is that a tension that you balance or do you just always go for improving the product and then go from there?
So in practice, this turns out not to be a tension that's actually important.
Because if you look at, I mean, this isn't unique to everything to be.
This is pretty much any operational product like this.
If you look at where most of the revenue comes from, it comes from really, really big customers.
And if we think it doesn't matter how easy we make it used, we make it be like big customers will still have enormous challenges that very few people face.
It doesn't matter which product they use.
Like we make their challenges go away, but they still have to pay for support.
So the tension comes in play when you're talking about smaller customers.
But smaller customers don't really pay that much for databases anyway.
So, you know, if you're trying to maximize revenue, you can pretty much not worry about like really small businesses because they won't pay that much anyway.
And you can focus on selling, on making, you know, the commercial aspects of the project really compelling to big companies.
And for that, there is no tension between ease of use and revenue whatsoever.
For smaller businesses, yeah, there's a little bit of that tension.
But if you look at the numbers, it turns out not to be that important.
So we never really think about it.
We make it as easy as possible every time.
Cool.
That makes a lot of sense.
I mean, big companies just want reassurances, right?
When you're a 50,000 person business and the thing that you guys sell depends on the data that keeps flowing, it doesn't matter if you can push a button to like scale.
They want somebody that will take away the risk around that, right?
Yeah, it's taking on the risk.
It's also things like training.
Like, for example, most of our big customers, like the teams that interact with RethinkDB, you know, they can be up to 100, 150 people.
And it's not that 150 people necessarily like work with Rethink itself, but they're somehow related, you know, to the application or the operations of it or something that's relevant.
So you have to train.
If you think about it from a high level perspective, like you have to train 150 people to use this new product.
Like, yeah, they could learn it on their own.
They could go online.
They could read the documentation.
But we have structured courses where we can come in and we can teach people and get them up to speed very, very quickly and get them to be productive.
So it's big companies have a whole different layer of challenges that they face.
And they have usually more money than time.
Yeah.
So they're happy to trade one for the other.
And that's essentially what we do.
Sure.
If you have to get 100 people up to speed on something, training is so much more often the right answer to do it in a week or two rather than say, okay, everybody, go figure this out and we'll get back together.
Yeah.
So you guys just had a release.
What was it?
2.3 that you added a bunch of new features.
Do you want to highlight that?
Yeah.
So we do.
One of the things about our releases is we try to do frequent releases.
We try to release a new version of Rethink every two to four months, depending on how things go.
So the 2.3, we had user accounts, we had encryption, we added official Windows support.
So a lot of these features, they're a little bit boring in the sense that most of these were built for bigger companies.
Like as we get more and more big customers, they have demands that may not be necessarily important to developers that like download Rethink and try to build a simple app.
But yeah, RethinkDB 2.3 had a lot of features like that.
We're kind of targeted at big customers.
They were targeted at scale.
Things like encryption, compliance, like a lot of stuff like that.
In RethinkDB 2.4, which is coming out, we are adding a lot more things to the query language that are going to be really, really exciting.
We're adding real-time aggregations so people can do real-time analytics much easier.
We're kind of expanding Requel to support new terms.
There's going to be a lot of exciting stuff pretty much for everybody.
Okay.
That's awesome.
Yeah.
Some of those enterprise features, they don't make you jump up and down with excitement.
But that's critical to being adopted in these big companies.
And that's an important part of the business, right?
Yeah.
I mean, it's really important.
If you're running a database across multiple data centers over the internet, encryption is extremely important.
So we have to add that.
It's not necessarily that exciting, but it's kind of a showstopper for a lot of big companies.
Yeah.
Is there a Rethink as a service?
Like, can I go somewhere and pay $10 a month and have a small Rethink cluster I can work with or something like this?
Yeah.
So there are a couple.
The biggest one is actually done by IBM.
They bought a company called Compose.io.
You can go to compose.io.
And they host, actually, like most documentary-oriented databases.
So they do RethinkDB, MongoDB, Elastic, I think a couple of others.
It's pretty inexpensive to get started.
It's very cheap if you just want a single node.
And then they allow you to scale up pretty much as much as you want.
So Compose.io is probably the easiest way.
There are a couple of others.
And, of course, people can run it on Amazon themselves.
There's lots of different options.
But most users that want Rethink as a service use Compose.io right now.
Okay.
Yeah, that's cool.
Nice of that's out there.
So while we're talking, I'd like to talk about Horizon.js.
So tell me what Horizon.js is.
So Horizon.js is a new project that we just launched a couple of weeks ago.
It's built on top of RethinkDB, and it was an experiment that I actually think turned out to be really successful.
So what happened was the motivation behind Horizon, like what happened was a lot of users who were new to databases,
they wanted to build apps, mobile apps, web apps.
So they'd go on the bug tracker, and they'd say, hey, I'm trying to access the database from the browser, and it doesn't work.
And, of course, it wouldn't work because databases fundamentally have to be accessed from a back end.
And people kept asking this question, and we thought, hey, maybe we can make it easy to access the database from the browser.
So we built Horizon, which is a prefabricated back end, and what it lets people do is build JavaScript apps without writing any back end code.
So you can build a mobile app or a web app, and the back end, all of the back end is handled completely by the Horizon project.
You just start Horizon.
It's basically a server.
It connects to RethinkDB, and then all you have to do is write code on the front end,
and then all the back end stuff will be handled by Horizon itself.
So what that does is it makes building real-time apps dramatically easier, again,
because you don't have to write a single line of back end code.
And the goal behind Horizon was as people build more sophisticated apps,
they're going to, of course, need to write back end code.
So when the app gets complex enough, you can stop using Horizon as a standalone server and import it into Node.js
and start writing back end code and still use all of the Horizon services.
That's Horizon, and we didn't know how important it was going to be.
We wanted to try it.
It seemed like it would make a lot of people's lives easier.
And right now, so we launched it a couple of weeks ago.
I think right now Horizon already has a quarter of RethinkDB's user base.
So it turned out to be pretty successful, and it's growing.
It makes building things easier.
Yeah, people must have really been waiting for that.
So interesting that it basically, it's not so much a front end thing as it is a back end with an API
to alleviate the need for front end people to write back end code that they probably would rather not write anyway.
Yep, that's exactly what it is.
Horizon doesn't, so it does come with a small front end library,
but it's meant to be used with React or Angular or one of the many, many front end frameworks.
We don't actually do very much front end.
It's just, it helps front end developers build apps without writing back end code.
That's kind of all Horizon is, but it's a lot.
Because it turns out that there's an enormous amount of plumbing that people have to deal with over and over and over again,
and Horizon just takes care of that.
Yeah, that's cool.
And what's it written in for the back end?
Is that like a custom Node.js server or something different?
Yeah, Horizon is all Node.js.
Yeah.
When you said you can take it and plug it into Node, I figured you guys must just be going,
here's the Node thing you've got to run, and if you want, you can put it into your app, right?
That's cool.
Yeah, that's exactly how it works.
Can you talk about the popularity of various back ends for Rethink TV or middle tier, I guess?
How frequent is it that people are working with it from, say, Python versus Node versus Ruby?
Do you know those numbers?
So I actually, I don't know these numbers off the top of my head.
My intuition is that most of the users, everything could be used in Node.js.
I think Python is the second biggest, and Ruby is very close.
Java is really popular in enterprise environments.
.NET is really popular in enterprise environments.
I think Node is still the biggest.
I honestly don't know the exact breakdown.
And it's kind of actually hard to figure out because the drivers are accessible through the package managers for their respective language.
And some of them have statistics, some of them don't.
Like, some of them measure statistics differently, so it's fairly hard to compare.
Yeah, apples, oranges, yeah.
Yeah.
Okay, interesting.
I noticed something that you guys have on your Horizon project that's in private beta.
Well, it's almost all that way because it's just so brand new, right?
But it is this thing called Horizon Cloud.
What's that?
Well, so Horizon Cloud is a way for people to deploy and manage and scale Horizon applications.
So the whole stack is open source, right?
Rethink TV is open source.
Horizon is open source.
Anyone can download them.
Anyone can build an app.
You can deploy the app any way you want, you know, on Linode or AWS or Azure or pretty much in any way that you want.
But deploying an app at scale is still pretty challenging.
And what we learned from our customers is very often, you know, they'll make these huge Rethink TV and Horizon deployments.
And they'll call us and, you know, they'll buy a support contract and we help them out with a lot of these deployments.
So in this process, we learned a lot about best practices.
We learned about the patterns of, you know, how to scale big applications, how to scale big Rethink TV clusters.
And Horizon Cloud takes, it's basically software as a service or platform as a service.
It takes all of that knowledge and operationalizes it in a service.
So the goal is if you want to deploy a massive Horizon or Rethink TV application, you can do it yourself because everything's open source or you could use Horizon Cloud and then we'll deal with all of the deployment and scaling and management issues.
So that's the goal of Horizon Cloud.
It basically makes, it takes away all the headaches of deploying and managing and scaling these applications.
Interesting.
So it sounds like it takes some of the consulting work that you might have been doing and turns it into like a framework or an offering that's automatic in some sense.
Yes.
Yeah, that's exactly what it does.
And the goal with Horizon Cloud is so you could deploy, Horizon Cloud right now is building the Google Compute Engine.
So we'll deploy everything to Google Compute.
But eventually Horizon Cloud will run on pretty much any backend cloud service.
So people will be able to pick.
And for enterprise customers who don't necessarily want to run on the cloud, they'll be able to run Horizon Cloud on their own internal infrastructure.
Okay.
Yeah, that sounds awesome.
So congratulations on the launch with Horizon because that really looks like something people were waiting for.
Yeah, we're very excited about it.
It was a lot of work and a different kind of work from building a database, but people seem to really like it.
Yeah, it's cool.
You know, you get really successful as the one thing like RethinkDB.
And you think, well, how are we going to make another thing that's equally successful, right?
It's really challenging but also interesting to create these new products that somewhat level up on each other but at the same time are new things.
So, yeah, nice.
Yeah, it's really exciting.
And you kind of get better at building products after a while.
So, I think building Horizon was certainly easier than building RethinkDB, but it was still pretty challenging.
Yeah.
It feels to me like whenever you build a product, an app that's going to ship somewhere major or something like that, you feel like you're almost done.
And then there's like a hundred little small things that you keep having to do.
And it just takes way longer.
So, when you finally do ship, it feels great.
Oh, yeah.
Yeah, it takes way longer even if you plan for it.
It still takes longer.
You tell yourself it's going to take twice as long and it still doesn't feel right that it takes a long.
Awesome.
So, we're just about out of time.
Let me ask you a couple of questions before we call it a show.
The question I always ask my guests when they're, and so we get to the end of the conversation is, when you write code, what editor do you use?
Emacs.
Always Emacs for me.
Emacs, right.
You have a big Lisp background, right?
Like you started out doing a lot of Lisp code.
Is that correct?
Yeah, I was really excited about Lisp for a long time and to a large degree I still am.
I still am, although we don't use it at RethinkDB.
We use a lot of ideas that come from Lisp, but not the language itself.
But, yeah, I was very excited about Lisp, Common Lisp, and I got into Emacs and Emacs Lisp.
So, that part of my background, like I still use Emacs every day.
Honestly, I don't think I'm ever going to switch to anything else.
Yeah, it's awesome.
That just sounds impossible.
It's a world you cannot imagine, right?
Mm-hmm.
Yeah, funny.
Okay, and then while you have everyone's attention, any final calls to action?
How do they get started with Rethink?
Who's maybe listening from the RethinkDB community?
You guys are amazing, and you make everything worthwhile, and you make the product better.
For anyone who hasn't used RethinkDB, I'd encourage you to go to RethinkDB.com.
You can download it in a couple of seconds.
You could get started very, very quickly.
And we're on Twitter at RethinkDB.
If you have any questions, we're always there to help out.
All right, fantastic.
So, this has been a really interesting look inside your company, building open source projects, a cool, fresh new database.
Thanks for taking the time to chat with us all.
Yeah, it's my pleasure.
Thank you for having me on the show.
Yep, bye-bye.
Are you or a colleague trying to learn or improve your Python?
Have you tried books and videos that just left you bored by covering topics point by point?
Check out my online course, Python Jumpstart by Building 10 Apps, at talkpython.fm/course to experience a more engaging way to learn Python.
And if you're looking for something a little more advanced, try my WritePythonic code course at talkpython.fm/pythonic, or recommend it to a friend or colleague.
You can find the links from this show at talkpython.fm/episode slash show slash 65.
And be sure to subscribe to the show.
Open your favorite podcatcher and search for Python.
We should be right at the top.
You can also find the iTunes feed at /itunes, Google Play feed at /play, and direct RSS feed at /rss on talkpython.fm.
Our theme music is Developers, Developers, Developers by Corey Smith, who goes by Smix.
You can hear the entire song at talkpython.fm/music.
This is your host, Michael Kennedy.
I really appreciate you all taking the time to listen, give feedback, suggestions on shows, and sharing it with your friends.
Smix, let's get out of here.
Outro Music.
Bye.