Share your experience using SingleStore

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.

I worked for a company that outsourced tasks for SingleStore. I mainly worked with one customer who was a video platform. Their primary use case was storing metadata for their videos. They offered recording and playback services for TV shows in the US and Canada, and SingleStore efficiently managed the metadata for all these recordings.

 There's a wide range of professionals using SingleStore,  You can find more details on their website.

Since it is not as costly as  Oracle or other database counterparts, that's one benefit. And the speed is very fast. It supports in-memory data types, storing data on RAM for blazing-fast performance. That's the highlight; it's perfect for both OLTP and analytical workloads.

It's a distributed relational database, so it does not have a single server, it has multiple servers. Its architecture itself is fast because it has multiple nodes to distribute the workload and process large amounts of data. I heard a client processed 3.5 billion records in seven minutes! Their data ingestion is very high, and SingleStore even markets itself as the world's fastest database.

For new customers, it's very tough to start. Their documentation isn't organized, and there's no online training available. SingleStore is working on it, but that's a major drawback. 

Also, technically,  SingleStore needs more features on the SQL part. Most SQL boards work in MySQL, and SingleStore integrated all its sequel with MySQL, so nearly 99% of MySQL code runs on SingleStore. But features like TVF and UDL lack depth. Users have to walk into it, and SingleStore has minimal features there.

IUDF, TVF, and stored procedures are not as advanced as SQL Server's. That's one thing I would like to see improved. 

I worked with SingleStore just two months before resigning from my previous company. I have over two years of experience with it.

It is a stable solution. Any downtime I've seen was due to application or software bugs, not SingleStore. Human errors happen, but the system itself is stable.

It is a highly scalable solution. SingleStore has servers, separated into two parts.  One aggregates queries (gateway nodes), and the other stores data (leaf nodes). 

To increase database size, you simply add more servers. There's minimal downtime during rebalancing, maybe a minute or two. You can add as many servers as you need without taking anything offline. That's what makes it highly scalable.

We mostly handled day-to-day maintenance. But for the real heavy lifting, there's a separate team in SingleStore. It's all handled through one ticketing tool, Zendesk. You're a registered customer, you log a ticket, and they prioritize and address them accordingly.

Positive

SingleStore offers cloud and bare-metal installations. 

Cloud hosting is simple; you pay hourly and follow their cloud UI instructions. Anyone, even someone less technical, can install it. 

For bare metal VMs, it might take a day for a new technical person, but an experienced one can do it in an hour. It's quite easy.

The customer I supported had an on-premises SingleStore cluster running on bare metal.

One technical person is enough for deployment if it's not a production-grade cluster. For testing, one or two days should be max. 

For production-grade clusters, you might need professional services. SingleStore also offers database architects and consultants to help design your cluster architecture, hardware selection, license units, etc. They basically do everything for you, from designing the blueprint to setting up hardware and licenses. So, professional services are highly recommended for production environments.

If you have many clusters (over 10-15), you might need a team of 3-4 people for maintenance. But for 1-2 servers, you can handle it yourself. It's easy after the initial learning curve. And best of all, no downtime! You can perform maintenance tasks online, like adding a new service ID or scaling your cluster, without impacting your business.

The product offers high availability. Two copies of data at all times, so even if one server goes down, your application stays up. That makes maintenance even easier. You can take a server down, fix it, and put it back without impacting users. This makes maintenance very easy. 

As long as one server is running, you're good. The only limitation to high availability is the increased cost. You need more servers, which means more money. Think of it like this: without high availability, you'd need X servers. With it, you'd need 2X servers. Hardware costs go up.

I had a customer I worked with for five years who kept adding new customers throughout. SingleStore provides significant cost-based value to companies.

The pricing is available on the website, https://www.singlestore.com/pr.... They have two main options: cloud installation and bare-metal installation, each with different pricing models.

For cloud services, they offer three tiers: Standard, Premium, and Dedicated. Standard starts at just $0.80 per hour. This is for the standard cloud service.

Now, for self-managed on-premises clusters, they provide free licensing up to four units. If you need premium features or enterprise support, like direct access to their support team, you'd need to purchase their enterprise license. For specific pricing on those, I recommend contacting their sales team directly.

I'm currently focusing on C++, building my resume for web development. I want to be a programmer and build things, not work in a service-based company. That's why I moved on. But I'm happy to help with any service-related tasks or where my two years of SingleStore experience might be useful.

Online resources are limited since it's a new database. So, first, read the documentation to understand the basics. Then, approach them directly and explain your specific use case for the database. 

Their sales team is very responsive and can help you get started. I highly recommend this database, but do your research first because online materials are scarce. Just understand the basic terms and policies in the docs, then contact them to set up your clusters.

Overall, I would rate the solution an eight out of ten.