Bucket stragegy


I m working on a first project with couchbase, after years of mysql/redis.

I m couchbase for a mobile game, we store various type of data:

user profile
messages between users
friend list

we have planned to load test our services in order to optimize our couchbase usage, but it will be great to have some feedback from experienced coucbase users.

  • is it a good stragegy to split data btwn differents buckets (one for user profile, one for friend list…) ?
  • user profile contains a large amount of data an require a lot of view, we have 10 differents view and more to come, do we have to worry if we have millions of users?

Thanks in advance

Hey @nico_ad,

With many years of relational database experience myself, I too know how different things seem. In regards to your concerns:

(1) It is best to not think of buckets as being like tables which I think you are leaning on. User profiles, friend lists, ect., can all exist in the same bucket without any issues. What you’ll typically do to distinguish between the types of data is add a property to the document like this:

    "type": "leaderboard",
    "score": 1000

    "type": "user",
    "name": "Nic Raboy",
    "username": "nraboy"

Notice the type property? A similar thing can be accomplished with compound keys. For example:


Where your keys have a human readable prefix that lets you know what type of data exists in the document.

I encourage watching this free Webinar on data modeling to give you a better idea:


(2) In regards to documents with a lot of data. I may not have a clear understanding of your question, but when you create a Couchbase View, you’ll typically return a key or just a few values. Then if you need more information you can use the document key returned to grab the rest. This prevents possibly millions of full documents from being returned, when you don’t need all the full information at a given time.

If you’re using Couchbase 4.0, you can even use N1QL queries which you’ll be more familiar with because they are more like traditional SQL.

Let me know if this answers your question or if you have further questions.