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
> >
> >
>

Reply via email to