What is our primary use case?
Our company currently uses Scylla for our products since we are in the process of migration from Postgres.
Our company is reimplementing the user data pipeline and needs faster results. We found Scylla to be preferable for our use case from the alternatives we evaluated.
What is most valuable?
User-defined type in Scylla allows for data to be consistent. The performance aspects of Scylla are good, as always. The product's flexibility allows us to use Cassandra SDK with it while also being able to migrate from DynamoDB to it. A good point about Scylla is that it can be used extensively.
What needs improvement?
It has just been a month or so for me with Scylla. The documentation of Scylla is an area with shortcomings and needs to be improved. Improvement of documentation is needed considering that I work with Java. We currently use a data stack model, which is actually for Cassandra. There is no different dependency for Scylla, so it's adding a wrapper on the SDK that Cassandra supports, and we end up just using it.
I think it's good as it is. I don't have any input on what needs to be added in Scylla.
For how long have I used the solution?
I have experience with Scylla for around two months. Currently, I am learning more about Scylla. I am using the solution's latest version. My company is a system integrator. We have different verticals, and one of it is that we are moving into is integrating, which is running our product as a binary in our enterprise solution and on clients' machines.
Buyer's Guide
ScyllaDB
July 2025
Learn what your peers think about ScyllaDB. Get advice and tips from experienced pros sharing their opinions. Updated: July 2025.
865,295 professionals have used our research since 2012.
What do I think about the stability of the solution?
Stability-wise, I rate the solution a nine out of ten.
What do I think about the scalability of the solution?
Currently, we are involved with Scylla's prototype version. For the project that I am working on, Scylla is not being used, and it is not just the case with my project alone but also with a huge number of projects because they are moving to cloud-agnostic architecture. We are moving all the DynamoDB databases to Scylla. Within a year or so, all of our DynamoDB databases will be replaced.
To be able to rate Scylla's scalability, we would need time since we are using its prototype.
Which solution did I use previously and why did I switch?
Previously, I have used MongoDB for other projects.
We actually are not switching from MongoDB. We have a couple of alternatives for what we are building, and we wanted to know about SQL because we may have to change our schema quite a bit because we used to have a lot of metadata, and that's why the traditional RDBMS will have to split the columns instead of rows, making it very intense.
How was the initial setup?
Scylla is a cloud-based solution. We are moving to a cloud-agnostic architecture, so we would have different instances based on our enterprise solution or the client.
Whether to use a private or public cloud depends on the requirements of our clients.
In my local environment, the installation part was quite easy because it's a Docker installation. I don't know about the remote installations with Kubernetes because that is managed by the cloud tech team.
What other advice do I have?
I have been working on the solution for around a month, so it is mostly the people involved in the cloud tech department who look at things like the maintenance of the solution, an area in which I have no idea.
A weird error can pop up owing to the flaws in the documentation, because of which I am using an ORM tool to interact with the database. If required in a particular use case, I return a list of objects, or a list of a user data type, when it throws an error indicating that I should reimplement the codec. When I changed the codec to set, it started working fine. The aforementioned issue was not figurable even in Stack Overflow.
Overall, I rate the solution an eight out of ten.
Disclosure: My company does not have a business relationship with this vendor other than being a customer.