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
Thanks Bob for passing this along.
I’m looking forward to renewed interest in the 3.x codebase :)
For our 4.x plans, we’ll have to discuss here what we want to do with it and
I’m looking at everyone for input here. Even if you’ve never spoken up on this
list before, I’d lie to hear from you.
*
Thank you for that, those are the issues that are turning over in my mind also.
FoundationDB base would have improved CouchDB in a number of very helpful ways,
beyond the scalability benefits themselves (though you are right that running
FoundationDB in production is not a trivial undertaking).
> the most is the scaling limits of the database-per-user pattern
I had a discussion about replacing the db-per-user approach with a single
partitioned db having a username as a partition key for each document.
Looks easy to enforce Couch-side, both for query URLs and for new doc
_id-s. Sort of sp
Hello!
Thanks a lot for this update and overview of the situation. As users (our
company has been using couchdb since 2015 circa as the main database of our 3
tier web apps), I feel it may be preferable to move the couchdb-fdb work to a
separate project having a different name. As Janh has ment
Thank you for this feedback.
I think it’s reasonable to worry about tying CouchDB to FoundationDB for some
of the reasons you mentioned, but not all of them. We did worry, at the start,
at the lack of a governance policy around FoundationDB; something that would
help ensure the project is not b
As a user, my team and I were keenly looking forward to CouchDB v4 with
FoundationDB.
Given the current situation, it is only reasonable to come up with a
best alternative.
How about refactoring CouchDB to work with multiple storage engines?
The default CouchDB will support whatever the PMC
Hi,
That already happened. “Pluggable storage engine” was introduced in 2016
(https://github.com/apache/couchdb/commit/f6a771147ba488f80a7d29491263d19088d0eefb).
No alternative backends have yet been contributed.
B.
> On 13 Mar 2022, at 16:27, Chintan Mishra from Rebhu wrote:
>
> As a user,
Hi,
Personally, I had no specific need in mind for foundationdb to
address, I'm well served by the current storage atop ZFS, so I mostly
see downsides in adding any storage that adds new restrictions,
non-portable dependencies, or puts groups of features into silos. I.e.
foundationdb's requireme
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 inte
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 l
Just clarifying one point further down
> On 16. Mar 2022, at 14:03, Ronny Berndt 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?
> -
(With my hat on as a liaison from the FoundationDB community...)
I imagine that, like all corporate decisions, stopping work on
CouchDB-FDB was some part business reasons (which are entirely out of
scope for this discussion) and some part technical reasons. I wanted
to try and make sure to collec
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 barr
Heya Alex,
I think all these are fair assessments and I can’t think of anything atop.
Best
Jan
—
> On 16. Mar 2022, at 23:54, Alex Miller wrote:
>
> (With my hat on as a liaison from the FoundationDB community...)
>
> I imagine that, like all corporate decisions, stopping work on
> CouchDB-F
Hi,
I want to second the statements (Fynn, Ronny and others) that I see as support
for option 1 in Jan’s three ways forward:
1. Follow IBM in abandoning FDB-Couch, refocus all effort on Erlang-Couch (3.x).
“Follow IBM” in the meaning “staying together and have the benefit of a big
brand support
Hi All,
I think sticking with 3.x is the better way to go for the CouchDB
community. If anyone wants to continue with the FDB-CouchDB work. I think
the first place to start there is to change the user-facing API to better
fit with FDB.
We added some really nice unit tests for FDB-CouchDB, it might
Hi there,
We have received your request #1692199 and we'll start working on it as soon as
possible. We usually respond within 24 hours, but please keep in mind that
there may be a delay in response over the weekend. In the meantime, check our
Help Center at https://support.ecwid.com/hc/en-us
18 matches
Mail list logo
