Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

CouchDB 3.0

blog.couchdb.org

Post reply on HN
Print view View original

41–50 of 161 posts

Re: CouchDB 3.0

#41

Post by smoyer »

I built two products on CouchDB 1.x starting in 2010 ... version three is another amazing step forward! For my more recent projects, I've replaced CouchDB with clustered PostgreSQL using JSON columns as I really enjoy the ability to write SQL queries for against the JSON and to use the built-in full-text search capabilities. I think both CouchDB and clustered PostgreSQL are amazing tools and it's nice to be able to choose between them as needed. The best advice I've heard is to choose CouchDB when you know your queries ahead of time and the data "schema"[1] is variable and choose PostgreSQL when you know your data ahead of time and your queries are variable.

[1] In this case, a JSON document but either with a JSON-schema or marshaled/unmarshaled into a strict type.

Re: CouchDB 3.0

#42

Post by freeqaz »

tbrock wrote: post #12

At this point why would you use CouchDB over something like MongoDB? Seriously asking... Over the past 5 years MongoDB has gotten a great storage engine, transactions, distributed transactions, multi master replication, first class change streams and is very very solid as a foundational piece of infrastructure you can rely on while CouchDB has languished. I can’t imagine reaching for it in my tool belt when I need a…

They are tools that solve different problems, imo. In CAP theorem[0] you have 3 groups of DBs.

CA databases: SQL databases that are hard to scale ("partition") but are always consistent and available.

CP databases: MongoDB style databases that are consistent and partition tolerant, but trade availability (sometimes your queries will fail during high load).

AP databases: CouchDB style databases. They are always available and are partition tolerant, but you may be querying stale data.

[0]: https://en.wikipedia.org/wiki/CAP_theorem?wprov=sfla1

Re: CouchDB 3.0

#43

Post by LoSboccacc »

is the lucene search indexer synchronous with couchdb days updates?

I'm wondering how people solve the common search after create pattern when using external indexes

Re: CouchDB 3.0

#45

Post by newfeatureok »

hajile wrote: post #18

Reducing max document size from 4GB down to 8MB seems hyper-restrictive. For those interested, looks like the guts of CouchDB are going to be swapped out for FoundationDB. https://blog.couchdb.org/2020/02/26/the-road-to-couchdb-3-0-...

8MB is just the default, you can switch it back to 4GB if you want, but you won't have an easy time switching to 4.0 due to the 8MB limit imposed by FoundationDB.

Re: CouchDB 3.0

#46

Post by dumbfounder »

Quarrelsome wrote: post #34
tbrock wrote: post #12

At this point why would you use CouchDB over something like MongoDB? Seriously asking... Over the past 5 years MongoDB has gotten a great storage engine, transactions, distributed transactions, multi master replication, first class change streams and is very very solid as a foundational piece of infrastructure you can rely on while CouchDB has languished. I can’t imagine reaching for it in my tool belt when I need a…

MongoDB has _suspiciously_ amazing SEO and marketing. CouchDB's by contrast is awful. As silly as that sounds as a reason to choose CouchDB it demonstrates where the respective company's priorities lie.

MongoDB is a an actual for-profit company, so of course it has marketing. CouchDB is an open source apache project. You are comparing apples to oranges.

Re: CouchDB 3.0

#47

Post by anonyfox »

Has anyone here tried to use couchdb directly within an elixir/erlang OTP application? As like, „mix install“? Would kill for couchdb as a library!

Re: CouchDB 3.0

#48

Post by yatsyk »

CouchDB/PouchDB looks very promising for offline first apps, but I can’t understand how to restrict bad clients. Client potentially could insert document of huge size or execute expensive query and degrade experience of other clients on the same server. Is it any way to prevent this?

Re: CouchDB 3.0

#49

Post by newfeatureok »

yatsyk wrote: post #48

CouchDB/PouchDB looks very promising for offline first apps, but I can’t understand how to restrict bad clients. Client potentially could insert document of huge size or execute expensive query and degrade experience of other clients on the same server. Is it any way to prevent this?

You resolve that issue the same way you would resolve the same issue if you were using Postgres - you introduce some back-end.

For your example specifically I'd use a proxy.

Re: CouchDB 3.0

#50

Post by Quarrelsome »

dumbfounder wrote: post #46
Quarrelsome wrote: post #34

Earlier quoted context omitted.

MongoDB has _suspiciously_ amazing SEO and marketing. CouchDB's by contrast is awful. As silly as that sounds as a reason to choose CouchDB it demonstrates where the respective company's priorities lie.

MongoDB is a an actual for-profit company, so of course it has marketing. CouchDB is an open source apache project. You are comparing apples to oranges.

Its not just CouchDB, I did a lot of searching a little while back and I generally just don't like how tightly they've wrapped up almost all of the results. If you go by searching alone its overwhelmingly MongoDB positive to such an extent that its hard to believe its organic.

It's definitely impressive marketing but when I'm deciding on which tool to use that arguably works against them as opposed to for them.

Post reply on HN