4 ms·

Ask HN: Have you looked into CouchDB lately?

4 points by oblib 8y ago

beatgammit 8y ago
No. Why would I? I used it for a few years and hated it. We still have one or two internal apps that use it that we're to lazy to port to something better. I used to be hip on NoSQL, but I've decided that Postgres is good enough 90% of the time, and I've never regretted using an SQL database at the outset, but I've usually regretted a NoSQL db, and this is with non relational data (test result blobs, no need to do any kind of relational queries, just dump and retrieve data). I don't like CouchDB because the views are not intuitive and it takes a while to train a new team member on it, so I tend to just deal with it myself. Debugging reducers and whatnot is a pain, and I honestly don't see much benefit over a key/value use case of Postgres, which has the benefit of being familiar to most devs. The cases where Couch DB is the "right" choice are just too niche to be a default choice for anything, and SQL databases can usually solve those problems reasonably well too.
- oblib 8y ago
  That's pretty much what I find most SQL users say. I think your opinion comes from learning SQL first. I never used SQL for my apps so I didn't struggle with learning to do things differently. I can't say I've struggled with CouchDB, but I did have to dive into learning it. Personally, I found it much easier to get started with than SQL though. I dove into SQL back around 2001 and quickly realized that is a career choice, and not something one could just dabble with and do right. It seemed much easier to me that I could fool myself into thinking I was good with it than learning how to do it right "The cases where Couch DB is the "right" choice are just too niche to be a default choice for anything" I'm sure this has to do with personal preferences in many use cases and influenced by "what's "easiest" for me", and not because of CouchDB is lacking or poorly designed or inefficient. One of what I find to be big advantages for CouchDB is "PouchBB.js", a client side Javascript library with a very easy to use API to work with CouchDB. This lets you create apps that run almost entirely in user's web browser that, combined with "Service Workers", can run completely offline and instantly sync up with the remote CouchDB when they come back online. After you've got over the hump of setting up a CouchDB almost everything else needed to create an app can be done with PouchDB and that is fast and easy.

4 points by oblib 8y ago

No. Why would I? I used it for a few years and hated it. We still have one or two internal apps that use it that we're to lazy to port to something better. I used to be hip on NoSQL, but I've decided that Postgres is good enough 90% of the time, and I've never regretted using an SQL database at the outset, but I've usually regretted a NoSQL db, and this is with non relational data (test result blobs, no need to do any kind of relational queries, just dump and retrieve data). I don't like CouchDB because the views are not intuitive and it takes a while to train a new team member on it, so I tend to just deal with it myself. Debugging reducers and whatnot is a pain, and I honestly don't see much benefit over a key/value use case of Postgres, which has the benefit of being familiar to most devs. The cases where Couch DB is the "right" choice are just too niche to be a default choice for anything, and SQL databases can usually solve those problems reasonably well too.

oblib 8y ago
That's pretty much what I find most SQL users say. I think your opinion comes from learning SQL first. I never used SQL for my apps so I didn't struggle with learning to do things differently. I can't say I've struggled with CouchDB, but I did have to dive into learning it. Personally, I found it much easier to get started with than SQL though. I dove into SQL back around 2001 and quickly realized that is a career choice, and not something one could just dabble with and do right. It seemed much easier to me that I could fool myself into thinking I was good with it than learning how to do it right "The cases where Couch DB is the "right" choice are just too niche to be a default choice for anything" I'm sure this has to do with personal preferences in many use cases and influenced by "what's "easiest" for me", and not because of CouchDB is lacking or poorly designed or inefficient. One of what I find to be big advantages for CouchDB is "PouchBB.js", a client side Javascript library with a very easy to use API to work with CouchDB. This lets you create apps that run almost entirely in user's web browser that, combined with "Service Workers", can run completely offline and instantly sync up with the remote CouchDB when they come back online. After you've got over the hump of setting up a CouchDB almost everything else needed to create an app can be done with PouchDB and that is fast and easy.