HBase vs Azure Cosmos DB

• Scalability. HBase can scale to trillions of records.
• Fast. HBase is extremely fast to scan values or retrieve individual records by key.
• HBase can be accessed by standard SQL via Apache Phoenix.
• Integrated. I can easily store and retrieve data from HBase using Apache Spark.
• It is easy to set up DR and backups.
• Ingest. It is easy to ingest data into HBase via shell, Java, Apache NiFi, Storm, Spark, Flink, Python and other means.

Read full review

• Injects unstructured data at a very high speed.
• No real need for administrative work, it indexes everything on it's own.

Read full review

• There are very few commands in HBase.
• Stored procedures functionality is not available so it should be implemented.
• HBase is CPU and Memory intensive with large sequential input or output access while as Map Reduce jobs are primarily input or output bound with fixed memory. HBase integrated with Map-reduce jobs will result in random latencies.

Read full review

• Cosmos DB can be very expensive if you're using it for scenarios that are better completed in regular old Azure Table Storage or Blob Storage, specifically if you put some thought into your partitioning schemes. No product is a good substitute for thoughtful system design.
• It would be helpful if I had some more insight into how many resources (DTUs) an individual query uses.
• The auto-indexing is great, but a little mysterious -- not usually an issue but it does require some intentional thought.

Read full review

• As Hbase is a noSql database, here we don't have transaction support and we cannot do many operations on the data.
• Not having the feature of primary or a composite primary key is an issue as the architecture to be defined cannot be the same legacy type. Also the transaction concept is not applicable here.
• The way data is printed on console is not so user-friendly. So we had to use some abstraction over HBase (eg apache phoenix) which means there is one new component to handle.

Read full review

• Azure Cosmos DB may be expensive on its own, but it was cheaper than increasing the size/power of our VMs running SQL Server instances enough to keep up with the volume and velocity of the unstructured data.
• We got the JSON data out of our SQL Servers and they quit tipping over.

Read full review