NoSQL Databases Resources - Page 2

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 Wide Column Database category for what reviewers say about scaling behavior and how efficiently each uses the underlying resources.

• ScyllaDB: 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.
• HBase: 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.
• Cassandra: 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.
• Amazon Keyspaces: 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.

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?

IoT platforms push a lot of high-velocity data and expect real-time access, which is a natural fit for wide column databases. I've been researching the Wide Column Database category for which ones reviewers actually run for high-ingest, real-time workloads at scale, framing "reliably" around what the reviews support rather than as an absolute guarantee.

• ScyllaDB: Reviewers cite event ingestion, real-time use cases, and time-series or key-value access at high throughput with predictable latency, which maps closely to IoT telemetry. Careful data modeling is the prerequisite for that reliability.
• HBase: Used for near-real-time read/write on billions of rows and feeding ML models (reviewers cite fraud detection on streaming data), which fits IoT analytics at volume. It leans on Hadoop and is stronger for OLTP-style access than heavy aggregation.
• Cassandra: Its high availability, no single point of failure, and fast writes make it a durable choice for always-on IoT ingestion. Reviewers note read performance and data modeling as the areas to plan around.
• Microsoft Azure Cosmos DB: Global distribution, instant scaling, and low latency suit geographically spread IoT fleets on Azure, with RU/s cost planning as the main caveat for constant high ingest.

For IoT specifically, did you separate hot ingestion from analytics, or lean on one database for both? And which of these actually held up as device counts and event rates climbed?

I've been comparing Cassandra and ScyllaDB specifically for high-throughput write workloads and, just as importantly, which one data engineering teams find less painful to run in production. Both sit in the Wide Column Database category and share the same data model and query language (ScyllaDB is Cassandra-compatible), so this is a genuine apples-to-apples comparison; the difference is in the engine and the operational experience.

• ScyllaDB: Reviewers consistently credit its C++ shard-per-core design with high write throughput and predictable low latency on fewer nodes, plus auto-tuning that cuts DBA overhead. The catch is a steep initial learning curve around data modeling and cluster tuning.
• Cassandra: Reviewers praise its write throughput and battle-tested maturity, with a large community and broad compatibility that ease hiring and troubleshooting. The operational costs they raise are JVM-related tuning, high node/RAM requirements, and specialized DevOps knowledge (compaction, tombstones).

The pattern in the reviews: ScyllaDB tends to win on raw performance-per-node and lower steady-state ops, while Cassandra wins on maturity, community, and ecosystem, at higher operational overhead. One reviewer put it directly: Scylla edges performance, but Cassandra is more established with better compatibility. For teams who've run both in production for high writes, which was genuinely easier to operate day to day, and did Scylla's performance edge justify the migration effort?