# How flexible is CrateDB when it comes to vertical scaling? **URL:** \ **Category:** CrateDB\ **Created:** [September 13, 2021, 7:51am UTC](https://community.cratedb.com/t/how-flexible-is-cratedb-when-it-comes-to-vertical-scaling/800 "2021-09-13T07:51:07Z")\ **Posts on this page:** 2\ **Page:** 1
**Author:** ![Emre\_Sevinc](https://sea2.discourse-cdn.com/flex020/user_avatar/community.cratedb.com/emre_sevinc/32/375_2.png) [@Emre\_Sevinc](https://community.cratedb.com/u/Emre_Sevinc)\ **Post date:** [September 13, 2021, 7:51am UTC](https://community.cratedb.com/t/how-flexible-is-cratedb-when-it-comes-to-vertical-scaling/800/1 "2021-09-13T07:51:07Z")
How flexible is CrateDB when it comes to **vertical scaling**? E.g. what if I **increase** the number of **CPU cores** and **RAM** per **node** , _after having created a table and ingested data to it_? Can I simply alter the table settings to have **more shards** after I have increased the number of CPU cores? Can CrateDB dynamically handle this? Also: are there some **practical** limitations for the amount of **RAM** and number of **CPU cores** _per node_? E.g. would you say “beyond that amount of RAM / CPU cores, be careful for such and such overhead!”, etc.? ---
**Author:** ![proddata](https://sea2.discourse-cdn.com/flex020/user_avatar/community.cratedb.com/proddata/32/1379_2.png) [@proddata](https://community.cratedb.com/u/proddata)\ **Post date:** [September 13, 2021, 2:26pm UTC](https://community.cratedb.com/t/how-flexible-is-cratedb-when-it-comes-to-vertical-scaling/800/2 "2021-09-13T14:26:47Z")
> How flexible is CrateDB when it comes to **vertical scaling**? E.g. what if I **increase** the number of **CPU cores** and **RAM** per **node** , _after having created a table and ingested data to it_ ? This can just be done and typically wouldn’t need immediate action (e.g. double memory / cpu cores). > Can I simply alter the table settings to have **more shards** after I have increased the number of CPU cores? Increasing shards can be done on any table. However twice as many CPU cores typically doesn’t mean, that you need twice as many shards immediately. > **[Crate.io](http://Crate.io) Docs** > The number of shards [can be changed](https://crate.io/docs/crate/reference/en/4.6/general/ddl/alter-table.html#alter-shard-number) after table creation, providing the value is a multiple of [number\_of\_routing\_shards](https://crate.io/docs/crate/reference/en/4.6/sql/statements/create-table.html#sql-create-table-number-of-routing-shards) (set at table-creation time). Altering the number of shards will put the table into a read-only state until the operation has completed. However typically with growing use cases you would typically use partitioned tables. For partitioned tables you can also change the number of shards for **all** partitions, or just for **single** partitions and/or for all **future** partitions. > Also: are there some **practical** limitations for the amount of **RAM** and number of **CPU cores** _per node_ ? As a Java application CrateDB is using compressed oops which soft limits the amount of heap to be used to ~30.5GB. With the current recommendation of 25% of total system memory as heap, this would be 128GB per crate process / vm / container. (also see [Memory configuration — CrateDB: How-Tos](https://crate.io/docs/crate/howtos/en/latest/performance/memory.html)). That being said, you can run bigger single nodes, however through to CrateDBs distributed nature, often more nodes are faster overall as bigger ones. ![image](https://us1.discourse-cdn.com/flex020/uploads/crate/original/1X/8df7b54a0048563a1964efd207175bb92f659811.png) Typical configurations include nodes with 16 vCPUs and 64 GiB Memory (e.g. AWS m5.4xlarge / Azure D16s). Depending on use cases up to 300 - 400 nodes. But we also support production use cases with 3 nodes of 4 vCPUs and 16GiB of Memory.