The Changelog: Software Development, Open Source - MongoDB, NoSQL, Web Scale (Interview)

Episode Date: March 9, 2011

Steve and Wynn sat down with Eliot Horowitz from 10gen to talk about MongoDB, the NoSQL landscape, and the fun of building at Web Scale.

Welcome to The Changelog, episode 0.5.1. I'm Adam Stachowiak. And I'm Winn Netherland. This is The Changelog. We cover what's fresh and new in the world of open source. If you found us on iTunes, we're also on the web at thechangelog.com. We're also up on GitHub. Head to github.com slash explore. You'll find some training repos, some feature repos from the blog, as well as our audio podcast. And if you're on Twitter, follow Change Log Show, Change Log Jobs, and me, Adam Stack. And I'm Penguin, P-E-N-G-W-I-N-N.

This episode is sponsored by GitHub Jobs. Head to thechangelog.com slash jobs to get started. If you'd like us to feature your job on this show, select advertise on the changelog when you post your job and we'll take care of the rest. Just like FedEx. So looking for a senior technical analyst, J boss edition must be skilled in web logic,

Unix, Linux, Java, J two E double E the whole Java stack. If you're interested, apply it. LG dot GD slash nine a. And Java is interested, apply at lg.gd.com. And Java's not the only game in town for FedEx.

They're also looking for a senior-level PHP dev. Got strong PHP skills, SQL query skills against Unix and Linux environments. Java, SQL to Oracle databases are also pluses for this position. You'll also be located in Clearvale, Tennessee. Relocation assistance is available, and it is full-time. Check out lg.gd.com. White Glove Housecall Health

is a four-year-old startup that's revolutionizing healthcare as we know it. If you sling Rails or even iOS, they're looking for a developer with at least two years of Ruby and four years of practical general software development experience. Full-time in Austin, Texas.

If you're interested, apply at lg.gd slash 9c. Fun episode this week. We talked to Elliot Horwitz over at Tingen, the company behind MongoDB. Steve and I had fun talking about our favorite NoSQL store. So I hear the listeners can't tell the difference between Steve and Kenneth. Do you hear that? Yeah. People get them mixed up all the time.

On this fake radio show. On this fake radio show. This is like the cable access of the interwebs, you know? It reminds me of, oh, come on. What is it? Wayne's World? Yeah. You knew where I was going.

Party on. Party on, Wayne. Speaking of party on, we'll be at South by Southwest this week, at least I will. You are still up in the air on that, but at least look for me. I'm hanging back in Houston this time. Are you? Yeah. Well, Penguin will be solo handing out changelog stickers.

So if you see me in the concourse, holler out and you can get a changelog sticker for your laptop. And we're also getting some teas, so please stay tuned to that. If you see us at one of the conferences, ask us for them because we'll have them soon. And if you're out there and you would like to sponsor these changelog t-shirts, we are now soliciting sponsors for these changelog t-shirts.

I love it. You don't get your name on it, but you get to help pay it for them. There you go. Kenneth will be at PyCon. Steve will be at CodeConf. And we'll both be doing a special live episode at Red Dirt RubyConf, Oklahoma City, April 21st and 22nd. Looking forward to

that. Absolutely looking forward to that. Love that conference, too. They're doing a lot of great stuff. So hope to see you there. Should be a fun time. So, great episode this week. We even get a take of WebScale from Elliot. Very cool. Sounds like a fun episode. You want to get to it?

Let's do it. We're chatting today with Elliot Horowitz, founder over at Tenjin, the company behind MongoDB. So Elliot, why don't you introduce yourself and a little bit about your day-to-day role over at Mongo. Hi, thanks. I'm Elliot Horowitz. I'm the CTO and co-founder of Tenjin. So I've been working on MongoDB for about three and a half years now. Day-to-day, I write a lot of code for Mongo, work with a lot of clients, and do a lot of roadmap development and other sorts of things with the community. So as one of the project founders, why don't you give a little backstory about how MongoDB

came about? MongoDB really came out from my and Dwight Merriman's frustration working at databases in sort of the previous decade before we started MongoDB. You know, I think he and I once counted, and in a decade before we started working on this, between the two of us, we wrote a dozen different data storage pieces for systems. So, you know, things varying from simple, you know, things for storing massive numbers of images to distributed, you know, key value store-like things. They're all very niche.

They all have sort of very specific purposes in mind. And we're not general in any way. I think in every single case, we had tried some off-the-shelf solution first, whether it was a relational database or some other key value store type system. In all cases, they fell down for some reason. Basically, what we said is, there's probably a way we can generalize this and actually create a database that we would want to use and that we think we could use for most of our problems

rather than having to reinvent the wheel every time and so that's really where the motivation for MongoDB came out and then the design mostly came out from things that what would we want to use when we were starting our next project what was the ideal what would we want to use? You know, if we were going to, you know, when we were starting our next project, what was the ideal database we'd want to use? Neither of us were, you know, particularly looking to build a database. It was more about, you know, we wanted to build something that we would want to use

from our experience. Talk a little bit about those problems you're trying to solve. Were they performance related or just design-related? So it was a little bit of, you know, both from a design perspective, a scale problem. You know, in some cases it was storing billions of images. So, you know, for storing billions of images, you know, relational databases aren't really good at that. You could use file systems. You could use distributed file systems.

But they all have some problem that we found. So, you know, in our case, we were trying to store billions and billions of very small images, and all the solutions we tried didn't work very well. In other cases, we were sort of jury-rigging massive amounts of complexity on top of key value stores in order to do

document-like retrieval. Right? So if you have, like, sort of richer data types, right, there are sort of known ways to solve this with relational databases, but it ends up being a very complicated problem, or you end up storing a big blob in a relational database, but then it's hard to index on it, it's hard to query on it. And so we had sort of built a bunch of various, you know, basically hacks around both relational databases and key value stores to sort of make this work for us.

But in the end, you know, neither was very general. You know, they were all hacks, so we never, you know, they were never full-fledged databases. And so they always ended up causing some pain here or there. And really, we never wanted to write them in the first place. We really just wanted to work on our application, but we couldn't because of database limitations. It seems like one of the cries that sort of come out of the whole NoSQL thing is that different data stores for different usages. So Mongo is really flexible and does have a lot of usages, but it seems like, do you, I guess you're saying you disagree with that to a certain degree, or is it just that most of your data should be able to be stored in one database with side applications as opposed to having a more complicated setup, I guess?

So I think there are definitely a few general types of databases that will make sense long term. There are definitely places where relational databases make sense. There are definitely places where document databases make sense. There are definitely places where document databases make sense. I think that the world has gone very far on the one size doesn't fit all and running lots of different kinds of data stores. And I think that's really a reaction to limitations with the current technology. I don't think it's necessarily the right approach to have six different storage engines running inside of an application. I think it's that there is no one storage engine that can solve, or one or two, that can solve all of your problems.

And so, you know what people started doing? You know, completely reasonable people and rational people said, okay, I'm going to use this. I can't find a database that solves all my problems, but if I pick and choose different storage engines and different databases, then I could actually get my work done. And I think that that's more of a reaction to the current state of technology than the correct long-term way of thinking about storage.

I think that there is definitely an ability to create a database that solves the majority of problems. So the pendulum swings one way, and then it swings back the other way, and now we're kind of finding a happy middle place, I guess? Right, and I think that's sort of the goal. I don't think we're there today, but I think the goal is definitely to find the place

where most of your data lives in one storage engine, and maybe you use a few very niche products in certain areas. Maybe for data warehousing, a data warehouse products, a data warehouse storage system versus an online storage system may look

very different, but I don't think that it's, you know, I don't think it's a matter of having eight different storage ends. I think it may be having, you know, one, two, or maybe three in some cases. The NoSQL field is getting kind of crowded. Any of those that were out there when you started down this path that you looked at and just felt that it wasn't a good fit for what you wanted to do? So if you look at NoSQL as a whole, right, so there's really a few different types

of general databases. So you've got, you know, key value stores, you've got graph databases, and you've got document databases. And they're all very different. And so I think that, you know, I think fundamentally what we want to do is it doesn't fit well into the mold of a key value store. You know, I think key value stores are very good in some cases. They're very, you know, there's a lot of good things about key value stores, but it's not a general database.

Graph databases, again, there are certain areas where they work exceptionally well, probably better than anything else. But again, it's not a general solution. I think document databases definitely are the solution for most, at least in terms of the web infrastructure and online systems, is generally the right approach to most problems. So with all these different choices, one of the problems is developer education. So how do you manage to explain to developers the differences of all these different databases? I mean, I definitely saw a number of blog posts about Mongo where people had simply set it up wrong or had incorrect expectations about the way things worked.

And, you know, it didn't work out for them, but that's not really a fault of Mongo. It's more that they didn't read the docs. Right. I mean, so this is a constant battle for us. And, you know, I think it's just a matter of, you know, making the documentation as good as possible, making sure that we talk to lots of people, we're doing conferences around the world, basically just where we go and we just sort of talk about Mongo and what are good use cases for it, how it works, what are the design philosophies behind it,

such that when you're using it, you can use it more effectively. And it's a constant battle. Mongo is in some ways very close to relational databases. A lot of things feel familiar. But once you dive deeper than the very basic level, things change dramatically. Both changing how you have to use it and the expectations you have to get from it.

There's a big gap there. That's what's going to take time to close. And also, the other thing to remember about Mongo is because we are looking at a, you know, we're trying to build sort of a general database and not, you know, a niche product, Mongo is definitely a very large-scale project. And we've been working on it for over three years now.

And our list of sort of, you know, core features is still not complete. You know, our roadmap for the next 18 months has tons of features on it that we think are, you know, just sort of not like advanced features or not like nice-to-haves, but are just basically core features you need for a database like this.

And so, you know, in our minds, MongoDB is definitely not done. I mean, that. And so, you know, in our minds, MongoDB is definitely not done. I mean, that's definitely something, you know, an expectation we have to manage. That it's just like, yeah, MongoDB is great for lots of cases today, but in no way is it, you know, complete in our minds at this point. Well, it's been over a year since we last covered Mongo on the changelog. We were big fans then, still big fans now. So we're looking down the barrel at 1.8, the upcoming release.

What's new in 1.8 for MongoDB devs? So MongoDB 1.8 has a whole bunch of new stuff in it. The biggest, the most notable feature for sure is single server durability or journaling. And so this has definitely been one of the concerns people have had with Mongo previously, where, you know, previous to 1.8, no single instance of Mongo was durable.

So if you wanted to make, you know, guarantee the integrity of your data, the correct way to do it was making sure you had, you know, multiple servers of the data and using replica sets to make sure you had multiple copies so that any hardware failure or even a data center failure would not cause data loss. When we originally designed MongoDB, we really had more enterprise in mind, more large-scale deployments, and so we hadn't focused too much on sort of the very small instances or just someone who wants to run a two or three node instance. And so one of the big problems people have had, both in the small scale and in the large scale, was the lack of journaling.

So 1.8 has journaling, which means that on a single server, you know, if you lose, you know, on a hardware failure, on power failure, your database will not end up in a corrupt state. You will have a consistent database. So that alone is good. It also means that even if you have multiple data centers, it means that you can recover faster. So even for the enterprises, it's still really nice

because recovery time is faster in the event of a failure. So there's a lot of good things about journaling. So journaling is definitely the biggest feature in 1.8. And then for the very small deployments, it's a game changer because a lot of people, if they wanted to run a single instance on a single server, Mongo really wasn't a good fit for them because there was no way to guarantee data integrity. So that's definitely the biggest feature with 1.8.

I think that's one of the reasons I love Mongo so much is it's so approachable for new developers. I mean, it's really, it maps very closely to relational databases. It's easy to get your head around. But at the higher end, what are some of the larger installations you've seen in Mongo? So there's a number of large ones. Some of the large ones of note are places like Shutterfly and Foursquare. Both of them are storing very large data sets with lots of throughput.

Craigslist is loading up a fairly monstrous data set into Mongo as we speak. So some pretty large-scale deployments out there. And the enterprises really like Mongo. So for the single developer, one of the main reasons to use Mongo is the data model and how easily it is to code with it and how agile it is in terms of being able to add fields or adapt your schema as your application changes. At the enterprise, it's actually two things. One is the agility.

We talked to one customer who switched to Mongo simply because they were 18 months behind in their product roadmap because working with Oracle is becoming such a bottleneck. Having to change schemas and work within the limitations there was causing major delays on their product

roadmap. Larger companies also, of course, care about scalability in terms of being able to scale horizontally using Mongo sharding. Sometimes it's helpful to be able to describe a technology to also maybe draw a distinction to some other technologies. So maybe we can go down the list and name a few of these and just kind of highlight some differences and approaches between a few of these NoSQL solutions. So Mongo versus and approaches between a few of these, uh, no SQL solution. So Mongo versus react,

what do you see as the big difference there? Right. So react and all the sort of the dynamo, um, dynamo style databases are, are really distributed key value stores. And I think, you know,

I've, I've never used react in production, but I have no reason not to believe it's not a very good highly scalable distributed key value store. The difference between something like React and Mongo is that Mongo really tries to solve a much more generic problem.

So, you know, one is a couple of key points. One is consistency. So, you know, Mongo is fully consistent, and all Dynamo implementations are eventually consistent. For a lot of developers and for a lot of applications, eventual consistency just is not an option. I think for the default data store

for a website, you need something that's fully consistent. The other major difference is just data model and queryability and being able to manipulate data. So, for example, with Mongo, you can index on any fields you want. You can have compound indexes. You can sort. All sort of the same kinds of queries you do with a relational database work with Mongo. In addition, you can update individual sort of the same kinds of queries you do with a relational database work with Mongo. In addition, you can, you know, update individual fields, you can increment counters, you can do a lot of the same kinds of update operations you would do with, you know, with a relational database. So it

maps much closer to a relational database than to a key value store. Right, you know, key value stores are, you know, are great if you need, you know, if you've got billions of keys and you need to store them, they'll work very well. But if you need to sort of replace a relational database with something that has – that is pretty feature comparable, they're not designed to do that. What I hear a lot, document versus document, MongoDB versus CouchDB. Where do you see that one shaking out? So I think we've decided, you know, there's a few major differences between Mongo and Couch. And I think a lot has gone for a more

they have map reduced views which are sort of very elegant and there's some nice features there and they've also spent a lot of time working on master master replication and conflict resolution and one of their

major things they've been talking about recently at least is online syncing versus offline syncing. If you want to have a database that runs in your phone and in the cloud and have it all sync up. And that's an application that Mongo simply would not work for at all. Mongo's more focused on the core website infrastructure side of things. So more large scale, you know, Mongo has sharding built in,

much more similar feel to a relational database, whereas, you know, if you want to do a query with sorting, you create an index, you create a compound index, the same way you would in a relational database, you'd actually just go and create the index. You would do a query, you know, similar to the way you do in a relational database. In Mongo, you would say,

if I want to find everyone who lives in New York sorted by age, it would be something like find where city equals New York, sort by age. And so it's a much more relational feel to it. Speaking of geospatial, you guys have just tweaked, is it in 1.7 or 1.8 that you tweaked the geo index to be not just rectangular but elliptical? So 1.7, 1.8 is kind of the same thing. 1.7 is the development version. So basically in 1.8 we'll have a spherical version of geo. So if you do want sort of more precise geospatial indexing on a sphere,

it will work much better. So that's in 1.8. So if someone's evaluating Mongo, what types of application tasks do you think that Mongo does extremely well? So the most common use cases for Mongo are, you know, sort of core website infrastructure. So things like user profiles or, you know, any kind of CMS-type data.

Those are the kinds of, you know, data models that really don't work terribly well in a relational database that work very well in Mongo. Right, if you look at user profiles, for example, in a relational database, a user profile may very well encompass 50 different rows and 7 different tables. In Mongo, the nice thing is you can actually just put it all into a single document. So if you just think about user profiles and addresses,

well, if any user may have three addresses, in a relational database, you'd have a users table and a user address table. And so if you wanted to find everyone who lived in New York, you'd end up doing a join between the user table and the user address table. In Mongo, you'd have a single document. That document would have an array of addresses in it, and you can index on that array of addresses. So if you wanted to find all people who lived in New York,

you'd simply do a query like users where address.city equals New York. So it's sort of a so it's both simpler from a code perspective, and it's much more performant because you've got a single document on disk. It's always

going to be contiguous on disk, so it's like you can do one seek and load the whole thing. If you want to update it, it's talking to a single place. And you're never doing any sort of joins between on disk, so it's like you can do one seek and load the whole thing. If you want to update it, it's talking to a single place. And you're never doing any sort of joins between two tables, so it's much easier to scale horizontally. One of the things that a lot of other NoSQL databases have that

Mongo doesn't is a sort of REST interface. Is that one of those core features that you guys are thinking about adding, or is that something that is just not Mongo-like? I think there's nothing wrong with a REST interface. I think that's something that we would probably put on the nice-to-have side of the world. I think REST is...

Mongo is definitely meant to be behind a firewall. It's not meant to be sort of the front end to your website. We think that a lot of business logic should really live outside of the database, that if you want a really horizontally scalable database, your database tier and your application tier do have to be separate. And then between the application tier and the database, simply a binary protocol is going to end up being faster

and a little bit cleaner to implement, and you can do more things with it. And so we've decided to go down that route. And I think having a REST interface in the database is a nice thing. There's a bunch of community-driven layers on top of the database that give a fairly nice REST interface as well. So if people do want to use REST, they can use some of these third-party layers on top of it.

I've pretty much only used Mongo from Ruby myself, but I know that you guys have a lot of other drivers to other languages. What's sort of the breakdown, do you know, of what people use Mongo in different language communities or which ones you see more often? How does that sort of break down? We really see it across the board.

There's a ton of Java, a ton of C Sharp, lots of Ruby, Python, PHP. We have users using Perl, C++, Erlang, Haskell, Node.js. Pretty much I've seen projects in almost every language I can think of. I've personally used the Racket driver, which is pretty nice. Again, that's a community-driven project. And so there's a lot of drivers at this point. But in terms of where the usage is, it's pretty much,

when I think about web development breakdown, it's pretty much where I'd expect. Most of the enterprises are using Java or C Sharp. A lot of the smaller sites or a lot of the startups are using Python or Ruby. There's still a lot of PHP. So it's a little bit all over the map. I'm very interested in startups. And so you guys have a sort of interesting quality because you are a startup. You have a lot of the big name investors. But unlike a sort of interesting quality because you are a you know startup you have a lot of the big name investors but unlike a lot of startups now you're not a website you're actually a core technology so do you see that as being a little bit different of a feel do you feel

like you're still involved in the whole web startup world or is this you know is that sort of a dividing uh factor in any kind of way uh It's definitely very interesting because we sort of are, we go back and forth in that line a lot of times, especially because we work with a lot of the, you know, web startups. So in some ways we feel very in touch with that universe, but at the same time we are definitely not in the same space. We definitely don't, you know, we don't, you know, go to the same kinds of things. We're not affected by the same kind of changes.

So there are some similarities, but I'd say we're more different than similar to a web startup on average. I have some snobby systems friends that always poo-poo Web 2.0 websites. They kind of laugh at me every time I say that word. Speaking of laughing, what's your take on web scale? The web scale video or the... The video and the fact that it's sort of been turned into the meme, I guess, is like, you know. Yeah, so, I mean, so the day the video came out, I have to say that the Tenjin offices were... There was a lot of laughter going on that day.

And the guy who wrote it, or who made it, actually sent us an email the same day, because he's actually a Mongo user, and sent us an email saying, hey, by the way, I'm sorry about that. I didn't mean it that way. In our mind, it's all

in good fun, and I think it's one of those things with the new technology, with a somewhat, I wouldn't call it controversial, but with a sort of hot field where there's lots of companies vying for, um, vying for attention and users. Um, it's very, you know, people like latching onto things like that. So it's, but on our mind, it's all, it's actually pretty funny. You know, my take on it was that Mongo is so approachable

and that developers that may not really understand document databases and things come to Mongo and they can get their heads around it pretty easily in the same way that a lot of people that don't write JavaScript feel that they can write JavaScript when using jQuery. So it kind of lowers the barrier of entry there.

And I think it's important to be able to talk about the technology that you're using other than just the buzzwords from the website. I think that was one of the things that made it so funny is because that verbiage is directly from the MongoDB org website. Right. No, it's, yeah, it was really quite funny. So under the hood for a moment, BSON, binary JSON. So when we interviewed Douglas Crockford, he said that the JSON spec would never change because it would always be frozen in time at 1.0.

Has the same held true for BSON? Yes and no. So one of the nice things about BSON is that it's typed and the types are in the document itself. So it's very easy to add new types. So that's one of the main disadvantages to JSON for us was sort of the lack of types and the inability to extend it easily to add types.

So that was really one of the main things that the inability to extend it easily to add types. So that was really one of the main things that we did was make it easily, you know, make it easy to add types. So it's very easy for us to add types whenever, you know, as needed. So from that perspective, it's really quite easy to do. At some point, we probably will do a version 2.0. There's a,

probably a few very subtle things we'd like to tweak at some point. And, you know, and the header, in the BSON document headers actually have space reserved for a version field, so it will actually be fairly simple to change it at some point. And the website mentions protocol buffers. We've covered those here in the changelog. Was that something you considered when you set up to do Mongo, or was it you needed the traversability from the get-go?

Yeah, we looked at protocol buffers briefly, and protocol buffers were not quite so, this was three and a half years ago, so they weren't quite where they are today. But overall, I think they're a little bit different than what we think is the right fit for Mongo at the mapping side. So I don't think it's the right fit for Mongo at the mapping side. So I don't think it's the right fit for us.

I just went to the MongoDB roadmap to try to find a good question to ask you about what's coming in the future, and it says that I should contact my administrator because the page has been deleted. So is the future secret? What are you guys working on? Or can you just not tell me or you'll have to kill me?

No, I'm not sure which page you're looking at. But so the roadmap for... So for 2.0... So 1.8 is coming out in the next week or so. And so that has a bunch of stuff. And then after that,

the next release is going to be 2.0, which will be coming out sometime in May or June. So 2.0 will have a number of things, some of which will be better aggregation. One of the major focuses for this year is going to be concurrency, so there will be some fairly large concurrency improvements for 2.0. We're going to be looking at doing online compaction. We're going to be looking at doing online compaction. We're going to be looking at doing TTL timeout collections. So if you have time-sensitive data, you can age it out easily. And then better aggregation is going to be another focus for this year.

So when you're not hacking on MongoDB, what are you hacking on? There are not too many hours of the day where I'm not hacking on MongoDB at this point. I do have a, you know, I tend to write a lot of one-off C++ projects for myself to, you know, whether it's my like little CLI, you know, command line based to-do list or a few other things but at this point the vast majority of my time is on MongoDB and that's your for fun language too? Nothing higher level than that? I play

around with Python for a lot of scripting stuff. I do like Scheme so I play with Racket a lot but once I delve into anything remotely complex I usually end up defaulting back to C++ at this point. I think C++ has gotten a bad rap in many ways, and especially a lot of the new stuff coming out, you know, C++ 0x, it's really, it's quite an interesting

language, and it's actually evolving in a very interesting way, so I'm pretty excited to see it changing. Vim, TextMate, Emacs? Emacs. Tangent definitely has a split, but Emacs definitely comes out on top. So who is your programming hero? Who do you aspire to be like in your epic hacking i i would have to get back to you on that one i uh that's that's a tough one you know i think there's a lot of um

you know it's a very good question because there's definitely, you know, I think there's a lot of hackers who go two ways, right? You've got the hackers who go more project management style, right? You know, you've got Linus. Yeah. You know, you've got the Linus style who I think I saw a quote from him recently where he said most of the code he writes these days is in his email editor in response to people telling him how to fix their code. Yeah, I saw that. And then you've got people who write books, and then you've got people who end up just writing code for a long time. I'm definitely in the writing code for a long time mindset at this point,

but we'll see what happens over the next decade or so. You know, I was turned on to MongoDB from a lightning talk at, I think, Mountain West RubyConf a couple of years ago. I've been using it for almost two years now. So any tips or advice for spreading the word about your awesome open source project? I think the key for people to understand why Mongo is interesting is to understand that it's not a key value store, that it's actually good for multiple things. If you look at the two main things that's interesting because of its, you know, because

of agility and because of scalability. And on the agility side, it's not only that you can change the schema at will, it's that it's very easy to get into because the doc, you know, a document database maps very well to the way you think about objects in the real world, to the way that your code is arranged, right. You know, a MongoDB document looks very similar to a Ruby object. So it's a very, you know, if you just want to get in and start programming,

it works very well. When you want to then start making sure it's performing well, it's got all the indexing, all the features there to help you. And then if you're doing well and you need to scale it, it also helps you there. So I think that, you know, one of the keys about Mongo is that it's not just sort of, it doesn't try to solve one problem. It tries to really address the database problem as a whole and really has

features at both when you're starting out, when you're sort of in the middle stages and when you need to scale it up all the way. Well, we love using Mongo. Look forward to the new features in 1.8 and then the big 2.0 release. And thanks for taking the time today, Elliot. No problem. Thanks for having me. See it in my eyes So how could I forget when

I found myself for the first time Safe in your arms As the dark passion