Since SingleStore became free to use last November – for up to four nodes, and with community support – new, creative uses of SingleStore have abounded. One of the most impressive new implementations is from Katoni, an ecommerce hub that offers SEO tools via software as a service (SaaS) to mostly Scandinavian clients. Katoni has replaced Elasticsearch with SingleStore for SingleStore’s ability to handle complex queries with speed, scalability, and native SQL support.
SingleStore is currently the primary database powering Katoni’s SaaS suite of SEO tools. SingleStore runs alongside PostgreSQL, which serves as a secondary database for specific tasks such as projects, users, and billing.
Moving to SingleStore
Like many companies, Katomi was originally running on other technologies, then moved to SingleStore as problems such as slow query performance dogged their efforts.
According to Martin Skovvang, software engineer at Katoni, “We started out with Elasticsearch, but soon needed a replacement as our queries became more complex. Especially, the JOINs, subselects, and HAVING features provided the major benefit of moving to SingleStore, along with the transaction siupport, scalability, and ease of use.”
Katoni uses a combination of rowstore and columnstore tables. They are excited about some upcoming SingleStore features that promise to combine the best of both.
Getting SingleStore for free, while they grow their SaaS business, is crucial to Katomi’s success. As they hit their business milestones in SaaS, they expect to move to a paid subscription.
Katomi runs SingleStore in Google Cloud Platform, using three VMs. They collect millions of rows of data a day into tables with tens of millions of rows in rowstore, using several tens of gigabytes of memory, and more than a billion rows in columnstore, consuming disk storage of an additional tens of gigabytes.
Katomi describes SingleStore’s stability as “impressive.” According to Skovvang, “What usually worries me most about managing databases? Two things: backups and crash recovery.” With other databases, crashes required involving the vendor’s support team, costing Katoni hours of downtime. With SingleStore, the recovery process is almost fully automatic; they never need to involve support.
Katomi does have a short wishlist for SingleStore. The interpret_first feature, which was offered as an option in SingleStore DB 6.7, then turned on by default in SingleStore DB 6.8, met one wish. Katomi are also looking for a native UUID data type, unique indexes in columnstore, and enhanced support for foreign keys.
Schema design options will open up if SingleStore can shard on non-PRIMARY keys. Enhanced multi-language support for certain full text indexes will help as well. Most of the features Katoni is looking for are either already planned, or under active discussion for SingleStore’s development road map.