Just clarifying one point further down > On 16. Mar 2022, at 14:03, Ronny Berndt <ro...@kioskkinder.com.INVALID> wrote: > > 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. The original suggestion in this thread was thinking of CouchDB as a layer on top of a distributed data store, like FDB-Couch, but with other “backends” that cover distribution in a network and data storage. The current 3.x codebase has a feature “pluggable storage engines” that ships with the default implementation `couch_bt_engine`. There is one early and affect abandoned prototype of an in-memory implementation (hello Chewbranca ;) and I have wrote ~85% of a SQLite-based storage engine that I have not open- sourced, and I don’t know if I will be able to, but it exists and largely works. Note that the storage here is on each CouchDB node, that’s a part of the CouchDB layer cake that comes *after* distribution. In contrast, FDB takes over distribution *and* storage for us. Let’s not conflate the two concepts, and take the (lack of) interest in one as an outlook for usefulness of the other. (I think PSE for Erlang-CouchDB is useful and I hope we get at least the two variants I mentioned above properly released at some point, but that’s for a future roadmap thread, a RocksDB variant would be feasible too). What I don’t really see is an abstraction layer that allows end-users to choose between multiple distributed data stores like FDB (say DynamoDB or CosmosDB), even though that would be *really* interesting for CouchDB-interop. Those implementations would be either a lot of work, or would be so generic that they have to eschew many underlying-system-specific optimisations[1], that’s why don’t think these would appear any time soon. But they *could* feasibly be done, given enough developer time/interest. [1]: I have some experience writing a PouchDB storage backend for CosmosDB using the leveldown API and while it works, it is not taking advantage of running on a database as sophisticated as CosmosDB (née DocumentDB). Best Jan > 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 >>> >>> >>
