My main use case for SingleStore is for our data retention and load management. We have infrastructure wherein the user's data are used for quick search, which means the searching functionality in our app is being handled with the help of SingleStore so that the searches are quick and easy for the users.

I decided on SingleStore for this use case because previously we were using AWS-related functionality, specifically EC2 instances, but those were not working well. I switched to SingleStore for the flexibility and infrastructure they provide, and it has helped us considerably.

The best features SingleStore offers in my experience are the excellent team support and the very good UI.

What makes the support stand out to me is that the UI is interactive and intuitive for first-time users. The team is also good at resolving issues, and I can reach out to them directly by creating a ticket whenever I face any issues.

SingleStore has impacted my organization positively because the output and performance of the app have been improved. I measured that improvement through both faster search time and better user experience based on customer reviews.

I have noticed that SingleStore can be improved because the integration of SingleStore with DataDog is not good. The data which is sent to DataDog sometimes does not match with the SingleStore dashboard.

I have been working in my current field for three years.

SingleStore is reasonably stable.

SingleStore offers good team support and their UI is interactive for first-time users. Their team is capable of resolving issues efficiently, allowing users to create tickets and receive support.

I did not previously use a different solution; SingleStore is the first solution which we implemented.

I did not purchase SingleStore through the AWS Marketplace. My experience with pricing, setup cost, and licensing is good.

I have seen a return on investment in terms of time saved.

The advice I would give to others looking into using SingleStore is that it is a good tool. The customer support is great. The integrations can sometimes be a problem that needs to be checked.

My main use case for SingleStore is real-time analytics and data storage and serving for my ML workloads. It enables me to run low-latency analytics and model-driven use cases at scale, which is quite difficult for OLAP and OLTP databases alone.

One specific example of how I use SingleStore for one of my model-driven use cases is as a data warehouse for fintech, which processes payments through TC worldwide. The integration with Azure Data Factory occurred without complications. It helps me in an excellent way since I am very fast in obtaining the data for my dashboards. Additionally, the compression of the information is accurate.

Regarding my main use cases with SingleStore, I think it is very useful for managing information for business intelligence processes and processing. Given that the information is brought quickly, it processes correctly when loaded into the dashboard.

The best features SingleStore offers include fast data recovery and data compression by 80 percent. Having the information in sheets helps me to process the information quickly. Simplicity in T-SQL is another aspect I appreciate.

Data recovery and sheet-based processing help my team on a day-to-day basis by enabling us to handle information efficiently.

I would like to add that the data compression by 80 percent helps us in an excellent way since we are very fast in obtaining the data for our dashboards and the compression of the information is great.

SingleStore has impacted my organization positively by enabling us to run low-latency analytics and model-driven use cases at scale, which is quite difficult for OLAP and OLTP databases alone. It has been very helpful because our internal clients are happy to have the data and make data-driven decisions easily. Making decisions based on data within a two-hour delay to the transactional database is excellent since we went from twenty-four hours to two hours. I think the best contribution is decision-making with data that is close to reality.

Reducing that delay from twenty-four hours to two hours has significantly affected my team and business outcomes by increasing productivity. We have been able to serve all our customers, and they are very happy. We can deliver to them on time.

SingleStore can be improved in the aspect that the Azure pipelines do not have many parameterization features compared to others, for example, AWS. Also, error handling needs attention. When it fails due to memory, it only indicates that but not exactly in which process it failed.

I would like to add that we need to know what the roadmap of SingleStore is.

An additional improvement needed is that the semantic layer can be better. Currently, it requires significant development experience to fine-tune queries.

I have been using SingleStore for six years and some few months.

SingleStore is stable as I find it extremely stable. I have not seen any downtime.

SingleStore's scalability is high and it can be used by any size of organization and can handle any needs of any organization.

The customer support is very proactive and responsive twenty-four hours per day, seven days per week.

Positive

I previously used a different solution, which was Oracle database.

I switched from Oracle to SingleStore because SingleStore outperforms based on my analysis with simple data sets within my organization.

I have seen a return on investment as real-time compute reduces the hassle of fine-tuning required, but it is minimal compared to other tools like Oracle or other RDBMS. Primarily, it was not client-focused. It was used for large enterprises with a significant amount of real-time data generation. The objective was to scale as data loads with high-performing query model responses.

My experience with pricing, setup cost, and licensing is that it can be a bit expensive for startups, but for my organization, the cost is affordable and cost-effective.

Before choosing SingleStore, I evaluated other options such as PostgreSQL.

My advice to others looking into using SingleStore is that it is extremely good for scenarios where large sets of data are generated in a day and the data is streamed. If you would like to run queries and analytics on such data, it would really scale and outperform TimesDB or Oracle in-memory options.

Before we wrap up, I have additional thoughts about SingleStore, stating it is a great tool that is very cost-effective. It shines as a unified solution for high OLTP and OLAP workloads. I rate this product a nine out of ten.

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.