CouchDB Interviews: Jan Lehnardt posted Wednesday, August 28, 2019 by liv
This is an interview with Jan Lehnardt. Jan is part of the CouchDB Support team at Neighbourhoodie, as well as VP of Apache CouchDB at the Apache Software Foundation.
Q: Can you give a short introduction?
I’m Jan, I’ve started working with CouchDB in 2007 and have loved it ever since. I’m currently the chairman of the Project Management Committee, which means I get to write more emails than everyone else on the project, but I’m also deeply involved in the regular development and documentation day-to-day of the project. At Neighbourhoodie, I work with Joan and Diana to help our customers be successful with CouchDB in whatever way.
Q: What first got you interested in CouchDB/NoSQL?
At the time, I was doing freelance consulting around scaling PHP and MySQL installations, which had suddenly became popular. When I first heard about CouchDB, I feared that I was going to be out of a job real soon, if something like it caught on. That was two years before NoSQL became a thing, so I may have jumped the gun a little bit, but I also wasn’t completely wrong in my assumption that a revolution was coming.
I’ve stuck with CouchDB because it embodies so many of the ideals that made the web successful, and that I still believe are the right foundation for a lot of contemporary technology: HTTP for transport, JSON for storage, P2P-replication for advanced data locality, and no other database does this in a production grade way.
Q: How did you start contributing to CouchDB?
I wanted a specific feature, but the lead developer didn’t have time to look into it. They pointed me to the place where the code should go, so I got started.
Q: What’s the most convoluted bug fix you ever had to figure out?
I think Joan is already covering the most convoluted in [her interview]({% post_url 2019-08-28-interview-joan-touzet %}), so I’ll pick the most memorable one: from the start CouchDB has prided itself in being extremely robust when it comes to data storage. CouchDB will go out of its way and sacrifice a lot of niceties for making sure that data you give it is stored safely and securely. Leading up to our first major release of 1.0, one of our developers added a piece of code by accident that made it through code review that relaxed the very strong persistence guarantee to a degree where up to one second of data that CouchDB had said it stored safely could actually be lost.
A 1.0 release is a very special moment for any project, but doubly so for a database that is known for bragging about data safety even pre-1.0. Needless to say, once reports came in, the whole team at CouchDB got on the case VERY quickly. For about a week, a development team across three time-zones worked non-stop on analysing the problem, addressing the issue, and developing a tool to fix affected databases. In the end, we had zero reports of production data getting lost and we could get back to celebrating our 1.0 release.
While it wasn’t a fun problem to have, the coming together of the team working for many different companies, or on their own was a moment to behold, something that I won’t forget for the rest of my career, and I’m happy to be working with many of those people at CouchDB and Neighbourhoodie still.
Q: What’s your favorite CouchDB feature that people don’t know about?
I think don’t talk about CouchDB enough period, but we’re working hard on changing that. If I had to pick one feature though, it would be the built-in high availability of a CouchDB cluster.
I am responsible for all the operational stuff here at Neighbourhoodie, keeping servers and products up and up to date and all that. With a CouchDB cluster, standard size is three nodes, I can at my own discretion take down one node to do maintenance work, or more correctly, have my maintenance scripts do their work, and bring it back up, and the production app on top never notices anything. That way, I can cycle through all nodes with no downtime and run upgrades in a matter of minutes, where we’ve worked on projects not using CouchDB and relying on one very important database server, planning all this would be a multi-week, if not multi-month, project. The peace of mind here is impossible to measure.
Q: What would you recommend to people who are looking to adopt CouchDB for their project?
Whether you come through formal or informal education, at some point you will come across a teaching resource that will try to teach you the one true way to do data storage. It usually involves an RDBMS of some sort, and everything else needs to revolve around that: an object relational mapper, schema migrations, data normalisation, etc. While all of these things are important, and even relevant in the context of CouchDB, albeit in different forms, my biggest advice getting started is keeping an open mind. Your background might have gotten you a dogmatic intro to databases, so that anything that deviates from that norm seems weird, or even wrong, and a lot of things in CouchDB might seem weird at first, but if you do keep an open mind and accept that there might be multiple correct answers to the same question and problem spacem you’re going to have a lot of fun with CouchDB.