Share your experience using SQream DB

I use the solution in my company as a database management system, specifically as a relational database management. Mostly, the tool is used in the banking environment to keep historical data, especially in banks like Deutsche Bank and UBS. Banking environments use SAP Adaptive Server Enterprise because they can store historical data, after which manipulating data can be done at a fast pace. When it comes to reporting, SAP IQ is good because it can pull crores of records in minutes, and it is one of the things that can be used in the banking environment.

The most valuable part of the tool stems from the fact that it is a very cost-efficient product compared to the newer technologies because it needs a very small amount of RAM. The infrastructure required for the product to run is much less. The maintenance required for the product is also very low. Even in a small project, one person is enough to maintain and handle the solution.

SAP is least bothered about Adaptive Server Enterprise nowadays since it wants to focus on promoting its new product, which is S/4HANA. If SAP gives out new releases and a patch upgrade to improve performance and provide additional options, then SAP Adaptive Server Enterprise can compete with other relational database systems in the market. The overall performance of the product is an area where the tool has certain shortcomings and needs to improve.

I work in a very stable environment, and I prefer a very stable replication and database management system. Most of our company's customers do not want to opt out of SAP Adaptive Server Enterprise, but SAP has announced that it will be ending its support for it in 2027, and though I feel SAP might extend it, I feel SAP will want to promote its new product. Previously, I heard that SAP Adaptive Server Enterprise's end-of-support dates were announced for 2025, but now I think that they have extended it to 2027 or 2030.

I have been using SAP Adaptive Server Enterprise for nine years. My company is a customer of SAP.

It is a stable solution, but when you end up facing some issues with the tool, you will start facing problems since there are very few technical persons in the market who can handle the product. It is not very easy to fix the issues with the product since there are only a few technical people left in the market who know about the product, and most of them have moved on from the solution already.

It is a scalable solution that can handle a large amount of data.

As far as I know, my company deals with around seven to eight customers of SAP Adaptive Server Enterprise, but there are no technical people to help with the solution. I am the only technical person in my company who is available when it comes to SAP Adaptive Server Enterprise. I only work on two accounts associated with the product, while there are seven to eight accounts needing support. SAP does not want to give its complete billing process to a technical person, which is the major reason why SAP manages it by itself.

Earlier, there were not many applications using SAP Adaptive Server Enterprise. These days, most of the applications are connected to the database provided by SAP Adaptive Server Enterprise, after which many have started facing new issues in the product, which may, to an extent, be a new one even for SAP. SAP has been releasing notes and fixes to deal with the issues associated with the product. Sometimes, if SAP faces a new issue with the product, it notes it down and releases a solution for the problem.

The product's initial setup phase is easy. SAP has made the setup phase of Adaptive Server Enterprise easier to deal with compared to how its process was in the past.

Mostly, SAP Adaptive Server Enterprise is deployed on a private cloud while some of our company's customers have it deployed on Azure or on an on-premises model.

Price-wise, the product is worth it since one needs very less infrastructure to use it. If you speak in numbers, I would say that when it comes to S/4HANA, you need RAM memory to be in terabytes. If one uses 128 GB for a production system, it will be very high as it can hold data till three or four TB, and it can give you results in seconds.

My company chose the product over the other tools in the market in the late 2020s, and it was a booming solution. Oracle had been sidelined by many since earlier when there were no new releases from SAP. When I entered the IT field, seizing a better opportunity, I chose SAP Adaptive Server Enterprise because I knew that it would have very few complications. I also knew that if you were well versed with SAP Adaptive Server Enterprise, then you would have great demand in the field and would get opportunities to work on the solution.

Whether I would suggest the product to others or not is something that depends on the kind of business they do. If you want to pull reports or store data and do calculations, then you need to have additional products along with SAP Adaptive Server Enterprise. If you want to store data that may run into terabytes, then it is possible to do so with SAP Adaptive Server Enterprise, and such data will not get corrupted.

I don't think that it will be easy for someone to learn the tool, but it may be easier if done on a black and white screen. There are not many graphical user interfaces available for the product, and it has more SQL and is a tool that has a simple English language, which is not like any programming languages but something like a simple query language.

I rate the tool an eight out of ten.

I have used MySQL for the past two products that I have been a part of. MySQL serves as our database layer where we store all our data across whatever platform we have. It functions as the main component that stores our data.

Our product is quite large, so we have multiple databases, with MySQL being one of them where we store user data. Our product is a hiring-based platform, so we store user data, enterprise data, and the jobs that users assign, among multiple other things.

I haven't used a different solution previously, but we are currently using MySQL as well as MongoDB for our database needs.

MySQL is an RDBMS database, and I have also used MongoDB. MySQL has its own advantages as well as disadvantages. With MySQL, we can easily store data. The latency for accessing data is lower than MongoDB because MongoDB stores in BSON format, whereas MySQL stores in table format. This makes it suitable, and I believe for the type of product we have, this is the right database choice.

MySQL has low latency and is very easy for our use case. We are using Sequelize with it, so implementation is straightforward and putting data into MySQL is simple. As an RDBMS database, the relational management is excellent. There is less redundancy, and the table structures are well-defined beforehand. Before putting data in, we must create the table and set everything up properly. Error handling is also very good.

Performance-wise, MySQL is very fast and reliable. We have deployed it on AWS servers, and it is quite reliable. From an integration capability standpoint, integrating it with any platform or application is fast and easy to use. We simply need the database details and to create the tables we want, and we can start using it without hesitation.

As an RDBMS, MySQL provides us great capability. For a product growing to large scale like ours, where we currently have around 10 lakh users but will grow to 20, 30, 40 million or more, having a strong database foundation is essential. MySQL provides that. Creating a database with good structure is crucial, and foreign key and primary key relationships should be well-defined beforehand. MySQL ensures that you create tables in a manner that makes it easy for end users and simple to grow that particular database in the future.

MySQL is very reliable because it has ACID properties, including atomicity and consistency. Replication is easy, and we are replicating it with one of our search services used for fast searching. Scalability is very easy, and security features are very good for enterprise editions, providing transparent data encryption, authorization, authentication, and firewalls.

MySQL can be improved in several ways. It has connectivity errors and administration troubles that sometimes occur, though not consistently. MySQL has slow queries; sometimes when I run a query, it scans the whole table, and if the data is very large, it takes too much time to retrieve the data. There can be resource bottlenecks with RAM and CPU usage being a little lower than ideal. Monitoring system metrics is crucial because we need to identify and address these types of issues. Schema designing is another area for improvement, as a poorly designed schema can lead to data redundancy in the future. If I haven't initially planned for a 20 lakh user database and am only working with a 1,000 user case, it will be very problematic because in the future, it will affect the whole table structure, and we will need to change everything. Thorough thinking is necessary before even creating the table.

MySQL documentation could be better. Sometimes when I need to find something related to MySQL, the documentation is not very comprehensive. If I have a problem with it, I have to go to Stack Overflow or something similar to get the full detail. Additionally, sometimes when we are connecting to local MySQL, it says we cannot connect to SQL, and I don't know the reason. The error messages are not very helpful, so we have to investigate those cases manually. There are multiple instances of this occurring.

Documentation can be better overall. The integration capabilities could be improved slightly. Whatever I have used is working fine for me currently, but it could be a little better. The UI of MySQL Workbench, which I use, is not appealing to me, so it could be improved. MySQL overall is very good, and the foundation is very strong. We can develop features around it and different types of things inside it, which will make it better in the future.

Regarding stability, MySQL is quite stable for us. The product that I am working on is quite stable because we have been using it for three years, and it hasn't given us any problems. The newer LTS versions are the safest for us, especially when we are releasing to production, so they are our go-to choice, and they are stable.

If the database foundation is very good with well-thought-out table structure and everything, then scalability is easy. However, if you are not thinking about the next few years and the client's user database size increases or the use case demands more, you have to consider it beforehand. If that is properly considered, then MySQL is the best option because you can easily grow from 1,000 people to 10 lakh people.

I think customer support is very good. I haven't interacted with it personally, but it appears to be good. From Oracle, they are providing customer support, and we can submit service requests that they solve on a 24/7 basis, providing solutions within a few hours.

Positive

Regarding money saved, we have a 10 lakh user case with user data. I believe in that case, we have saved quite a bit because we set up the foundation very well, and the setup was very good thanks to my seniors. Currently, we are building on top of it, and because the foundation was very good, we are able to scale it further. If we want to scale to 30 or 40 lakh people, then it is still possible, covering three to four million users. So that is good for us right now.

If I give MySQL a rating, as I have said, I have worked with both RDBMS and non-RDBMS databases. In both cases, I would give it a solid nine. It is actually used by multiple companies, and it is actually very good. It is a foundation, and if it is implemented perfectly, then it will be very good in the future.

If your product has a clear table structure and you already know what data you will have and how to manage it, what the table structure will be, what the rows and columns will look like, and if you know how it will grow eventually in the future and understand the end-to-end process, then MySQL is the best option to choose. If you have doubts about some tables, then you can use another type of non-RDBMS databases. If you have clarity about some things and not clarity about others, then you can use a combination of both as well. It depends upon the enterprise use case.

If you have clarity about how you are going to scale and how you are reducing redundancy among the data, then MySQL is the best option. I would recommend going for it. I give MySQL an overall rating of nine.