We dump a lot of our data, such as every entry created with respect to when a user rides a scooter, every record gets updated to ScyllaDB. It is used as a single source of truth and it manages massive data. 

We support various business use cases, including mobility, where data about driver allocations get updated. We currently have twenty clusters and more than one hundred nodes.

The performance and scalability are good, and we hardly see any major issues with ScyllaDB. Updates are reliable and help the organization handle large datasets effectively.

To be honest, not really. We were sold on the pitch, offering better compaction and ROI, but we did not experience these benefits.

From a sales pitch standpoint, it needs to deliver on promises of better ROI and compaction. Additionally, ticketing and support systems could be improved due to the time it takes to get answers. There's also an issue with compatibility when attempting to switch back from the enterprise to the community version.

I would say probably five years by now.

The performance and stability are fine. We hardly see any major issues, and from a reliability standpoint, it's all good.

Due to organic growth, we end up upgrading the cluster and adding more nodes. In terms of reliability, it's all good, but specific benefits from scalability were not highlighted.

The technical support and customer service are around a five or six out of ten. Improvements can be made in ticketing and response times.

Neutral

We used to work with Cassandra. During our initial phases, we found ScyllaDB promising due to its implementation language and maintenance, which led us to adopt it over Cassandra.

Migrating to the enterprise version from the community version is straightforward and supported, but moving back to the community version is complex due to compatibility issues.

To be frank, not really. The open-source version sufficed our use case without requiring the costly enterprise version.

The enterprise version comes with a cost of about $300,000 per year, however, we did not experience the promised compaction benefits.

We evaluated Cassandra during initial proof of concepts.

I would suggest using ScyllaDB wisely and adhering to best practices, such as regular cleanup since many engineers tend to expand clusters instead of cleaning up data. I would rate ScyllaDB as eight out of ten.

We use ScyllaDB, a NoSQL database, as a distributed system to store customer data. My last project was in telecommunications, where we stored caller information like phone numbers, names, and scam tags for a scam call protection service. We handled insert, update, and other operations since the back-end AI system needed daily data inputs. We ran scripts to add the data to ScyllaDB across two AWS regions: US East and US West. One Scylla node handled requests, synchronizing data with its peer nodes. During the POC phase, we testedperformance, read/write operations, and latency and chose the right consistency levels for ourneeds. After that, we moved to production.

We are customers, not partners, and we’ve used ScyllaDB to implement an application in our company.

The best features of ScyllaDB are how it synchronizes data and its failover system. There's a unique formula to decide the number of nodes you need and the minimum required, which I find helpful. It also offers encryption and supports APIs, making it great for distributed systems

and scaling databases across different regions. While it's easy to use, having prior experience helps configure it properly. There are many configurations; if you don't understand them, you might mess up the design. So, understanding your system's needs, like whether it requires more read or write operations, is crucial for setting up the correct configuration.

We faced several challenges while integrating ScyllaDB into our AWS environment. One common issue was that a security port wasn’t opened on one node, preventingdata synchronization across clusters. We noticed the data wasn’t syncing correctly when we saw different record counts in other regions. After investigating, we found that the port was closed in one AWS region. Once we opened the port, the data synchronization across all nodes resumed as expected.

I've been using ScyllaDB for the last three years. Initially, we worked on some POC projects and deployed one live project into production.

I've had some stability issues with ScyllaDB. For instance, if one of the nodes in a cluster goes down, sometimes the APIs or command line tools don't work to read the node's status. You might need to restart the node to bring it back up manually. It can be challenging if the node'sstate gets messed up and must be cleaned before re-adding it to the cluster. Based on stability, I'd rate it a seven out of ten. However, since we're using the free version, it might be more stable with the paid version, which could be a nine out of ten.

The paid version of ScyllaDB is not that expensive. The main advantage of the paid version is direct support from the ScyllaDB team, which can resolve issues faster—typically within a day, compared to two to three days with the free version. The paid version also offers better guidance and support, while the free version has good documentation and is more high-level. I’d rate their support team nine out of ten because of the quick responses from their community.

I would recommend ScyllaDB to others. It’s a great product built on Cassandra, with added advantages. For newcomers, it’s a distributed database with excellent scalability and performance and very low latency for all kinds of operations. Overall, I’d rate ScyllaDB an eight out of ten.

We have a business model that requires heavy reads for several applications all in one place. So we decided to use ScyllaDB because of the workload, to have multiple reads and writes at the same time.

I like how fast it is to query data from the ScyllaDB node! Because it can actually enable you to query any data from any node as fast as possible. And the ability to save the same copies of data across the cluster, depending on your setup as well. It's really fast.

Some of the regular commands in NoSQL do not work. It's Cassandra and ScyllaDB, so you have to make custom commands to be able to query data sometimes. It doesn't have universal compatibility. It will not allow you to make use of some functions. So, I have to do custom queries to query data.

I have been using it for about a year now.

I experienced one or two bugs, but for the database itself, it's stable. For other features, such as the ScyllaDB Manager (the one you use to control other nodes, make backups, and check the status of other nodes), there were issues. When you deploy ScyllaDB, you also deploy another instance for the manager that helps you control dashboards and visualizations. 

In the previous release, there were one or two things they had to correct, which sometimes caused unexplainable errors. You had to update to the latest version. But so far, their 3.3 version has been really stable. I updated it last week.

We have about two teams right now, so the number of people would be about eight to ten.

I have contacted the customer service and support. We are trying to move to the enterprise version because the open-source version is limited. 

I think everyone is trying to adopt ScyllaDB, and it's quite new. There isn't enough information on the Internet if you don't have support. So we are considering getting support as well.

ScyllaDB is trying to build their customer base right now. They are very on point. I've just had a few interactions with them, but I strongly agree that the support is very good.

Positive

We had a business model, and we tried to do a bit of research to see which one fits best. Because of ScyllaDB's scalability and high performance, they chose it. 

We are a financial institution and we have relationships with several banks and fintechs. So we have their data in-house, and we try to manipulate this data, derive analytics from it, save it in different forms, and manipulate it. 

ScyllaDB helps us manage high data volumes and support rapid read and write operations. It is also very effective when we demand high throughput with low latency and the ability to scale as fast as possible. 

We had existing databases such as Mongo and SQL Server, but we were having performance issues. We needed something to expand, something to have a broader reach, something to give us more robustness. So that was the reason why we went with ScyllaDB.

The initial setup is pretty easy. They have their documentation cut out really nicely. It's like the more regular installations you have to do for a database cluster. But, yeah, it's pretty easy.

We use the open-source version on-premises, but we're trying to move to the enterprise version. But currently, we are deployed on-premises.

It's a bit expensive. When we were given a quotation for our setup, it was actually quite expensive as well.

If you are not familiar with it at all and you're trying to adopt it for the first time, it's going to be incredibly difficult. It's a journey that we have passed through. Without proper support or without going for the cloud model or the enterprise model where you get support from ScyllaDB, I would advise against going for ScyllaDB.

But if you want to try it out to see what it can do, and you're okay with running without support, I'd say fine, you can use it. It's a really good database.

But if you've explained your business model and what you want to use it for, my first question would be whether you are okay with running without support. If you can't, I would ask you to just look somewhere else for something that works better for you.

Overall, I would rate it an eight out of ten, with one being bad and ten being the best. I haven't really explored the full capabilities of ScyllaDB because without support, you don't know how efficient it can be and how your usage can be. 

The reason why I would say eight is because we've seen firsthand how ScyllaDB is able to manage a high workload. And because of its shared-nothing architecture, it distributes its views and processes.

We use the solution for distributed systems. 

ScyllaDB is fast and reliable. It has good performance. 

The product needs to add more features and improve the response time of the support team. 

I have been using the product for more than a year. 

We haven't faced any issues with the solution's stability. 

The solution's deployment is of medium complexity. 

You need to have database experience to use the product. I rate it a seven out of ten. 

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.

Neutral

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.

Positive

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.

We use the platform to manage advertising-related data, such as tracking ad views and demographic information.

The product's most valuable features are efficiency and reliability. Compared to similar tools, it consumes fewer computing resources and requires minimal maintenance, ensuring smooth operations.

I have been using ScyllaDB for approximately three years. 

We've had occasional performance challenges that required resource adjustments or optimizations in our interaction with the platform. However, the support team has responded and promptly resolved these issues.

I rate the stability a nine. 

The product is highly scalable.

The technical support team has been excellent. They are responsive and knowledgeable, providing timely assistance.

The initial setup has been straightforward in our experience. The deployment team handles the setup efficiently, typically completing it within a day with minimal involvement required from our side.

The product's efficiency has allowed us to optimize resource usage effectively. Its reliability reduces operational overhead, enabling us to focus resources on other critical tasks.

It is user-friendly for those familiar with databases. A basic understanding of database management is necessary for effective use and deployment.

I rate it a ten. 

We use it as a non-relational database. We use it to store two things:

1.  To store audit log data and 
2. blob data, including images with different sizes, like 200kb.

We use it as an image database as well, such as user profile pictures and product catalog promotional pictures.

ScyllaDB is a rewrite of Cassandra in C++ and uses a special library called Seastar, which was developed by ScyllaDB. 

Seastar is optimized for I/O operations, which makes it very good compared to Cassandra. Like it's ten times better in terms of performance.

The documentation is good. It integrates easily with our existing data infrastructure.

If you don't have the best computing resources, then it's not easy to set up. In such cases, we have to run ScyllaDB in developer mode.

I have been using it for five years. 

I have never faced any problems. As per my use case and our environment, it is stable.

It's pretty good. It offers everything we need at this time. It's a scalable product.

In my organization, all 55 people across six products use ScyllaDB.

We have never contacted customer service and support. It's all working great. So, never needed the support 

We tried MongoDB. It wasn't scalable at that time, like six or seven years ago. Then we moved to Cassandra and then ScyllaDB.

With best computing resources: If you have good computing resources like CPUs, memory, and especially solid-state drives (SSDs), the installation and configuration are very easy. 

Without the best computing resources: If you don't have the best computing resources, then it's not easy to set up. In such cases, we have to run ScyllaDB in developer mode.

It's free. Only support is costly. So the support is an extra cost, which is expensive.

I would recommend to use it. It is easy for a beginner to learn to use ScyllaDB for the first time. 

Overall, I would rate it a ten out of ten. 

ScyllaDB is a very seamless product within C++ or something. So, it's faster and all that stuff. Even if it is all good, there is more need for marketing on their website than on the original thing. 

Now, if you are a big company, ScyllaDB is a good, robust product. It's a terabyte/petabyte kind of product. But your cost would be one-third or even less with ClickHouse, and it would be smoother and lighter.

ScyllaDB is very fast, and I can use it for so many things. But what happened is we pushed a lot of data, and even though it was fast, things started getting weird here and there. 

At one point, we could understand why accepting this when you restart something or fix something and it starts working. You feel very smart, like, " Oh yeah, we did it right." But then again, these are the problems we shouldn't be having in the first place. 

But it is fast and very distributed. So, let's say you're Google, and you need your server in 500 places, and they all should talk with each other in close proximity. And you deploy ScyllaDB and have a dedicated DevOps version full-time. It's going to work. So, those things are there in ScyllaDB. But, again, it requires a full-time job.

It seems we have better options available. So probably don't go for ScyllaDB. The reason is, first, it's very high. It's not as straightforward as, like, Postgres or ClickHouse to set up. It requires a complex setup. 

The other problem is what they call. For example, they will say that for up to a million operations, you experience this. But the problem is if they have nine servers, then your one operation is counted as nine operations, not one. So, even though you have one write, they count it as nine. It's like it's just not false premises. You can always host it yourself, but then it's way more complex. 

The benefits are not substantially more than those of other databases. It's not that it's slow or anything. It's good enough and all. But it's just that ClickHouse or other databases are simpler and faster and probably provide more features. So, I kind of burn out from the database, and that's why I would keep it small.

I tried it for two and a half months. 

ScyllaDB claims it's very stable under a massive load, and I don't doubt it. We didn't have the database go down due to data load. We had problems with infrastructure showing racks from an infrastructure point of view. I don't blame ScyllaDB for not being stable, but in my experience, it wasn't very smooth when it came to infrastructure. If your infrastructure breaks, you have problems. 

Maybe if you use the cloud, you don't have to deal with it, but we didn't use the cloud. We tried to set it up ourselves and faced a lot of problems. Maybe I missed something, but we did it a couple of times, and each time there was a new issue. 

At one company, only five people used it for about two to four months. Our team consisted of two or three people who deployed and tested it.

We did talk to the support team for help. And funnily enough, we talked with US support. A lot of marketing people for ScyllaDB sit in Europe. So we talked with people in London, India, and America. They know their stuff. They are good people. They know their product, everything is good. 

What they don't know is if you ask any person, "Why should I use ScyllaDB over Clickhouse?" they will probably not give you a good answer. So, that kind of stuff. 

The other thing is that people are happy. But then again, if you want support on point, they charge some money. And I think we paid for two, three hours, and then it was extra. 

Basically, a lot of companies have a mode for ScyllaDB in the market because ClickHouse is a product of its own, and a lot of companies are already using something called Cassandra. ScyllaDB is bigger and better than Cassandra. It uses less memory and they claim it's five to ten times faster. 

It is not easy to setup.

I would rate my experience with the setup a five out of ten, with ten being easy.

It is an expensive tool compared to its competitor.

If you already use Cassandra, you can probably consider using ScyllaDB; otherwise, just avoid it.

Using ScyllaDB isn't that hard. Setting it up on the infrastructure side is the same as Kafka. Using Kafka is a piece of cake, but managing and setting it up is difficult. So, using ScyllaDB is not hard, but there are lots of unknown unknowns that you only discover after you get the bill or have users, and then you need DevOps help.

Overall, I would rate the solution a five out of ten.