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.
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.
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.
Software Engineer at a computer software company with 1,001-5,000 employees
Real User
Top 10
Jul 18, 2023
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.
Consultant at a comms service provider with 10,001+ employees
Real User
Jun 6, 2022
Data export, along with how we can purchase the data periodically, needs to be improved so that the storage is within control. Then, we could optimize it even better.
ScyllaDB is an open-source, distributed NoSQL wide-column datastore (a highly scalable NoSQL database), known for its compatibility with Apache Cassandra, and for supporting the same protocols as Cassandra (CQL and Thrift) and the same file formats (SSTable). ScyllaDB is designed for high throughput and low latency, making it suitable for data-intensive applications. Its architecture allows it to deliver remarkable performance on a massive scale, utilizing modern multi-core servers...
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.
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.
The product needs to add more features and improve the response time of the support team.
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 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.
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.
Data export, along with how we can purchase the data periodically, needs to be improved so that the storage is within control. Then, we could optimize it even better.