HodGreeley

Hod @ Couchbase here. Depending on what you mean, I have to disagree. Are you talking about Vanadium Core, or Vanadium and Syncbase? From what I'm reading, Couchbase does significantly more than Syncbase. It supports many of the security features of Vanadium, although it doesn't have ACLs with things like proximity built-in.

Couchbase Lite does all this, and is a mature, shipping product with many real-world deployments (including peer-to-peer as a primary use). It's a JSON document database, with full map/reduce indexing/query capabilities. It uses MVCC (similar to git) to handle offline first + conflict resolution.

Couchbase Lite can be used stand-alone, or as part of the Couchbase Mobile stack, which includes Sync Gateway and Couchbase Server. Everything is open source, too.

I'm happy to answer questions here, you can ping me on twitter, or through our forums, etc. Hod @ Couchbase

This is complicated, because you're intertwining Sync Gateway and Couchbase Server.

Couchbase Server queues writes immediately. The default is to ack once a write is in Server memory, but you can choose other options. See the response from daschl in that thread.

I see what you were trying to get at with your question. I'm not sure we clarified enough what's going on. I'll respond on the forum.

Hod @ Couchbase here. EE would have had the same limits. If this is the limit I'm thinking of, it's there for a reason (defensive against malfunctioning implementations, and very rarely something that should be exceeded). It was increased at some point (not sure when). But CE is not crippled relative to EE.

Hod @ Couchbase here. This is inaccurate. Couchbase does not delay in writing to disk (some other dbs do). You typically want 3 nodes for high availability and failover, but it isn't required. Auto replication can also help avoid loss in many failure scenarios.

Have you had to scale anything like they describe? Prototype is one thing. They already said it got them of the ground quickly.

This seems too broad a statement to be useful. What about the memory leaks, for example? Or the lack of complex querying? Obviously one design decision was to use Firebase at all, instead of the architecture they moved to. Can you be more specific about where you think they went wrong?

An alternative to look at is the Couchbase Mobile stack. The stack in includes the Couchbase Lite database (NoSQL), Sync Gateway, which enables syncing and more, and Couchbase Server. All open source. It's pretty easy to run all yourself, or on something like AWS. The db runs on many platforms, both mobile and desktop.

Disclaimer: I work for Couchbase.

You can take a look at Couchbase Mobile for native client offline+sync capabilities, too. PouchDB integrates with Couchbase Sync Gateway, so the combo is versatile.

Seems like you're confusing Couchbase Mobile and Couchbase Server. And that wasn't a sales person that responded. It was the head of Couchbase Mobile engineering.

It's not just rights, but the ease of doing data routing with channels. For mobile, having a full stack of an embedded mobile db, sync, and backend server solves a lot of problems.