ANN: Membase to become Couchbase; Membase, Inc. merges with CouchOne

[ingenthr]

Hi all,

For the past few weeks, a number of us have had to keep some very
exciting news under wraps!

Membase, Inc. and CouchOne, Inc. are merging to form Couchbase.

The great news about this is while both are NoSQL databases, there are
a
number of areas they will benefit from one another and there is
surprisingly little
overlap between them.

You will find plenty of details on http://www.couchbase.com/

Of course, in the very short term we both have our existing roadmaps
we'll be executing against so you'll see both Membase and CouchOne
updates soon. Membase should have some new minor patch updates soon,
and we're adding a number of new features in a minor update soon.

If you have any feedback or questions after looking at the site,
please let us know.

Thanks,

Matt

--
Matt Ingenthron
Couchbase, Inc.

[Joshua Partogi]

Hi Matt,

That is a great news! Congrats for this merger. I have one question
about this merger.
How will the end product of CouchBase will be?
1. How will client connect to the database? HTTP API or Memcached
protocol?
2. How will our data stored? Key-value or document?
3. How will we query our data? Map-reduce or simple key lookup?
4. How will it scale?

Thank you,
Joshua.

On Feb 8, 4:19 pm, ingenthr <m...@northscale.com> wrote:
> Hi all,
>
> For the past few weeks, a number of us have had to keep some very
> exciting news under wraps!
>
> Membase, Inc. and CouchOne, Inc. are merging to form Couchbase.
>
> The great news about this is while both are NoSQL databases, there are
> a
> number of areas they will benefit from one another and there is
> surprisingly little
> overlap between them.
>

> You will find plenty of details onhttp://www.couchbase.com/

[BigBlueHat]

Morning, Joshua,

Thanks for the congrats! We're excited about seeing these to products
converge. I'll do what I can to answer the questions you asked, but at
this stage, things are quite formative. If you have ideas/input on
what you'd like to see, please let us know.

On Feb 10, 2:11 am, Joshua Partogi <joshua.part...@gmail.com> wrote:
> Hi Matt,
>
> That is a great news! Congrats for this merger. I have one question
> about this merger.
> How will the end product of CouchBase will be?
> 1. How will client connect to the database? HTTP API or Memcached
> protocol?

Likely both. We won't stop supporting Memcached's protocol as so much
depends on it, and the "snap in" replacement between Memcached and
Membase is a valuable feature that's a priority to keep in Couchbase.
CouchDB, of course, has it's own REST API for adding documents, and
that will need to be exposed at some level for replication, browser-
based apps, etc. So a mix of the two is most likely.

> 2. How will our data stored? Key-value or document?

The key (heh) difference between Key/Value and Document databases is
that in a Dcoument DB the docs are indexable--whereas the value of
keys in a K/V DB are not (typically). In CouchDB, a document is simply
the value of a key. However, CouchDB adds obvious constraints on the
type of value whereas Membase/Memcached does not. The best approach to
mixing these two is still open to discussion, but having the full
strength of both is important.

In a way CouchDB's attachments system is similar to a key/value store
in that they can be arbitrary files (JSON, images, whatever). It may
be that there are "attachment only" documents that contain the non-
JSON data in Couchbase--if you've upgraded from Membase for example.

All of this is in the initial planning stages, so no promises here,
just thoughts/ideas. :)

> 3. How will we query our data? Map-reduce or simple key lookup?

We'll be providing something beyond simple key look-up, but there's
(again) lots to figure out on how best to approach this problem.

> 4. How will it scale?

Up and out. :) CouchDB's scaling model is primarily horizontal
(replication). Membase provides a mix of both: more RAM and disk to go
"up" and more nodes to go "out." Scalability is an obvious priority
for both projects, and "by our powers combined" you'll have far more
options that before--scaling "down" to phones and "up" to Cloud-based
data-centers.

Hope that answers a few questions. I'm sure others will chime in soon
with ideas/explanations.

Thanks again for asking,
Benjamin

[Matt Ingenthron]

Hi Joshua,

I forgot to reply to this earlier, but my new colleague Benjamin
basically said what I would have. :)

Couchbase will keep the existing interfaces that developers know and
love. We'll be adding new functionality and new interfaces, I'm sure,
as we work out the best ways to combine the technology.

Thanks for the questions!

Matt

[Hareem Haque]

Hi Matt

When the new db come out

Best Regards
Hareem. Haque

[Joshua Partogi]

Hi Benjamin,

Thanks for the prompt reply.

On Feb 11, 3:34 am, BigBlueHat <benja...@couchbase.com> wrote:
> Morning, Joshua,
>
> Thanks for the congrats! We're excited about seeing these to products
> converge. I'll do what I can to answer the questions you asked, but at
> this stage, things are quite formative. If you have ideas/input on
> what you'd like to see, please let us know.
>
> On Feb 10, 2:11 am, Joshua Partogi <joshua.part...@gmail.com> wrote:
>
> > Hi Matt,
>
> > That is a great news! Congrats for this merger. I have one question
> > about this merger.
> > How will the end product of CouchBase will be?
> > 1. How will client connect to the database? HTTP API or Memcached
> > protocol?
>
> Likely both. We won't stop supporting Memcached's protocol as so much
> depends on it, and the "snap in" replacement between Memcached and
> Membase is a valuable feature that's a priority to keep in Couchbase.
> CouchDB, of course, has it's own REST API for adding documents, and
> that will need to be exposed at some level for replication, browser-
> based apps, etc. So a mix of the two is most likely.

It would be interesting to see the mix of the two. :-) I have also
found that the library for memcached is very messy. The data that is
sent from one library can not be read from another library. This often
happen when we need to send data from Python and read using Ruby. Any
plan to make official library that are compatible to each other?

> > 2. How will our data stored? Key-value or document?
>
> The key (heh) difference between Key/Value and Document databases is
> that in a Dcoument DB the docs are indexable--whereas the value of
> keys in a K/V DB are not (typically). In CouchDB, a document is simply
> the value of a key. However, CouchDB adds obvious constraints on the
> type of value whereas Membase/Memcached does not. The best approach to
> mixing these two is still open to discussion, but having the full
> strength of both is important.
>
> In a way CouchDB's attachments system is similar to a key/value store
> in that they can be arbitrary files (JSON, images, whatever). It may
> be that there are "attachment only" documents that contain the non-
> JSON data in Couchbase--if you've upgraded from Membase for example.
>
> All of this is in the initial planning stages, so no promises here,
> just thoughts/ideas. :)

It would be interesting to see the outcome of this also. :-)

> > 3. How will we query our data? Map-reduce or simple key lookup?
>
> We'll be providing something beyond simple key look-up, but there's
> (again) lots to figure out on how best to approach this problem.
>
> > 4. How will it scale?
>
> Up and out. :) CouchDB's scaling model is primarily horizontal
> (replication). Membase provides a mix of both: more RAM and disk to go
> "up" and more nodes to go "out." Scalability is an obvious priority
> for both projects, and "by our powers combined" you'll have far more
> options that before--scaling "down" to phones and "up" to Cloud-based
> data-centers.

Nice. This would be one of the killer feature I guess.

Kind regards,
Joshua.