5 ms·

Honest question: why doesn't Couchdb receive any love on HN? It's such a perfect tool for my side projects and most projects that will never reach Twitter scal

Honest question: why doesn't Couchdb receive any love on HN? It's such a perfect tool for my side projects and most projects that will never reach Twitter scale

killingtime74 3y ago
For that scale postgres works very well. Going to need very good reasons to not use it.
- yawnxyz 3y ago
  Postgres is harder to setup; Using Couchdb can be set up completely in-memory and in IndexedDB as a prototype tool (as PouchDB), then set to sync with a hosted DB somewhere else. For < 10000 user apps, I'd want this flexibility, I think. If I have more than 10k users, I'd have more problems
  - gwbas1c 3y ago
    > Postgres is harder to setup ??? When I used Heroku, Postgres was a checkbox. Can't get any easier than that. I understand that it's more work to set up a schema, as opposed to just dumping data structures into a data store. But, as I described elsewhere in this thread, the flexibility to query any table will help dramatically as your requirements change throughout the lifetime of a product.
pokstad 3y ago
It did for a while but fell out of favor. Couch doesn’t have any current major endorsements and many companies that used it have moved onto better solutions. Couchbase had most of the momentum and it turned into a different product.
treis 3y ago
It's a cool idea but everything is just a little funky. At least that's how I remember it when I tried it a while back. That plus all the problems of coding in your DB were the reasons I didn't use it again. Shame too because the sync between couch & pouch was super cool. Feels like the way things should work.
- yawnxyz 3y ago
  The Couch / Pouch thing is really drawing me in... can't wait to learn some hard lessons about the funkiness myself...
- jinjin2 3y ago
  MongoDB has a similar sync to Realm, which seems a lot more capable than Couch sync.
  - jamil7 3y ago
    But only through their opaque sync service right?
gwbas1c 3y ago
I had a bad experience with it a decade ago: I inherited some code that used it to test-drive the technology, and it was a failed experiment. In the case of this code, CouchDB was simply being used as a dumb key-value lookup. We weren't using any special features of CouchDB. Of course, a lot has changed since, so the problems I encountered might not exist. Basically, CouchDB needed to periodically run a gargage-collection-like operation. (If I remember correctly, records were not deleted, but instead hidden until you run the cleanup.) The problem was that the cleanup process was so unoptimized that CouchDB copied the entire database without the deleted records. In our case, the disk we had was about 90% occupied, so we couldn't run cleanup. So why was CouchDB a failed experiment: First: The problem with handling deletions was rather serious, for a database. It's quite painful for a database to need 2x your anticipated storage; and for that database to continue creating records even if it blocks something like garbage collection. This lead me to conclude that the database could have other bugs lurking. I need to trust that the database won't lose data or become inoperable due to its own bugs; or due to beginner mistakes with unfamiliar technologies. Second: CouchDB offered no features that I needed for my project that I couldn't get elsewhere. I just needed simple key-value lookups. Third: Learning curve: Everyone and their dog knows SQL. This was handling a niche use case, so most likely, whoever was touching it was going to be very unfamilar with the code. Picking a well-known SQL database helps keep that learning curve in check.
- yawnxyz 3y ago
  That data cleanup caveat is an important lesson — thank you so much for sharing your hard lessons learned. I actually don't know SQL very well (coming from design), so something like Couch feel more intuitive to set up as it looks and feels like JS / JSON, with neat additions like views. I think I'll keep using Couchdb for my tiny projects, with the caveat that "if something gets bigger and more well-defined, start learning SQL" (or at least properly learn Supabase)
  - gwbas1c 3y ago
    > I actually don't know SQL very well That's a huge, huge gap in your skillset. SQL databases are generally the one-size, fits-all of databases. There's good reasons (very good reasons) to use alternate databases; but they tend to be outside of the primary use cases of an application. One of the very important features of SQL is that how you query your data isn't tied to the structures that are convenient for a particular use case. Basically, the problem with using CouchDB and MongoDB as a general purpose database is that you're storing and querying data structures, or documents. It's easy early in a project, when your use cases are small. The problem comes later in the project, when a requirement comes to query a data structure that's deeply nested inside of a document. This can incur a rather substantial performance penalty, unless you denormalize your data. For example, when I used to go to MongoDB conferences, they used the example of a message board, where all messages in a post were stored in the same document. (For example, imagine that all messages in this thread are stored in a single document.) The problem then comes when you need to support a page like https://news.ycombinator.com/threads?id=gwbas1c https://news.ycombinator.com/threads?id=gwbas1c, that lists all posts that I've made. In the case of SQL, supporting a page like https://news.ycombinator.com/threads?id=gwbas1c https://news.ycombinator.com/threads?id=gwbas1c is merely writing a new query and updating an index. It doesn't require denormalization or scanning many documents. > I actually don't know SQL very well Another reason why it's important to understand SQL basics comes from being able to write code that performs well, within reason. I constantly inherit code that uses an ORM (library that translates between SQL and objects), and the code just can't perform. The original authors didn't know SQL at all, and just assumed that the ORM would do the heavy lifting for them. > I actually don't know SQL very well You don't really need to know much SQL to get by: Just four commands, "select, insert, update, delete," (and upserts) and then understand joins. Understand transactions, and you're all set. You can leave the more advanced features to when you need an advanced database feature.

Honest question: why doesn't Couchdb receive any love on HN? It's such a perfect tool for my side projects and most projects that will never reach Twitter scale

killingtime74 3y ago

For that scale postgres works very well. Going to need very good reasons to not use it.

yawnxyz 3y ago
Postgres is harder to setup; Using Couchdb can be set up completely in-memory and in IndexedDB as a prototype tool (as PouchDB), then set to sync with a hosted DB somewhere else. For < 10000 user apps, I'd want this flexibility, I think. If I have more than 10k users, I'd have more problems
- gwbas1c 3y ago
  > Postgres is harder to setup ??? When I used Heroku, Postgres was a checkbox. Can't get any easier than that. I understand that it's more work to set up a schema, as opposed to just dumping data structures into a data store. But, as I described elsewhere in this thread, the flexibility to query any table will help dramatically as your requirements change throughout the lifetime of a product.

pokstad 3y ago

It did for a while but fell out of favor. Couch doesn’t have any current major endorsements and many companies that used it have moved onto better solutions. Couchbase had most of the momentum and it turned into a different product.

treis 3y ago

It's a cool idea but everything is just a little funky. At least that's how I remember it when I tried it a while back. That plus all the problems of coding in your DB were the reasons I didn't use it again. Shame too because the sync between couch & pouch was super cool. Feels like the way things should work.

yawnxyz 3y ago
The Couch / Pouch thing is really drawing me in... can't wait to learn some hard lessons about the funkiness myself...
jinjin2 3y ago
MongoDB has a similar sync to Realm, which seems a lot more capable than Couch sync.
- jamil7 3y ago
  But only through their opaque sync service right?

gwbas1c 3y ago

I had a bad experience with it a decade ago: I inherited some code that used it to test-drive the technology, and it was a failed experiment. In the case of this code, CouchDB was simply being used as a dumb key-value lookup. We weren't using any special features of CouchDB. Of course, a lot has changed since, so the problems I encountered might not exist. Basically, CouchDB needed to periodically run a gargage-collection-like operation. (If I remember correctly, records were not deleted, but instead hidden until you run the cleanup.) The problem was that the cleanup process was so unoptimized that CouchDB copied the entire database without the deleted records. In our case, the disk we had was about 90% occupied, so we couldn't run cleanup. So why was CouchDB a failed experiment: First: The problem with handling deletions was rather serious, for a database. It's quite painful for a database to need 2x your anticipated storage; and for that database to continue creating records even if it blocks something like garbage collection. This lead me to conclude that the database could have other bugs lurking. I need to trust that the database won't lose data or become inoperable due to its own bugs; or due to beginner mistakes with unfamiliar technologies. Second: CouchDB offered no features that I needed for my project that I couldn't get elsewhere. I just needed simple key-value lookups. Third: Learning curve: Everyone and their dog knows SQL. This was handling a niche use case, so most likely, whoever was touching it was going to be very unfamilar with the code. Picking a well-known SQL database helps keep that learning curve in check.

yawnxyz 3y ago
That data cleanup caveat is an important lesson — thank you so much for sharing your hard lessons learned. I actually don't know SQL very well (coming from design), so something like Couch feel more intuitive to set up as it looks and feels like JS / JSON, with neat additions like views. I think I'll keep using Couchdb for my tiny projects, with the caveat that "if something gets bigger and more well-defined, start learning SQL" (or at least properly learn Supabase)
- gwbas1c 3y ago
  > I actually don't know SQL very well That's a huge, huge gap in your skillset. SQL databases are generally the one-size, fits-all of databases. There's good reasons (very good reasons) to use alternate databases; but they tend to be outside of the primary use cases of an application. One of the very important features of SQL is that how you query your data isn't tied to the structures that are convenient for a particular use case. Basically, the problem with using CouchDB and MongoDB as a general purpose database is that you're storing and querying data structures, or documents. It's easy early in a project, when your use cases are small. The problem comes later in the project, when a requirement comes to query a data structure that's deeply nested inside of a document. This can incur a rather substantial performance penalty, unless you denormalize your data. For example, when I used to go to MongoDB conferences, they used the example of a message board, where all messages in a post were stored in the same document. (For example, imagine that all messages in this thread are stored in a single document.) The problem then comes when you need to support a page like https://news.ycombinator.com/threads?id=gwbas1c https://news.ycombinator.com/threads?id=gwbas1c, that lists all posts that I've made. In the case of SQL, supporting a page like https://news.ycombinator.com/threads?id=gwbas1c https://news.ycombinator.com/threads?id=gwbas1c is merely writing a new query and updating an index. It doesn't require denormalization or scanning many documents. > I actually don't know SQL very well Another reason why it's important to understand SQL basics comes from being able to write code that performs well, within reason. I constantly inherit code that uses an ORM (library that translates between SQL and objects), and the code just can't perform. The original authors didn't know SQL at all, and just assumed that the ORM would do the heavy lifting for them. > I actually don't know SQL very well You don't really need to know much SQL to get by: Just four commands, "select, insert, update, delete," (and upserts) and then understand joins. Understand transactions, and you're all set. You can leave the more advanced features to when you need an advanced database feature.