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
MySQL
Score 8.3 out of 10
N/A
MySQL is a popular open-source relational and embedded database, now owned by Oracle.
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.
Well for MySQL we had to use Amazon because of the pricing structure. We are using Mongo on Compose and it has been pretty good to us for the past 2 years. We are moving all of our databases to Amazon for the customer support and pricing structure that is competitive to Compose,
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 use Amazon Aurora as our primary datastore and use IBM Compose Mongo as an alternative only when Aurora does not cover the use case well. Amazon DynamoDB looks good but doesn't have the same wealth of libraries and support which makes MongoDB easy to use and therefore was …
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 …
While using IBM Bluemix to host our SaaS product in the Asia/Pacific region, PostgreSQL suited us for integrating well with IBM Cloud, and also being available within the same geographic region.
Other products that we looked at: ElephantSQL provides At-Rest encryption, but this …
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 …
Is not a drop-in replacement for any of the things listed above. MySQL has it's purpose and use-cases, same as those. It's a low-cost solution for high read/low write applications and works very well when used in the right circumstances. Support can be purchased from various …
SQLite - Is the goto DB for Mobile/Desktop Apps. Its not as elaborate as Mysql but since its a RDBMS it provides all the basic features and its lite. We use mysql at the backend and for desktop app we use SQLite
postgres - Its a formidable opponent. It is fast and reliable and …
MySQL holds its own in terms of SQL engine speed and storage capability, but database administration is where MySQL really shines. Other products that I've used offer little in terms of tuning or portability. Managing a MySQL database is relatively painless out of the box and …
If you are looking for a relational database (depending on your app), MySQL is a good place to start. MongoDB and Cassandra are NoSQL options (very powerful). I am more inclined towards PostgreSQL as it's more scalable over time. MySQL was bought by Oracle and the community …
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 …
UI isn't that great compared to the other competitors. The management of our memcached cluster was becoming pretty complicated as the application grew in size. Redis is a much better option compared to memcached. Redis is bit unreliable compared to the alternative RabbitMQ …
Every time you don't need a document DB, you can't go wrong with Redis over MongoDB. Google Cloud Pub/Sub may have solved one use case, but we'd still have to deploy Redis instances for other use cases, and adding another tech stack would only add complexity to our …
As we perform a lot of deployments to AWS, we have the option of easily using a cache layer with either Memcache or Redis. We almost always choose Redis as it can solve more problems in production than Memcache in our experience. There is some overlap between what Redis can do …
We chose Redis over Memcached and Couchbase for its performance, cost, support, and ease of use. Couchbase probably would have worked as well, but it seemed a bit overkill for our use cases.
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.
MySQL is best suited for applications on platform like high-traffic content-driven websites, small-scale web apps, data warehouses which regards light analytical workloads. However its less suited for areas like enterprise data warehouse, OLAP cubes, large-scale reporting, applications requiring flexible or semi-structured data like event logging systems, product configurations, dynamic forms.
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.
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.
Learning curve: is big. Newbies will face problems in understanding the platform initially. However, with plenty of online resources, one can easily find solutions to problems and learn on the go.
Backup and restore: MySQL is not very seamless. Although the data is never ruptured or missed, the process involved is not very much user-friendly. Maybe, a new command-line interface for only the backup-restore functionality shall be set up again to make this very important step much easier to perform and maintain.
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
For teaching Databases and SQL, I would definitely continue to use MySQL. It provides a good, solid foundation to learn about databases. Also to learn about the SQL language and how it works with the creation, insertion, deletion, updating, and manipulation of data, tables, and databases. This SQL language is a foundation and can be used to learn many other database related concepts.
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.
I give MySQL a 9/10 overall because I really like it but I feel like there are a lot of tech people who would hate it if I gave it a 10/10. I've never had any problems with it or reached any of its limitations but I know a few people who have so I can't give it a 10/10 based on those complaints.
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
We have never contacted MySQL enterprise support team for any issues related to MySQL. This is because we have been using primarily the MySQL Server community edition and have been using the MySQL support forums for any questions and practical guidance that we needed before and during the technical implementations. Overall, the support community has been very helpful and allowed us to make the most out of the community edition.
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.
MongoDB has a dynamic schema for how data is stored in 'documents' whereas MySQL is more structured with tables, columns, and rows. MongoDB was built for high availability whereas MySQL can be a challenge when it comes to replication of the data and making everything redundant in the event of a DR or outage.
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.
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.