Hi all, I’m also an end user and maintainer of a fork of Colin Skow’s Superlogin (https://github.com/perfood/couch-auth) who is running a few single node CouchDBs with a few thousand per-User DBs.
I agree with the general tone of Ronny’s mail - keeping things simple and having a low entry barrier for folks who want to write apps with CouchDB without worrying about the backend is how I’ve gotten into using it. Same for a few users of my library that I’ve been in touch with. I’m very excited about Jan resuming the work on document based access control. To me, this would make the difference between „DB per user is clunky + annoying, but works OK if you want to build an offline-first app“ to „data is all in one place, we can properly query data across users and I’d recommend CouchDB to anyone“. Kind regards and thanks to you devs, Fynn > Am 16.03.2022 um 14:03 schrieb Ronny Berndt <ro...@kioskkinder.com.INVALID>: > > Hi, > > I think we have to look at the discussion from different angles. > It would be interesting to know how CouchDB is used in general. > > - How many users use CouchDB as a single-node database? > - How many users use CouchDB as a clustered database? > - How many CouchDB users use a cluster and reach the limits of CouchDB? > > (My) view as an end user or as a developer using CouchDB as a single-node > data backend: > > Try to keep things simple. Normally, as a user, I don't want or need to know > how a kernel of an operating system, or an engine of a car works. When i > press the > "start" button, it should run and work. The same applies to the storage of > data through CouchDB. These should somehow be saved as quickly and as best > as possible, but how > exactly what works doesn't matter to me as an end user. > > Furthermore, it should be easy to get started with installing and > administering CouchDB. > There are already countless setting options to adapt CouchDB to your needs. > My observation on Slack is that most (myself included) have much simpler > problems. > CORS-, Authentication-, Mango view-, Javascript view-, Q/N-, "bad redable > and formatted" (erlang) > error message-, DB-Backup-, Fauxton-, Replicator-, and Query-parameter > questions, to name a few. > > Development using FoundationDB as the storage backend was fairly silent. I > have no > feeling, or it is not entirely clear to me what advantages (or > disadvantages) FDB could bring as an end user, > but I don't want to have to worry about configuring a FoundationDB cluster > yet - but > maybe I'm just misjudging it and it wouldn't be like that at all. > > As some have pointed out, there are many small and useful improvements to > CouchDB 3.x > exist, which probably makes more sense for the majority of users. Robert > wrote it > that the possibility of an alternative storage backend has existed since > around 2016 and none was implemented > until now. My gut feeling is that it probably doesn't make sense to have > CouchDB-FDB in active > development state. Perhaps the best of what's going on now should be > carried over into CouchDB 3.x. > Others have raised many interesting points that I think make more sense to > implement than CouchDB-FDB. > > CouchDB is currently being pushed forward by a few developers, which is > probably due to the fact > that there are few Erlang developers who are also actively using CouchDB > and can push the development forward. > > - Ronny > > > Am Di., 15. März 2022 um 22:52 Uhr schrieb Juan José Rodríguez < > jjrod...@gmail.com>: > >> Hi, >> >> My team has been using CouchDB in different projects to support >> synchronization in mobile apps. We don't use a db-per-user pattern strictly >> but something that comes pretty close. >> >> So far we have not encountered the limits and we are comfortable with >> CouchDB 3.x., we were not particularly interested in incorporating >> FoundationDB as we intuited a significant increase in the complexity of the >> architecture which, at least in our case, was not necessary (admittedly in >> exchange for very interesting functionalities). >> >> We prefer to refocus development on CouchDB 3.x, we do not have a clear >> position on the CouchDB-FDB option but would be concerned about any option >> that would result in dividing the project efforts. >> >> We believe that CouchDB 3.x has a lot of room for development with features >> that can help increase its adoption and improve its usage at least in our >> context: >> - Incorporate support for mobile sync clients, e.g. allow initial syncs >> without deletes. >> - Rethink the db-per-user pattern, perhaps as an idea partitioned _changes >> streams could help improve this aspect. >> - Allow permanent document deletions or something like expiration policies >> for deleted content. Any functionality that helps to keep databases >> compact. >> - Perhaps, better support for conflict resolution >> >> Thanks, >> Juanjo >> >> El jue, 10 mar 2022 a las 17:24, Robert Newson (<rnew...@apache.org>) >> escribió: >> >>> Hi, >>> >>> For those that are following closely, and particularly those that build >> or >>> use CouchDB from our git repo, you'll be aware that CouchDB embarked on >> an >>> attempt to build a next-generation version of CouchDB using the >>> FoundationDB database engine as its new base. >>> >>> The principal sponsors of this work, the Cloudant team at IBM, have >>> informed us that, unfortunately, they will not be continuing to fund the >>> development of this version and are refocusing their efforts on CouchDB >> 3.x. >>> >>> Cloudant developers will continue to contribute as they always have done >>> and the CouchDB PMC thanks them for their efforts. >>> >>> As the Project Management Committee for the CouchDB project, we are now >>> asking the developer community how we’d like to proceed in light of this >>> new information. >>> >>> Regards, >>> Robert Newson >>> Apache CouchDB PMC >>> >>> >>
