{"id":1631,"date":"2014-12-16T19:33:26","date_gmt":"2014-12-16T19:33:25","guid":{"rendered":"https:\/\/www.couchbase.com\/blog\/?p=1631"},"modified":"2025-06-13T23:50:14","modified_gmt":"2025-06-14T06:50:14","slug":"how-many-nodes-part-3-hardware-considerations","status":"publish","type":"post","link":"https:\/\/www.couchbase.com\/blog\/how-many-nodes-part-3-hardware-considerations\/","title":{"rendered":"How Many Nodes? Part 3: Hardware considerations"},"content":{"rendered":"

The first two parts of this series covered an overview of the 5 factors of sizing a Couchbase Server cluster<\/a>, and a more in depth look at various use cases and features and the effects they have on sizing. \u00a0The fourth part will look at the metrics for monitoring<\/a> a Couchbase Server cluster in order to determine the proper sizing and when to grow it.<\/p>\n

Now I’d like to provide some guidance on hardware recommendations. \u00a0While it would be easy for us at Couchbase to demand very hard-and-fast requirements for hardware, it wouldn’t be at all appropriate given the vast difference in use cases and application\/infrastructure environments that our customers want to use the software in. \u00a0Take for example the difference between a customer running on their own physical hardware on their own datacenter where they have access to 512GB RAM systems, FusionIO cards and 10Gig-E networking versus a customer running within Amazon’s AWS. \u00a0Couchbase’s customers span these two extremes and just about every configuration in between…you can see how hard it is for us to provide specific recommendations.<\/p>\n

At the highest level, Couchbase is designed and tested to run on “commodity hardware”. \u00a0As you can tell from above, “commodity” means different things to different people. \u00a0I always ask customers what type of hardware profile they available or want or plan with. \u00a0We then size the cluster keeping in mind the benefits of horizontal scalability and the number nodes needed support the dataset and workoad…as opposed to saying you will definitely need 6 HP DL 380s with 64GB of RAM, 24 cores of CPU and 2TB of SSD. \u00a0Our hardware recommendation will be at the intersection of your dataset and workload requirements, the resources available to you and cost. \u00a0Our documentation covers this briefly as well: Resource Requirements<\/a><\/p>\n

Okay, enough with the disclaimers, let’s dig into the details. \u00a0In the previous parts of this series, I listed the 5 factors of sizing Couchbase:<\/p>\n

    \n
  1. RAM<\/li>\n
  2. Disk<\/li>\n
  3. CPU<\/li>\n
  4. Network<\/li>\n
  5. Data Distribution<\/li>\n<\/ol>\n

    I’m going to start with the easiest first (at the bottom) and work my way up.<\/p>\n

    1. \u00a0Data Distribution<\/strong><\/p>\n

    The easiest :-) \u00a0Any production deployment of Couchbase should have no less than 3 nodes. \u00a0The reasoning behind this is for autofailover safety, ease of upgrades and further scale.<\/p>\n

    2. \u00a0Network<\/strong><\/p>\n

    The 2nd easiest :-S. \u00a0In general, you likely have very little choice regarding what type of network you have available. \u00a0These days, anything 1Gig-E or above will be sufficient for Couchbase. \u00a0If your application is particularly latency sensitive or requires extremely high throughput, you will benefit from end-to-end connectivity of 10Gig-E<\/a>.<\/p>\n

    Put as few “hops” between your Couchbase nodes and the clients in terms of firewalls and routers. \u00a0If you do need to have those in between, just realize that your latency will be affected.<\/p>\n

    When setting up XDCR<\/a>, the network variability becomes greater but it also becomes less important due to how we’ve architected that feature.<\/p>\n

    3. \u00a0CPU<\/strong><\/p>\n

    Couchbase is more about CPU cores than the speed of each one (2.4GHz versus 2.6GHz versus 3.0 GHz versus Intel versus AMD will not make a difference). \u00a0Couchbase is multi-threaded in many ways and will make use of many cores…but it’s also not a requirement to have 32 or 64 or more cores (most would agree those are not exactly “commodity”). \u00a0Start with 4 cores for a basic workload, and then add additional cores as needed for views and XDCR. \u00a0See the previous parts<\/a> of this series for more details.<\/p>\n

    4. \u00a0Disk<\/strong><\/p>\n

    This is going to be a big one, as well it should be. \u00a0Couchbase is a database, but unlike any other. \u00a0Where Oracle\/MySQL\/Postgres rely very heavily on disk performance, Couchbase separates the main application performance from disk IO which means the requirements are a lot lower. \u00a0Lower, but not non-existent.<\/p>\n