We used ScyllaDB as an alternative to MongoDB. Our company's MongoDB servers experienced malicious attacks, so we migrated to ScyllaDB.

We read from MongoDB and wrote everything to ScyllaDB because it's considered safer than MongoDB.

There are two that I like most. Firstly, if I update something, it's most likely to finish within milliseconds. Anything can be updated without writing too much code. Secondly, I like CDC.

When it comes to the performance, it's not as good compared to MongoDB or Postgres. However, performance is not a big issue in ScyllaDB. If you have a very large scale of data, it takes at least five milliseconds more time to execute the query compared to MongoDB or Postgres. This is the little drawback in ScyllaDB. But on the safer side for CDC, read and write, and all things are good in ScyllaDB.

There are some extra packages we can apply on ScyllaDB separately. We can add some extra layers on top of ScyllaDB to improve the performance. So, it can improve throughput, latency, scalability, and performance.

The documentation is not well established for new developers. If a developer is starting their career, it's not ready to use. MongoDB and other things are very scalable and everything is documented. But here, everything is not documented. You have to go to the GitHub repo, Stack Overflow, or Google things.

The documentation is not well maintained. But if a developer is experienced, like two or three years in MongoDB, they can make the wrapper cluster and use ScyllaDB easily. If anyone is pressured, it takes some time to adjust to ScyllaDB because the scalability and performance on the internet are not well improved, and the documentation is not well written or maintained.

I used it at my previous organization.

Initially, about two years ago, they would support us by responding within 24 hours if we posted any problems on the data repo. We could also debug ourselves and search on Google to fix issues.

There also support on the GitHub repo. You can post anything and get responses.

If you post one problem, they can find similar problems and give you answers to those as well. For example, if you ask about latency, they can give you information about throughput, scale, performance, and areas you can improve. So if you ask about one question, they can give you the answer to that question and similar questions as well. That is one of the best things.

If your wrapper class is written in a well-structured and managed way, there is no problem. But if you have a connection issue between your local machine and the server with ScyllaDB, there could be problems in deployment.

In MongoDB, if there's an error, we can still deploy easily on the server, but ScyllaDB might break down during deployment. So make sure all errors and things are well maintained and handled in ScyllaDB when we deploy.

When it comes to the configurations, ScyllaDB configurations can take overhead compared to MongoDB. But in terms of freshness, all these things are good.

There can be challenges while integrating it into the existing infrastructure. If you are working on MongoDB and completely want to switch from MongoDB to ScyllaDB, you have to make a similar clone of the ScyllaDB instruction. Everything can be read from your existing database. Then, implementing the plus of ScyllaDB, you have to write everything into ScyllaDB instead of the existing database. If you are completely migrating, you can redirect from the existing database to ScyllaDB. But make sure the connection between the server and the local system can be established, and the TCP protocol is working.

It is worth it. It is a performance optimizer and is safer. There are no malicious attacks on your server, and it is safer with immediate CDC available. For other things, you have to write logs separately, but ScyllaDB has logs available in RediView itself. So you only have to enable them, and you can both with the implemented logs. So there are two or three things better than MongoDB.

MongoDB pricing and ScyllaDB are similar. It is worth it.

Overall, I would rate it a seven out of ten because there is some lag with the documentation and with existing databases. If you have no experience with Node developers, it might not be suitable for working with ScyllaDB. You have to have a good knowledge of ORM before using ScyllaDB. If you don't have experience with MongoDB or ORM, you cannot go with ScyllaDB directly. You have to take some time and face many challenges. So I will go with seven. Initially, it took some time, and I faced many challenges when I integrated it. But after some time, it was okay.

I would recommend people to go with ScyllaDB because of its performance and latency compared to MongoDB. Also, the logs are better, and malicious activity can happen in MongoDB but not in ScyllaDB. If you want to protect your database in MongoDB, you have to pay extra money, but you don't have to pay extra in ScyllaDB. So there are two or three things better in ScyllaDB compared to MongoDB.

For security reasons, we collect millions of signals and put them into the S3 bucket. Once we run Spark job on the raw data, we take all that data and send it to ScyllaDB.

ScyllaDB allows fine-tuning of the table structure. Speed is probably the most critical factor because we perform a lot of heavy data ingestion. One of its core features is its ability to handle high volumes and maintain speed when accessing data. Additionally, high availability and partitioning are built-in features of ScyllaDB.

Properly designing your queries first and then your data model accordingly ensures optimal performance. Another issue to consider is deletions. ScyllaDB does not handle heavy deletions well, which is understandable since it is built for heavy ingestion and fast queries. It works like a charm once users understand the product and its capabilities.

ScyllaDB needs to improve its handling of transactions. When data is deleted, it is not immediately removed; a background process handles the deletion, which takes time. This delay can slow down queries, as they must consider these pending deleted transactions. ScyllaDB should ensure that deletions are processed more efficiently to avoid this issue.

Additionally, ScyllaDB's data modeling needs improvement. If a poorly written query is executed, it can severely impact server performance, causing the server to lock up. ScyllaDB needs to enhance its robustness to handle such scenarios better.

I have been using ScyllaDB for two years. We use a managed service.

Since we use a managed service, they can catch issues much more quickly than we can. They also deploy new patches and updates regularly. We don't need extensive bug testing because they handle all that. However, we tend to break our server through actions, which is usually our fault. Nonetheless, the database releases are very stable.

We have thousands of users on our platform.

Support is very responsive. They handle any issue, regardless of severity. We pay for the managed service, which is not cheap, but the reliability is excellent for those who can afford it.

ScyllaDB is worth the investment if you get returns from the product that benefits your company. However, despite the product's quality, our company is struggling because we are not seeing the expected returns from our customers.

When it comes to performance, ScyllaDB requires you to model your queries first. You need to know what kind of queries you will be running. If you get that part right, data modeling in ScyllaDB will become much more efficient and work well with you. However, running ad hoc queries or queries that were not planned for can lead to increased latency.

Anybody from PostgreSQL, Oracle, or MySQL will experience a learning curve. Typically, with Oracle or PostgreSQL, you design your data model first and then your queries. However, with ScyllaDB, you need to know your queries first and then create your data model accordingly. The learning curve is not too steep—you can learn it within a month or even less. Once you have set it up, switching to another database is hard. ScyllaDB has significant advantages in handling high-volume data ingestion and providing breakneck query speeds. We were struggling with the high volume of data on Postgres.

We moved from Postgres to ScyllaDB. We had to rewrite our queries and data models, resulting in a significant effort. For us, this migration took almost six months. However, for someone starting fresh with ScyllaDB, this extensive effort might not be necessary.

If the use case involves heavy data ingestion and requires very low latency, I would definitely recommend ScyllaDB, provided there is a budget for hosting or managed services. If the requirements fit, it's a great choice. However, you need a developer team that knows how to use it, as well as people for maintenance and database administration. ScyllaDB is worth it, but it does not run by itself. You need people to manage it.

If you have a high volume of data, high ingest rates, and low delete requirements, ScyllaDB is a great choice. It offers features like auto partitioning and many other benefits. However, if your data volume is not very high and latency is not a significant concern, you should evaluate other options. It's important to understand your specific needs and what ScyllaDB has to offer before making a decision.

Overall, I rate the solution a seven out of ten.