Regarding a database: Going outside of SQL is always risky. In your case, it's only worth using CouchDB if you're excited to learn something new.
In my experience, the one time I used CouchDB I found it so flakey that I recommended we refactor to use a normal SQL database. Of course, a lot has changed; but:
The big power of a relational database is that it's extremely easy to just tweak your indexes and get views of your data that you didn't anticipate when you created your schema. Document databases like CouchDB (and MongoDB) require that your data is organized in a way similar to how you're going to query it.
The other power of a relational database is transactional integrity. You can update multiple rows in different tables, and the update either happens or it doesn't. Updating multiple documents in CouchDB (or MongoDB) doesn't have the same guarantee, meaning that your data can be corrupted by an incomplete update.
Comments
Regarding a database: Going outside of SQL is always risky. In your case, it's only worth using CouchDB if you're excited to learn something new.
In my experience, the one time I used CouchDB I found it so flakey that I recommended we refactor to use a normal SQL database. Of course, a lot has changed; but:
The big power of a relational database is that it's extremely easy to just tweak your indexes and get views of your data that you didn't anticipate when you created your schema. Document databases like CouchDB (and MongoDB) require that your data is organized in a way similar to how you're going to query it.
The other power of a relational database is transactional integrity. You can update multiple rows in different tables, and the update either happens or it doesn't. Updating multiple documents in CouchDB (or MongoDB) doesn't have the same guarantee, meaning that your data can be corrupted by an incomplete update.