# Which wide column solutions offer the best scalability and storage efficiency?

<p class="elv-tracking-normal elv-text-default elv-font-figtree elv-text-base elv-leading-base elv-font-normal" elv="true">Hi G2 community! So, scalability is the whole reason to reach for a wide column database, but storage efficiency (how much hardware you burn to get there) varies a lot. I've been looking at the <a class="a a--md" elv="true" href="https://www.g2.com/categories/wide-column-database">Wide Column Database category</a> for what reviewers say about scaling behavior and how efficiently each uses the underlying resources.</p><ul>
<li>
<a class="a a--md" elv="true" href="https://www.g2.com/products/scylladb/reviews"><strong>ScyllaDB</strong></a><strong>:</strong> Reviewers repeatedly credit its shard-per-core architecture with efficient hardware use, scaling predictably as cores are added and needing fewer nodes for the same load. Getting there depends on solid capacity planning.</li>
<li>
<a class="a a--md" elv="true" href="https://www.g2.com/products/hbase/reviews"><strong>HBase</strong></a><strong>:</strong> Reviewers highlight linear and modular scaling on commodity hardware for billions of rows, with memory compression called out as a storage-efficiency plus. It expects the Hadoop/HDFS stack underneath.</li>
<li>
<a class="a a--md" elv="true" href="https://www.g2.com/products/cassandra/reviews"><strong>Cassandra</strong></a><strong>:</strong> Horizontal scaling with no single point of failure is its hallmark, and reviewers scale it across large clusters. The efficiency caveat they raise is high per-node RAM needs, so scaling isn't cheap in terms of resources.</li>
<li>
<a class="a a--md" elv="true" href="https://www.g2.com/products/amazon-keyspaces/reviews"><strong>Amazon Keyspaces</strong></a><strong>:</strong> Serverless auto-scaling with virtually unlimited throughput and storage means you don't manage capacity yourself, which reviewers like for elastic scaling, at a cost premium.</li>
</ul><p class="elv-tracking-normal elv-text-default elv-font-figtree elv-text-base elv-leading-base elv-font-normal" elv="true">When you scaled one of these, what actually constrained you first: node count and RAM, storage growth, or the operational effort of expanding the cluster? And which stayed efficient as it grew?</p>

##### Post Metadata
- Posted at: 2 months ago
- Author title: Marketing
- Net upvotes: 1


## Comments
### Comment 1

On the first part of your question, operational effort tends to bind before hardware does. Adding nodes is the easy bit, keeping the cluster balanced and having the team confident doing it at 2am is the harder one. The ScyllaDB point is interesting for exactly that reason, since fewer nodes for the same load means fewer things to expand and rebalance.

##### Comment Metadata
- Posted at: 8 days ago
- Author title: SEO Content Specialist



### Comment 2

&lt;p&gt;&lt;span style=&quot;color: rgb(0, 0, 0);&quot;&gt;The constraint that surprises people first is usually compaction rather than raw storage. These are log-structured stores, so background compaction needs both spare disk headroom to write the merged output and enough IO budget to keep up with ingest, which means a node can be in trouble at seventy percent full rather than ninety-five. ScyllaDB&#39;s shard-per-core design getting credit for efficient hardware use is partly about keeping that background work predictable. Worth planning capacity against compaction headroom and watching pending compaction depth as the early warning signal.&lt;/span&gt;&lt;/p&gt;

##### Comment Metadata
- Posted at: 17 days ago
- Author title: Tech Consultant



### Comment 3

&lt;p&gt;With Cassandra, the first thing that bit us wasn&#39;t node count, it was RAM. We underestimated how hungry it gets per node and ended up over-provisioning just to stay stable. ScyllaDB&#39;s story on hardware efficiency is genuinely interesting but I haven&#39;t personally run it at the scale where that difference would be obvious. Would be curious to hear from anyone who&#39;s done a direct comparison on the same hardware.&lt;/p&gt;

##### Comment Metadata
- Posted at: 2 months ago
- Author title: SEO Content Specialist





## Related discussions
- [How well does Trello scale into a larger team?](https://www.g2.com/discussions/1-how-well-does-trello-scale-into-a-larger-team)
  - Posted at: over 13 years ago
  - Comments: 6
- [Can we please add a new section](https://www.g2.com/discussions/2-can-we-please-add-a-new-section)
  - Posted at: over 13 years ago
  - Comments: 0
- [Quantifiable benefits from implementing your CRM](https://www.g2.com/discussions/quantifiable-benefits-from-implementing-your-crm)
  - Posted at: over 13 years ago
  - Comments: 4