David Squier is a developer for Toyota, and the creator of Couchit, who is currently using CouchDB (and PouchDB) as the foundation for a rewrite of an existing application that will take it from a single-user/.NET model to a multi-user/Node.js/Cloud model. It’s not quite in production, but already has a fully functioning system with most the data tier complete.
He talked to us about how he first discovered CouchDB and what his experience has been like employing it in applications.
How did you hear about CouchDB, and why did you choose to use it?
I heard of CouchDB several years ago when I was working at Blizzard Entertainment. We looked at Couchbase, which was based on CouchDB. The company ended up going with Couchbase due to clustering support at the time (this was pre CouchDB 2.0).
Did you have a specific problem that CouchDB solved?
Yes. The CouchDB replication protocol and the related ecosystem (i.e., PouchDB) were the primary reason we chose CouchDB. Having written offline replication/synchronization systems in the past, I understood how complex and time-consuming such an effort is. Having an open-source replication protocol lets us build a reliable system on top of it and focus on serving our specific business needs.
For the folks who are unsure of how they could use CouchDB–because there are a lot of databases out there—could you explain the use case?
The application we’re building is called “Chassis Tuner” and it was built to work both on and offline. We run CouchDB in AWS as the canonical data source for the application.
If a user is online, they are connected to CouchDB in AWS.
If a user if offline, they run the same application, via an Electron wrapper, that embeds our React application with the Node.js server and PouchDB. A single configuration switch toggles between modes, with the offline mode replicating data from CouchDB to PouchDB.
By using pouchdb-node, we have a single API for both online and offline database operations, eliminating the need for different interfaces to handle each mode.
What would you say is the top benefit of using CouchDB?
The replication protocol. Without it, we would not be able to build our application (or would require many more months to develop a bespoke solution).
Second is the speed at which I can have other developers install, replicate, and develop with a local copy of the database is a big benefit.
What tools are you using in addition for your infrastructure? Have you discovered anything that pairs well with CouchDB?
Besides Fauxton, there are many requirements to modify existing documents, especially while in the development phase. These can be as simple as adding a new property to a document to performing dependent lookups based on keys referenced in a parent document to determine if the referenced document exists in the database.
We initially found a tool that fit the bill called Couchtato. Unfortunately, it is no longer actively maintained and lacked a number of features we needed. As a result, it was forked and has evolved into a new tool called Couchit, which we will use going forward.
Finally, we’ve created a schema registry that defines a number of high-level document “types” with standard properties. We use this to perform automated document validation using JSON Schema via AWS Lambda functions, as well as provide filtered replication.
What are your future plans with your project? Any cool plans or developments you want to promote?
Our current efforts are focused on our initial launch and the related operational data requirements. Once users start using the application and generating parts, vehicle setups, and running simulations we will start getting a rich set of data that can be used to build systems for analysis, reporting, and as inputs for machine learning.
For more about CouchDB visit couchdb.org or follow us on Twitter at @couchdb.
Have a suggestion on what you’d like to hear about next on the CouchDB blog? Email us!
On the road to CouchDB 2.0 last fall, 
CouchDB Blog 