SingleStore Reviews

I use it for managing both transactional and analytical workloads within the same database. In my previous organization, I successfully implemented it for a banking system, where it accommodated transaction-based processes using row store tables and analytical requirements using column store tables. This dual functionality eliminates the need for separate databases for transactions and reporting, streamlining the overall architecture. With SingleStore's distributed architecture, it provides the scalability needed to support diverse workloads effectively.

Its in-memory storage, distributed architecture, scalability, and failover mechanisms collectively contribute to its exceptional performance and reliability, especially in demanding transactional environments like online and mobile banking systems. The ability to store data in memory is a standout feature, enhanced by robust failover mechanisms. Even in scenarios where all servers experience downtime, it ensures data safety by maintaining a copy on disk.

The critical challenge involves optimizing the distribution of data across partitions through careful design of the sharing key. Poor key distribution can significantly impact performance, requiring a backward approach in design rather than adding tables incrementally. Intricate use cases, especially those involving joins across multiple tables, pose challenges if sharing and distribution are not well-aligned. Unlike traditional databases where indexing may suffice, SingleStore may require redistributing the entire dataset, presenting a persistent challenge.

I have been using it for four years.

The stability of SingleStore varies depending on the use case. For a transaction-based system, I would rate it around eight out of ten. However, if it's utilized for an analytical system, I would give it a rating of around seven out of ten.

Scalability is its key strength. Adding servers for scalability is a straightforward process involving simply incorporating a few additional servers and recycling the cluster triggers automatic repartitioning and redistribution of data. For instance, if the initial database creation involved a hundred servers and later, four more servers are added, specific commands can be executed to increase the partitions to one hundred twenty. The data is then efficiently redistributed across the expanded partitions without the need for manual data movement, ensuring a seamless and efficient scalability process. In my current organization, approximately three projects involve the usage of SingleStore, with a team size ranging from ten to twenty individuals.

During the onboarding process at my previous organization, SingleStore provided dedicated support for five to six months, offering invaluable assistance. Presently, with our current service providers partnered with them, support involves raising a ticket, leading to the allocation of a dedicated person for assistance. This personalized approach enables an assessment of the issue, considering factors like data volume. Additionally, the forums serve as a helpful resource for addressing queries, although responses may take a few days. I would rate it eight out of ten.

Positive

We transitioned from using IBM Db2 to SingleStore due to a shift in our infrastructure plan. Initially designed for on-premise deployment, we sought optimized server capabilities for a banking process, with a primary goal of cost reduction compared to mainframe expenses. In our current project, SingleStore is predominantly employed for analysis and reporting purposes. Previously, Palantir and Vertica were used for reporting, but observations of drawbacks in these platforms led to the decision to migrate to SingleStore for more efficient analysis and reporting capabilities, which is proving successful in our current setup.

The initial setup is straightforward, with comprehensive tutorials available on its website. Beginners can easily follow the step-by-step guides, either for a local installation or on cloud platforms like Azure.

The installation process is user-friendly, requiring the selection of a cloud provider and a few configuration choices. Unlike on-premise solutions that involve server setup, SingleStore simplifies the process, making it accessible to a wide range of users. For on-premise installations, specifying server details and failover architecture is necessary, but once the server is prepared, the installation itself is uncomplicated. Database creation involves specifying configurations and requirements, and streamlining the overall setup process.

The platform's versatility allows it to cater to various use cases effectively. Unlike other databases that might require separate solutions for transactional and analytical needs, it offers a unified solution for both. This dual functionality appeals to organizations seeking cost-effective solutions, as they can invest in a single database to address multiple requirements.

Using it for analytical purposes can be cost-effective in the long run, especially in terms of infrastructure. While building an on-premise cluster incurs an initial cost for servers with ample RAM, it becomes a one-time investment with subsequent maintenance handled internally. For cloud deployments, the cost may be relatively higher due to instances offering lower RAM. Opting for higher RAM in cloud instances increases the per-server cost. However, it's important to note that this is a one-time expenditure, and maintenance becomes more straightforward.

I would advise individuals to consider it for transactional systems, particularly if their requirement is for millisecond-level performance. The row store feature is well-suited for such applications. However, it's essential to be mindful of the associated costs, whether deploying on the cloud or on-premise. Due to the need for substantial RAM to store data in memory, the cost can be significant, especially for larger datasets. Overall, I would rate it nine out of ten.