{"id":1630,"date":"2014-12-16T19:33:21","date_gmt":"2014-12-16T19:33:21","guid":{"rendered":"https:\/\/www.couchbase.com\/blog\/?p=1630"},"modified":"2025-06-13T23:50:15","modified_gmt":"2025-06-14T06:50:15","slug":"how-many-nodes-part-2-sizing-couchbase-server-20-cluster","status":"publish","type":"post","link":"https:\/\/www.couchbase.com\/blog\/how-many-nodes-part-2-sizing-couchbase-server-20-cluster\/","title":{"rendered":"How Many Nodes?  Part 2: Sizing a Couchbase Server 2.0 cluster"},"content":{"rendered":"<p>In the <a href=\"https:\/\/www.couchbase.com\/blog\/how-many-nodes-part-1-introduction-sizing-couchbase-server-20-cluster\/\">first part of this series<\/a>, I gave an overview of the 5 factors that determine the sizing of your Couchbase cluster: RAM, disk (IO and size), CPU, network and data distribution. \u00a0In this second part, I want to go into more detail about specific use cases and scenarios to see how various application designs and workloads affect these various factors. \u00a0The <a href=\"https:\/\/www.couchbase.com\/blog\/how-many-nodes-part-3-hardware-considerations\/\">third entry<\/a> in this series goes into different hardware and infrastructure choices. \u00a0Finally, the <a href=\"https:\/\/www.couchbase.com\/blog\/how-many-nodes-part-4-monitoring-sizing\/\">fourth entry<\/a> looks at the metrics that you can monitor both within and external to Cocuhbase for understanding the sizing requirements.<\/p>\n<p>A Couchbase Server 1.8 cluster was fairly straightforward to size, and you can find a discussion on this here, along with a calculator. \u00a0With the recent feature additions to 2.0, this gets a little bit more involved&#8230;<\/p>\n<p>Let\u2019s look at two application design and requirement considerations that will have an impact on your cluster sizing:<\/p>\n<ul class=\"rteindent1\">\n<li>Is your application primarily (or even exclusively) comprised of individual document access? \u00a0Or do you expect to make use of our Indexing and querying feature? A good description on how to combine key\/document access and views can be found here.<\/li>\n<li><span style=\"font-family: inherit;font-size: 1em\">Do you plan on using the new <\/span>Cross-datacenter replication (XDCR) feature<span style=\"font-family: inherit;font-size: 1em\">?<\/span><\/li>\n<\/ul>\n<p><strong>Individual Document Access and upgrading from 1.8<\/strong><\/p>\n<p>The simplest use case to discuss is when an application really only requires individual document access (typically referred to as a \u201ckey\/value\u201d use case). \u00a0These include session and user profile stores, ad targeting applications, many social games, etc.<\/p>\n<p>Sizing these use cases maps very similarly to the 1.8 sizing guidelines with a few modifications. \u00a0As with all sizing discussions, the same 5 determining factors apply, with RAM sizing typically being the one that wins out here.<\/p>\n<ul class=\"rteindent1\">\n<li>RAM: See <a href=\"https:\/\/www.couchbase.com\/blog\/how-many-nodes-part-1-introduction-sizing-couchbase-server-20-cluster\/\">part 1<\/a> for a discussion on the considerations of sizing RAM properly. \u00a0For those of your familiar with 1.8, not much has changed here. \u00a0If you are \u00a0not familiar, take a look at our sizing guidelines and calculator.<\/li>\n<li>Disk: \u00a0Keep in mind that upgrading from Couchbase Server 1.8 to 2.0 may require considerably more disk space. \u00a0\u00a0From an IO perspective, the append-only disk format will actually read and write data faster and more consistently than 1.8. \u00a0However, there is also the need for online compaction of the disk files to take place and this will require some amount of added disk IO. <a href=\"https:\/\/www.couchbase.com\/blog\/compaction-magic-couchbase-server-20\/\">This blog<\/a> may help you understand compaction better.<\/li>\n<li>CPU: \u00a0As mentioned in <a href=\"https:\/\/www.couchbase.com\/blog\/how-many-nodes-part-1-introduction-sizing-couchbase-server-20-cluster\/\">part 1<\/a>, the application reading and writing into and out of RAM can be handled very efficiently with very little CPU. \u00a0The addition of automatic compaction does add a bit more CPU activity due to the disk IO, but won\u2019t normally impact the application\u2019s performance. \u00a0While typical 1.x installations could \u201cmake do\u201d with 2 cores, we are increasing this recommendation to at least 4 even for the basic \u201ckey-document\u201d use case.<\/li>\n<\/ul>\n<p dir=\"ltr\">???When upgrading from 1.x, it would be highly recommended to engage with <a href=\"https:\/\/support.couchbase.com\/home\">Couchbase Support<\/a> so we can help review the environment, provide recommendations and aid in making the upgrade go as smoothly as possible.<\/p>\n<p><strong>Cross Datacenter Replication (XDCR)<\/strong><\/p>\n<p>Many situations\/environments create the need for data to be replicated across multiple Couchbase clusters. \u00a0You need need XDCR for disaster recovery, geo-locality of data or just simply synchronization for testing. It will be important to ensure your Couchbase cluster is sized effectively. \u00a0These capacity requirements are in addition to everything else the clusters are being asked to perform.<\/p>\n<p>For the purpose of this discussion, I\u2019ll take separate looks at the \u201csource\u201d and \u201cdestination\u201d cluster requirements for XDCR. \u00a0In production, you can have a one-many, many-one or many-many topology by combining multiple uni-directional replication streams.<\/p>\n<p>1. Source Cluster<\/p>\n<ul>\n<li>RAM: This is a bit variable, but we have seen that there is a bit of extra RAM required just to handle the process of replicating data to another cluster. \u00a0It will vary a bit based on how many buckets (and replication streams) but a good estimate is to leave about 2GB of RAM free per node above and beyond what is needed to hold the data. \u00a0This is needed by the Erlang process (beam.smp on Linux, erl.exe on Windows).<\/li>\n<li>Disk: \u00a0The current implementation of XDCR involves sending data from the disk subsystem of a source cluster to the destination. \u00a0This allows for no queues to be maintained in RAM, and the restart of a replication process to still take place without resending all of the data. \u00a0Additionally, multiple writes from the local application are automatically de-duplicated before being replicated across, saving precious network bandwidth. What this means, however, is that the source cluster of any XDCR will have increased disk IO requirements in order to read the documents once they have been persisted to disk<\/li>\n<li>CPU: The source cluster of an XDCR will also have increased CPU requirements in order to process and send the data to another cluster. \u00a0By default, there are 32 streams per node per replication. \u00a0This can be increased, but keep in mind that a higher number of streams will require more CPU. \u00a0A general best practice should be to have one extra core per XDCR bucket being replicated.<\/li>\n<\/ul>\n<p>2. Destination Cluster:<\/p>\n<ul>\n<li>RAM and disk sizing: It should generally go without saying, but if you\u2019re sending more data to a cluster (as in aggregating it from other clusters), it will need more RAM and disk space to contain that data. \u00a0If you\u2019re simply replicating the same dataset around, there shouldn\u2019t be any increased requirements here.<\/li>\n<li>Disk IO: Even though you may not need more space for the same dataset (that is you do not need the working set of the source in memory), you will likely be incurring more writes from the source cluster(s) via XDCR. You will need enough disk IO to persist these to disk and also enough IO bandwidth to <a href=\"https:\/\/www.couchbase.com\/docs\/couchbase-manual-2.0\/couchbase-admin-tasks-compaction.html\">compact<\/a> this data along with the local application writes. ???<\/li>\n<li>In general, it is important to size both the source and destination clusters and test how it performs for your workload. However, it is known that the XDCR performance at the source cluster will benefit greatly by having more nodes as the data needing to be sent is done so in parallel.<\/li>\n<\/ul>\n<p>3. Network<\/p>\n<p>While the inter-cluster network requirements for Couchbase Server may not typically require much consideration, transferring data over a WAN link will likely require a bit more thought. \u00a0Couchbase Server will automatically checkpoint and restart XDCR as the network allows, but the replication is ultimately only effective if the data can get to the other side.<\/p>\n<p>4. Bi-directional replication and other topologies<\/p>\n<p>This discussion focused on single source and destination clusters replicating a single bucket. \u00a0Bi-directional replication turns each cluster into both a source and a destination with the capacity requirements of both.<\/p>\n<p>When combining multiple clusters and\/or multiple buckets, it is important to ensure that each has enough capacity. \u00a0For example, a one-many will create more replication streams on the one source, and a many-one will generate significant overhead (disk space \/ IO \/ CPU) on the destination cluster.<br \/>\n<strong>Views and Queries<\/strong><\/p>\n<p>One of the most sought-after new features of Couchbase Server 2.0 is the addition of views for indexing\/querying your data. \u00a0As with any new capability, it comes with certain requirements and considerations relating to sizing of the cluster.<\/p>\n<p>The view system is currently disk based which means that both disk space and IO requirements will be increased as well as needing more RAM outside of the object-based cache to improve the query throughput and latency via the OS\u2019s built-in IO caching.<\/p>\n<p>The actual impact will depend quite significantly on both your application\u2019s workload as well as the amount and complexity of your design documents and view definitions. \u00a0It\u2019s very important to follow these view writing best practices when designing your views to mitigate and lessen the sizing requirements as much as possible. \u00a0Write heavy workloads will put more pressure on the actual updating of indexes and more read-oriented workloads will put more load on the querying of those indexes.<\/p>\n<p>1. Index Updating<\/p>\n<p>An insert or update of a document will eventually trigger an index update to take place. \u00a0This trigger is either part of our normal background process and\/or from an application request. \u00a0The effective processing of these updates will have the following impacts:<\/p>\n<ul dir=\"ltr\">\n<li>Disk Size: There are extra files created both for each design document, as well as each view within. \u00a0These files are then filled with the keys and values emitted by your view descriptions (which is why it\u2019s important to keep them as small as possible). These are append-only files, so they will grow with each new insert, update or delete and are compacted in a similar fashion to the data files.<\/li>\n<li>Disk IO: Possibly the biggest impact that using views will have on a system is on the disk IO. \u00a0The index updating itself will potentially require a significant amount of IO as each document write may need to be written into multiple index files. \u00a0These updates are handled by separate threads and processes so as not to impact the normal functioning of the database, but having enough IO will be crucial to keeping the indexes up-to-date. Additionally, the normal and automatic compaction of indexes will consume some amount of disk IO and is required to keep the size of the disk files in check.<\/li>\n<li>CPU: Along with the disk IO, view updates will incur an added amount of CPU. \u00a0By default there are 4 indexers per bucket per node. \u00a0\u00a0Systems with many cores will be benefited by increasing this number. \u00a0The general practice should be to have 1 additional core per design document (each view is processed serially within a design document, but multiple design documents can be processed in parallel)<\/li>\n<li>Replica Indexes: Off by default, these can be turned on to greatly aid the query performance after the failure of a node. \u00a0However, they will at least double (depending on how many replicas are configured) the amount of disk space, disk IO and CPU load required by the system. \u00a0Along with the primary indexers, there are 2 replica indexers per bucket per node by default.???<\/li>\n<\/ul>\n<p>The index updating process scales linearly by adding more nodes because each node is only responsible for processing it\u2019s own data.<\/p>\n<p>It is our best practice to configure the disk path for indexes to be on a separate drive \/ drive from the data files. \u00a0Since each set of files is append-only, writes are always sequential on a file. \u00a0However, combining both the data and index files creates much more random IO on the shared disk. \u00a0Additionally, write heavy workloads should seriously consider using SSD\u2019s.<br \/>\n2. View Querying<br \/>\nIn order for an application to receive the best performance when querying views, the following sizing impacts should be taken into consideration:<\/p>\n<ul>\n<li>RAM: Even though the index files are stored on and accessed from disk, the format of these disk files lends itself very well to the OS\u2019s normal disk IO caching. \u00a0Because of this, it is important to leave a certain amount of RAM available to the system outside of the Couchbase quota. \u00a0The actual number will depend greatly on the size of your indexes, but even a relatively small amount can have a large impact on query latency and performance.<\/li>\n<li>Disk IO: While no extra space will be required simply by querying the views, there will be some amount of additional disk IO required. \u00a0This will depend greatly on how frequently the indexes are updated and then queried, as well as how much RAM is available to cache them.<\/li>\n<li>CPU: There will also be increased CPU requirements when querying the views due to the handling of the individual querying and the merging of results from the multiple nodes.???<\/li>\n<\/ul>\n<p>Given the scather\/gather implementation of indexing and querying, every node needs to participate in every query request. Query throughput can be improved by increasing available file system cache or physical hardware.<\/p>\n<p>3. Effect of Views on Rebalancing<\/p>\n<p>When taking advantage of the new Views feature of Couchbase Server 2.0, it will be important to know and prepare for the impact this will have on rebalancing of the cluster.<\/p>\n<p>At some point throughout the rebalancing process, the data that is moving from one node to another needs to be reflected in the index(es) on that node in order to keep queries consistently returning the same results. \u00a0We have designed the system to perform this update throughout the entire rebalancing process rather than try to catch everything up all at the end. \u00a0As each <a href=\"https:\/\/www.couchbase.com\/blog\/rebalancing-couchbase-part-i\/\">data partition is moved <\/a>, the index is updated before transferring ownership from one to the other. \u00a0This behavior is configurable. You can disable index-aware rebalance if your application can handle inconsistent results and significantly speed up rebalance time.<\/p>\n<p>Leaving this setting on leads to the following impacts:<\/p>\n<ul>\n<li>RAM: Because there is extra processing to be done, more RAM will be used for holding the pending writes in the disk write queue of each destination node<\/li>\n<li>Disk Size: There will be a significantly increased amount of disk space used during rebalance to ensure both the safety and consistency of the views. \u00a0This is cleaned up once the data is not needed anymore, but due to the heavy amount of writes, it\u2019s possible that the compaction process is not able to keep up until rebalance has completed.<\/li>\n<li>Disk IO: \u00a0Since there will be a large amount of data being read, written and indexed all at the same time, disk IO will be sharply increased during rebalance.<\/li>\n<\/ul>\n<p>Along with nearly every other part of Couchbase, the rebalancing process is benefited by having more nodes. \u00a0Imagine adding just one node to a cluster. \u00a0At one extreme, going from 1 to 2 nodes is always the worst case scenario. \u00a0This is because half of the dataset needs to be moved. In most cases, a set of replica data is being created during rebalance as well. In this special case, there is only one node available to handle the entire reading and receipt of data. \u00a0In contrast, going from 21 to 22 nodes is significantly less intensive. Only 1\/21 of the data needs to be moved, likely no replicas are being created and the read\/receipt load is shared by all 21 nodes.<br \/>\n<strong>Conclusion<\/strong><\/p>\n<p>For any complex system (especially a database), sizing is never an easy task. The variables are numerous and the considerations and decisions must always be based on the individual requirements of the application and availability of resources. \u00a0We will constantly strive to do our best to provide guidance, but it is very important to test and stage a system with your application workload \/ requirements both before and after deployment.<\/p>\n<p>The <a href=\"https:\/\/www.couchbase.com\/blog\/how-many-nodes-part-3-hardware-considerations\/\">next and 3rd entry <\/a>in this series provides some specific deployment and hardware recommendations\/considerations for a production Couchbase Server cluster.<\/p>\n","protected":false},"excerpt":{"rendered":"<p>In the first part of this series, I gave an overview of the 5 factors that determine the sizing of your Couchbase cluster: RAM, disk (IO and size), CPU, network and data distribution. \u00a0In this second part, I want to [&hellip;]<\/p>\n","protected":false},"author":24,"featured_media":13873,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"inline_featured_image":false,"footnotes":""},"categories":[1816,9415],"tags":[1300,1329,1330,1331,1328,1326],"ppma_author":[8969],"class_list":["post-1630","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-couchbase-server","category-xdcr","tag-cluster","tag-cpu","tag-disk","tag-network","tag-ram","tag-sizing"],"acf":[],"yoast_head":"<!-- This site is optimized with the Yoast SEO Premium plugin v25.8 (Yoast SEO v25.8) - https:\/\/yoast.com\/wordpress\/plugins\/seo\/ -->\n<title>How Many Nodes? Sizing a Couchbase Server 2.0 cluster<\/title>\n<meta name=\"description\" content=\"Explore specific use cases and scenarios to see how various application designs and workloads affect these various factors while sizing a Couchbase cluster.\" \/>\n<meta name=\"robots\" content=\"index, follow, max-snippet:-1, max-image-preview:large, max-video-preview:-1\" \/>\n<link rel=\"canonical\" href=\"https:\/\/www.couchbase.com\/blog\/how-many-nodes-part-2-sizing-couchbase-server-20-cluster\/\" \/>\n<meta property=\"og:locale\" content=\"en_US\" \/>\n<meta property=\"og:type\" content=\"article\" \/>\n<meta property=\"og:title\" content=\"How Many Nodes? Part 2: Sizing a Couchbase Server 2.0 cluster\" \/>\n<meta property=\"og:description\" content=\"Explore specific use cases and scenarios to see how various application designs and workloads affect these various factors while sizing a Couchbase cluster.\" \/>\n<meta property=\"og:url\" content=\"https:\/\/www.couchbase.com\/blog\/how-many-nodes-part-2-sizing-couchbase-server-20-cluster\/\" \/>\n<meta property=\"og:site_name\" content=\"The Couchbase Blog\" \/>\n<meta property=\"article:published_time\" content=\"2014-12-16T19:33:21+00:00\" \/>\n<meta property=\"article:modified_time\" content=\"2025-06-14T06:50:15+00:00\" \/>\n<meta name=\"author\" content=\"Perry Krug\" \/>\n<meta name=\"twitter:card\" content=\"summary_large_image\" \/>\n<meta name=\"twitter:label1\" content=\"Written by\" \/>\n\t<meta name=\"twitter:data1\" content=\"Perry Krug\" \/>\n\t<meta name=\"twitter:label2\" content=\"Est. reading time\" \/>\n\t<meta name=\"twitter:data2\" content=\"11 minutes\" \/>\n<script type=\"application\/ld+json\" class=\"yoast-schema-graph\">{\"@context\":\"https:\/\/schema.org\",\"@graph\":[{\"@type\":\"Article\",\"@id\":\"https:\/\/www.couchbase.com\/blog\/how-many-nodes-part-2-sizing-couchbase-server-20-cluster\/#article\",\"isPartOf\":{\"@id\":\"https:\/\/www.couchbase.com\/blog\/how-many-nodes-part-2-sizing-couchbase-server-20-cluster\/\"},\"author\":{\"name\":\"Perry Krug\",\"@id\":\"https:\/\/www.couchbase.com\/blog\/#\/schema\/person\/d75b855801e89467ae2cfe0caef39a15\"},\"headline\":\"How Many Nodes? Part 2: Sizing a Couchbase Server 2.0 cluster\",\"datePublished\":\"2014-12-16T19:33:21+00:00\",\"dateModified\":\"2025-06-14T06:50:15+00:00\",\"mainEntityOfPage\":{\"@id\":\"https:\/\/www.couchbase.com\/blog\/how-many-nodes-part-2-sizing-couchbase-server-20-cluster\/\"},\"wordCount\":2461,\"commentCount\":0,\"publisher\":{\"@id\":\"https:\/\/www.couchbase.com\/blog\/#organization\"},\"image\":{\"@id\":\"https:\/\/www.couchbase.com\/blog\/how-many-nodes-part-2-sizing-couchbase-server-20-cluster\/#primaryimage\"},\"thumbnailUrl\":\"https:\/\/www.couchbase.com\/blog\/wp-content\/uploads\/sites\/1\/2022\/11\/couchbase-nosql-dbaas.png\",\"keywords\":[\"Cluster\",\"cpu\",\"disk\",\"network\",\"ram\",\"Sizing\"],\"articleSection\":[\"Couchbase Server\",\"Cross Data Center Replication (XDCR)\"],\"inLanguage\":\"en-US\",\"potentialAction\":[{\"@type\":\"CommentAction\",\"name\":\"Comment\",\"target\":[\"https:\/\/www.couchbase.com\/blog\/how-many-nodes-part-2-sizing-couchbase-server-20-cluster\/#respond\"]}]},{\"@type\":\"WebPage\",\"@id\":\"https:\/\/www.couchbase.com\/blog\/how-many-nodes-part-2-sizing-couchbase-server-20-cluster\/\",\"url\":\"https:\/\/www.couchbase.com\/blog\/how-many-nodes-part-2-sizing-couchbase-server-20-cluster\/\",\"name\":\"How Many Nodes? Sizing a Couchbase Server 2.0 cluster\",\"isPartOf\":{\"@id\":\"https:\/\/www.couchbase.com\/blog\/#website\"},\"primaryImageOfPage\":{\"@id\":\"https:\/\/www.couchbase.com\/blog\/how-many-nodes-part-2-sizing-couchbase-server-20-cluster\/#primaryimage\"},\"image\":{\"@id\":\"https:\/\/www.couchbase.com\/blog\/how-many-nodes-part-2-sizing-couchbase-server-20-cluster\/#primaryimage\"},\"thumbnailUrl\":\"https:\/\/www.couchbase.com\/blog\/wp-content\/uploads\/sites\/1\/2022\/11\/couchbase-nosql-dbaas.png\",\"datePublished\":\"2014-12-16T19:33:21+00:00\",\"dateModified\":\"2025-06-14T06:50:15+00:00\",\"description\":\"Explore specific use cases and scenarios to see how various application designs and workloads affect these various factors while sizing a Couchbase cluster.\",\"breadcrumb\":{\"@id\":\"https:\/\/www.couchbase.com\/blog\/how-many-nodes-part-2-sizing-couchbase-server-20-cluster\/#breadcrumb\"},\"inLanguage\":\"en-US\",\"potentialAction\":[{\"@type\":\"ReadAction\",\"target\":[\"https:\/\/www.couchbase.com\/blog\/how-many-nodes-part-2-sizing-couchbase-server-20-cluster\/\"]}]},{\"@type\":\"ImageObject\",\"inLanguage\":\"en-US\",\"@id\":\"https:\/\/www.couchbase.com\/blog\/how-many-nodes-part-2-sizing-couchbase-server-20-cluster\/#primaryimage\",\"url\":\"https:\/\/www.couchbase.com\/blog\/wp-content\/uploads\/sites\/1\/2022\/11\/couchbase-nosql-dbaas.png\",\"contentUrl\":\"https:\/\/www.couchbase.com\/blog\/wp-content\/uploads\/sites\/1\/2022\/11\/couchbase-nosql-dbaas.png\",\"width\":1800,\"height\":630},{\"@type\":\"BreadcrumbList\",\"@id\":\"https:\/\/www.couchbase.com\/blog\/how-many-nodes-part-2-sizing-couchbase-server-20-cluster\/#breadcrumb\",\"itemListElement\":[{\"@type\":\"ListItem\",\"position\":1,\"name\":\"Home\",\"item\":\"https:\/\/www.couchbase.com\/blog\/\"},{\"@type\":\"ListItem\",\"position\":2,\"name\":\"How Many Nodes? Part 2: Sizing a Couchbase Server 2.0 cluster\"}]},{\"@type\":\"WebSite\",\"@id\":\"https:\/\/www.couchbase.com\/blog\/#website\",\"url\":\"https:\/\/www.couchbase.com\/blog\/\",\"name\":\"The Couchbase Blog\",\"description\":\"Couchbase, the NoSQL Database\",\"publisher\":{\"@id\":\"https:\/\/www.couchbase.com\/blog\/#organization\"},\"potentialAction\":[{\"@type\":\"SearchAction\",\"target\":{\"@type\":\"EntryPoint\",\"urlTemplate\":\"https:\/\/www.couchbase.com\/blog\/?s={search_term_string}\"},\"query-input\":{\"@type\":\"PropertyValueSpecification\",\"valueRequired\":true,\"valueName\":\"search_term_string\"}}],\"inLanguage\":\"en-US\"},{\"@type\":\"Organization\",\"@id\":\"https:\/\/www.couchbase.com\/blog\/#organization\",\"name\":\"The Couchbase Blog\",\"url\":\"https:\/\/www.couchbase.com\/blog\/\",\"logo\":{\"@type\":\"ImageObject\",\"inLanguage\":\"en-US\",\"@id\":\"https:\/\/www.couchbase.com\/blog\/#\/schema\/logo\/image\/\",\"url\":\"https:\/\/www.couchbase.com\/blog\/wp-content\/uploads\/2023\/04\/admin-logo.png\",\"contentUrl\":\"https:\/\/www.couchbase.com\/blog\/wp-content\/uploads\/2023\/04\/admin-logo.png\",\"width\":218,\"height\":34,\"caption\":\"The Couchbase Blog\"},\"image\":{\"@id\":\"https:\/\/www.couchbase.com\/blog\/#\/schema\/logo\/image\/\"}},{\"@type\":\"Person\",\"@id\":\"https:\/\/www.couchbase.com\/blog\/#\/schema\/person\/d75b855801e89467ae2cfe0caef39a15\",\"name\":\"Perry Krug\",\"image\":{\"@type\":\"ImageObject\",\"inLanguage\":\"en-US\",\"@id\":\"https:\/\/www.couchbase.com\/blog\/#\/schema\/person\/image\/07fdef12afbaed73ed2879a6d989ae12\",\"url\":\"https:\/\/secure.gravatar.com\/avatar\/d526d9acbd39623c0a9c0443617ab51bc75b0d8118706229ff946cea1a223257?s=96&d=mm&r=g\",\"contentUrl\":\"https:\/\/secure.gravatar.com\/avatar\/d526d9acbd39623c0a9c0443617ab51bc75b0d8118706229ff946cea1a223257?s=96&d=mm&r=g\",\"caption\":\"Perry Krug\"},\"description\":\"Perry Krug is the Head of Developer Experience at Couchbase. He has been with Couchbase for over 13 years and has been working with high-performance caching and database systems for over 17.\",\"url\":\"https:\/\/www.couchbase.com\/blog\/author\/perry-krug\/\"}]}<\/script>\n<!-- \/ Yoast SEO Premium plugin. -->","yoast_head_json":{"title":"How Many Nodes? Sizing a Couchbase Server 2.0 cluster","description":"Explore specific use cases and scenarios to see how various application designs and workloads affect these various factors while sizing a Couchbase cluster.","robots":{"index":"index","follow":"follow","max-snippet":"max-snippet:-1","max-image-preview":"max-image-preview:large","max-video-preview":"max-video-preview:-1"},"canonical":"https:\/\/www.couchbase.com\/blog\/how-many-nodes-part-2-sizing-couchbase-server-20-cluster\/","og_locale":"en_US","og_type":"article","og_title":"How Many Nodes? Part 2: Sizing a Couchbase Server 2.0 cluster","og_description":"Explore specific use cases and scenarios to see how various application designs and workloads affect these various factors while sizing a Couchbase cluster.","og_url":"https:\/\/www.couchbase.com\/blog\/how-many-nodes-part-2-sizing-couchbase-server-20-cluster\/","og_site_name":"The Couchbase Blog","article_published_time":"2014-12-16T19:33:21+00:00","article_modified_time":"2025-06-14T06:50:15+00:00","author":"Perry Krug","twitter_card":"summary_large_image","twitter_misc":{"Written by":"Perry Krug","Est. reading time":"11 minutes"},"schema":{"@context":"https:\/\/schema.org","@graph":[{"@type":"Article","@id":"https:\/\/www.couchbase.com\/blog\/how-many-nodes-part-2-sizing-couchbase-server-20-cluster\/#article","isPartOf":{"@id":"https:\/\/www.couchbase.com\/blog\/how-many-nodes-part-2-sizing-couchbase-server-20-cluster\/"},"author":{"name":"Perry Krug","@id":"https:\/\/www.couchbase.com\/blog\/#\/schema\/person\/d75b855801e89467ae2cfe0caef39a15"},"headline":"How Many Nodes? Part 2: Sizing a Couchbase Server 2.0 cluster","datePublished":"2014-12-16T19:33:21+00:00","dateModified":"2025-06-14T06:50:15+00:00","mainEntityOfPage":{"@id":"https:\/\/www.couchbase.com\/blog\/how-many-nodes-part-2-sizing-couchbase-server-20-cluster\/"},"wordCount":2461,"commentCount":0,"publisher":{"@id":"https:\/\/www.couchbase.com\/blog\/#organization"},"image":{"@id":"https:\/\/www.couchbase.com\/blog\/how-many-nodes-part-2-sizing-couchbase-server-20-cluster\/#primaryimage"},"thumbnailUrl":"https:\/\/www.couchbase.com\/blog\/wp-content\/uploads\/sites\/1\/2022\/11\/couchbase-nosql-dbaas.png","keywords":["Cluster","cpu","disk","network","ram","Sizing"],"articleSection":["Couchbase Server","Cross Data Center Replication (XDCR)"],"inLanguage":"en-US","potentialAction":[{"@type":"CommentAction","name":"Comment","target":["https:\/\/www.couchbase.com\/blog\/how-many-nodes-part-2-sizing-couchbase-server-20-cluster\/#respond"]}]},{"@type":"WebPage","@id":"https:\/\/www.couchbase.com\/blog\/how-many-nodes-part-2-sizing-couchbase-server-20-cluster\/","url":"https:\/\/www.couchbase.com\/blog\/how-many-nodes-part-2-sizing-couchbase-server-20-cluster\/","name":"How Many Nodes? Sizing a Couchbase Server 2.0 cluster","isPartOf":{"@id":"https:\/\/www.couchbase.com\/blog\/#website"},"primaryImageOfPage":{"@id":"https:\/\/www.couchbase.com\/blog\/how-many-nodes-part-2-sizing-couchbase-server-20-cluster\/#primaryimage"},"image":{"@id":"https:\/\/www.couchbase.com\/blog\/how-many-nodes-part-2-sizing-couchbase-server-20-cluster\/#primaryimage"},"thumbnailUrl":"https:\/\/www.couchbase.com\/blog\/wp-content\/uploads\/sites\/1\/2022\/11\/couchbase-nosql-dbaas.png","datePublished":"2014-12-16T19:33:21+00:00","dateModified":"2025-06-14T06:50:15+00:00","description":"Explore specific use cases and scenarios to see how various application designs and workloads affect these various factors while sizing a Couchbase cluster.","breadcrumb":{"@id":"https:\/\/www.couchbase.com\/blog\/how-many-nodes-part-2-sizing-couchbase-server-20-cluster\/#breadcrumb"},"inLanguage":"en-US","potentialAction":[{"@type":"ReadAction","target":["https:\/\/www.couchbase.com\/blog\/how-many-nodes-part-2-sizing-couchbase-server-20-cluster\/"]}]},{"@type":"ImageObject","inLanguage":"en-US","@id":"https:\/\/www.couchbase.com\/blog\/how-many-nodes-part-2-sizing-couchbase-server-20-cluster\/#primaryimage","url":"https:\/\/www.couchbase.com\/blog\/wp-content\/uploads\/sites\/1\/2022\/11\/couchbase-nosql-dbaas.png","contentUrl":"https:\/\/www.couchbase.com\/blog\/wp-content\/uploads\/sites\/1\/2022\/11\/couchbase-nosql-dbaas.png","width":1800,"height":630},{"@type":"BreadcrumbList","@id":"https:\/\/www.couchbase.com\/blog\/how-many-nodes-part-2-sizing-couchbase-server-20-cluster\/#breadcrumb","itemListElement":[{"@type":"ListItem","position":1,"name":"Home","item":"https:\/\/www.couchbase.com\/blog\/"},{"@type":"ListItem","position":2,"name":"How Many Nodes? Part 2: Sizing a Couchbase Server 2.0 cluster"}]},{"@type":"WebSite","@id":"https:\/\/www.couchbase.com\/blog\/#website","url":"https:\/\/www.couchbase.com\/blog\/","name":"The Couchbase Blog","description":"Couchbase, the NoSQL Database","publisher":{"@id":"https:\/\/www.couchbase.com\/blog\/#organization"},"potentialAction":[{"@type":"SearchAction","target":{"@type":"EntryPoint","urlTemplate":"https:\/\/www.couchbase.com\/blog\/?s={search_term_string}"},"query-input":{"@type":"PropertyValueSpecification","valueRequired":true,"valueName":"search_term_string"}}],"inLanguage":"en-US"},{"@type":"Organization","@id":"https:\/\/www.couchbase.com\/blog\/#organization","name":"The Couchbase Blog","url":"https:\/\/www.couchbase.com\/blog\/","logo":{"@type":"ImageObject","inLanguage":"en-US","@id":"https:\/\/www.couchbase.com\/blog\/#\/schema\/logo\/image\/","url":"https:\/\/www.couchbase.com\/blog\/wp-content\/uploads\/2023\/04\/admin-logo.png","contentUrl":"https:\/\/www.couchbase.com\/blog\/wp-content\/uploads\/2023\/04\/admin-logo.png","width":218,"height":34,"caption":"The Couchbase Blog"},"image":{"@id":"https:\/\/www.couchbase.com\/blog\/#\/schema\/logo\/image\/"}},{"@type":"Person","@id":"https:\/\/www.couchbase.com\/blog\/#\/schema\/person\/d75b855801e89467ae2cfe0caef39a15","name":"Perry Krug","image":{"@type":"ImageObject","inLanguage":"en-US","@id":"https:\/\/www.couchbase.com\/blog\/#\/schema\/person\/image\/07fdef12afbaed73ed2879a6d989ae12","url":"https:\/\/secure.gravatar.com\/avatar\/d526d9acbd39623c0a9c0443617ab51bc75b0d8118706229ff946cea1a223257?s=96&d=mm&r=g","contentUrl":"https:\/\/secure.gravatar.com\/avatar\/d526d9acbd39623c0a9c0443617ab51bc75b0d8118706229ff946cea1a223257?s=96&d=mm&r=g","caption":"Perry Krug"},"description":"Perry Krug is the Head of Developer Experience at Couchbase. He has been with Couchbase for over 13 years and has been working with high-performance caching and database systems for over 17.","url":"https:\/\/www.couchbase.com\/blog\/author\/perry-krug\/"}]}},"authors":[{"term_id":8969,"user_id":24,"is_guest":0,"slug":"perry-krug","display_name":"Perry Krug","avatar_url":"https:\/\/secure.gravatar.com\/avatar\/d526d9acbd39623c0a9c0443617ab51bc75b0d8118706229ff946cea1a223257?s=96&d=mm&r=g","author_category":"","last_name":"Krug","first_name":"Perry","job_title":"","user_url":"","description":"Perry Krug is an Architect in the Office of the CTO focused on customer solutions. He has been with Couchbase for over 8 years and has been working with high-performance caching and database systems for over 12 years."}],"_links":{"self":[{"href":"https:\/\/www.couchbase.com\/blog\/wp-json\/wp\/v2\/posts\/1630","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.couchbase.com\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.couchbase.com\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.couchbase.com\/blog\/wp-json\/wp\/v2\/users\/24"}],"replies":[{"embeddable":true,"href":"https:\/\/www.couchbase.com\/blog\/wp-json\/wp\/v2\/comments?post=1630"}],"version-history":[{"count":0,"href":"https:\/\/www.couchbase.com\/blog\/wp-json\/wp\/v2\/posts\/1630\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/www.couchbase.com\/blog\/wp-json\/wp\/v2\/media\/13873"}],"wp:attachment":[{"href":"https:\/\/www.couchbase.com\/blog\/wp-json\/wp\/v2\/media?parent=1630"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.couchbase.com\/blog\/wp-json\/wp\/v2\/categories?post=1630"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.couchbase.com\/blog\/wp-json\/wp\/v2\/tags?post=1630"},{"taxonomy":"author","embeddable":true,"href":"https:\/\/www.couchbase.com\/blog\/wp-json\/wp\/v2\/ppma_author?post=1630"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}