IBM Cloud Databases are open source data stores for enterprise application development. Built on a Kubernetes foundation, they offer a database platform for serverless applications. They are designed to scale storage and compute resources seamlessly without being constrained by the limits of a single server. Natively integrated and available in the IBM Cloud console, these databases are now available through a consistent consumption, pricing, and interaction model. They aim to provide a cohesive…
N/A
Oracle NoSQL Database
Score 10.0 out of 10
N/A
Oracle offers a NoSQL Database.
N/A
Redis Software
Score 9.1 out of 10
N/A
Redis is an open source in-memory data structure server and NoSQL database.
We previously hosted our own Redis and RabbitMQ cluster. Before switching to IBM Compose we evaluated Redis Lab, Scalegrid, AWS ElastiCache, CloudAMQP and others. We still host our core database (MongoDB) ourselves.
Aiven backup options are very limited (you can't download backups and you don't have an API) and their dashboard is incomplete and without an optimal design; but they accept way more data centers, and they have more pricing options.
We currently use both Heroku and Compose. Heroku is our PAAS choice for our application servers. As mentioned, previously, the cost of some compose services for development / staging / testing servers was getting costly. For these type of servers we don't need the high …
We use Amazon's RDS (MySQL database), Redislabs (Redis) and also MongoDB's Atlas. They all have their own advantages and disadvantages. For us, MongoDB's Atlas and Compose are obviously similar services. For now, we use Atlas to try new things (since they run the latest stable …
We use other providers for Redis, but we may switch to Compose to keep things under the same roof. Redis is so simple, though, and Compose is a bit pricier than alternatives. For MongoDB, however, we have not considered switching to another provider because we are totally …
Less Appropriate Scenario: 1) Small Scale or Low Budget Projects 2) Organizations with limited expertise in cloud technologies may find the learning curve steep, especially if they are not familiar with the IBM Cloud platform 3) If database requirements are highly dynamic and change frequently, the comprehensive features and management provided by IBM Cloud Databases might be overkill. A more flexible, self-managed solution could be preferable for adapting to rapid changes.
Oracle NoSQL Database is well-suited for you if your data formats are not consistent, if you have limited hardware resources, if you higher data throughput (whether the database is on the cloud or running locally), and if you don't need a declarative query language to maintain a standardized schema of your data. If you need reduced data redundancy and require ACID compliance, you are better off finding an SQL database solution.
Redis has been a great investment for our organization as we needed a solution for high speed data caching. The ramp up and integration was quite easy. Redis handles automatic failover internally, so no crashes provides high availability. On the fly scaling scale to more/less cores and memory as and when needed.
The ease of setup was effortless. For anyone with development experience, a few simple questions such as name and login data will get you set up.
The web application to manage cluster settings, billing settings and even introspect the data was simple and most importantly worked all the time. This can not always be said for web interfaces of other products.
Data-model flexibility. Unlike RDBMS solutions, Oracle NoSQL does not restrict you to a predefined set of data types.
Ability to Handle an Increased Amount of Traffic. As Oracle NoSQL can process queries much quicker than Oracle Database, Oracle NoSQL is able to respond to a lot more queries in the same amount of time.
Data-model simplicity. In SQL-oriented databases, there is a learning curve in learning the relationship between databases, tables, rows, and keys. On the other hand, Oracle NoSQL's key-value based storage is much easier to get the hang of.
Easy for developers to understand. Unlike Riak, which I've used in the past, it's fast without having to worry about eventual consistency.
Reliable. With a proper multi-node configuration, it can handle failover instantly.
Configurable. We primarily still use Memcache for caching but one of the teams uses Redis for both long-term storage and temporary expiry keys without taking on another external dependency.
Fast. We process tens of thousands of RPS and it doesn't skip a beat.
Better cost reports, before just increasing to another tier, thus increasing the price. This is critical for early stage startups, where budget is tight.
Add more data center options. As a comparison, a similar service, Aiven.io has dozen more options than Compose (basically all big cloud providers). We moved from AWS to Digital Ocean, which made us stop using Compose, since Compose forces us to be either on IBM or AWS.
Fewer analytical functions to choose from. When compared to Oracle Database, there is significant difference in the amount of built-in analytical functions.
Eventual data consistency. It is not guaranteed that a write or delete query will be immediately visible for subsequent queries.
Data redundancy. As there are no mechanisms that insure data integrity, users are more likely to have redundant data across their documents.
We had some difficulty scaling Redis without it becoming prohibitively expensive.
Redis has very simple search capabilities, which means its not suitable for all use cases.
Redis doesn't have good native support for storing data in object form and many libraries built over it return data as a string, meaning you need build your own serialization layer over it.
IBM is our trusted partner which never failed to meet our expectations. Stability, efficiency, usability and security is a must have for our business which is fully provided by IBM Cloud Databases
We will definitely continue using Redis because: 1. It is free and open source. 2. We already use it in so many applications, it will be hard for us to let go. 3. There isn't another competitive product that we know of that gives a better performance. 4. We never had any major issues with Redis, so no point turning our backs.
IBM Cloud Databases' pricing structure is easy to understand, and if you choose the right product, you can operate your system at minimal cost. Although there is ample documentation available, there doesn't seem to be a user community running on it, so specific usage know-how and troubleshooting can sometimes take longer than expected.
It is quite simple to set up for the purpose of managing user sessions in the backend. It can be easily integrated with other products or technologies, such as Spring in Java. If you need to actually display the data stored in Redis in your application this is a bit difficult to understand initially but is possible.
Support is helpful enough, but we haven't always had questions answered in a satisfactory manner. At one time we realized that Compose had stopped taking database snapshots on its two-per-day schedule, and had in fact not taken one for many days. Support recognized the problem and it was fixed, but the lack of proactive checks and the inability to share exactly what happened has caused us to look elsewhere for production work loads
The support team has always been excellent in handling our mostly questions, rarely problems. They are responsive, find the solution and get us moving forward again. I have never had to escalate a case with them. They have always solved our problems in a very timely manner. I highly commend the support team.
The reason why I choose IBM Cloud Databases is that the IBM cloud toolset is already being used in other functions of the company and by using IBM Cloud Databases, the other cloud tools are better embedded and integrated. If the company is set to use amazon tools, I would go for rds.
We are big users of MySQL and PostgreSQL. We were looking at replacing our aging web page caching technology and found that we could do it in SQL, but there was a NoSQL movement happening at the time. We dabbled a bit in the NoSQL scene just to get an idea of what it was about and whether it was for us. We tried a bunch, but I can only seem to remember Mongo and Couch. Mongo had big issues early on that drove us to Redis and we couldn't quite figure out how to deploy couch.
We pay less for computing resources, as Oracle NoSQL databases respond quicker than our previous SQL databases.
Our database administrators and software developers do not need to worry about "data massaging" and can focus on perfecting application logic.
Oracle NoSQL has built-in integration to other Oracle products, so we didn't not need to spend money on building custom integrators or higher additional developers.
Redis has helped us increase our throughput and server data to a growing amount of traffic while keeping our app fast. We couldn't have grown without the ability to easily cache data that Redis provides.
Redis has helped us decrease the load on our database. By being able to scale up and cache important data, we reduce the load on our database reducing costs and infra issues.
Running a Redis node on something like AWS can be costly, but it is often a requirement for scaling a company. If you need data quickly and your business is already a positive ROI, Redis is worth the investment.
