![[SingleStore Guide #1] Transactions and Analytics: Why Handle Both in One DB?](https://www.notion.so/image/attachment%3A3f487306-deab-47b0-b7c3-0e4b9921f204%3Acover.jpg?table=block&id=40c486ec-f74a-4dd2-9085-12787976883b&cache=v2&width=1200)
Why SingleStore doesn't keep a separate analytics DB
At SingleStore AI NOW 2026, held in Seoul in July 2026, Korean companies shared how they use SingleStore. K Bank presented an AI fraud detection system (FDS) that analyzes transaction data within a few milliseconds, and Kakao showed a hybrid search that combines keyword search and vector search in a single SQL query. Both workloads must return results the moment a request comes in, and both companies built them on SingleStore.
Adoption is growing, but it is still hard to pin down what kind of database SingleStore actually is. Search results mix in material from its MemSQL days, and the description from a 2020 Korean news article, "a database that uses both memory and disk," is still around. That description isn't wrong, but the default table type today is different from what it was then.
The short answer: SingleStore is a distributed SQL database designed to handle transaction processing (OLTP) and analytics (OLAP) in one engine. It splits work across multiple nodes, and it extended its columnstore, originally built for analytics, to handle transaction processing as well.
1. Why transaction processing and analytics have been kept apart
Transaction processing (OLTP) and analytics (OLAP) differ sharply in how they access data and use resources, so it has been hard for one system to deliver good performance on both.
OLTP covers short, frequent operations such as orders, payments, and sign-ups. To process a single order, the system checks the customer and stock, inserts the order record, and updates the stock count. If anything fails midway, all changes must be rolled back together so that no partial change remains. Because these requests arrive nonstop, what matters is not only finding the target row quickly but also short response times and high concurrency.
Summing last quarter's revenue by region, on the other hand, is OLAP. If you compute it from raw data, you read only the columns you need, such as date, region, and amount, across a huge number of orders in that period and add them up. Performance depends less on how fast you find one row and more on how fast you can read and aggregate a wide range of data.
OLTP stands for Online Transaction Processing and OLAP for Online Analytical Processing. The terms describe the nature of the work a database is handling.
According to the SingleStore documentation, the two workloads also favor different storage layouts. Row storage (rowstore) keeps the values of a row close together, which suits looking up and updating specific rows, but when you aggregate a few columns across many rows you end up reading values you don't need. Column storage (columnstore) groups values of the same column together, so you can read just the columns you need sequentially and compress them well. That makes it good for large aggregations, but frequent small updates need extra handling (the row to change is marked as deleted and a new row is written separately).
So a common setup has been to record transaction data in an operational DB, then move it into a data warehouse for aggregation. The data moves through ETL or CDC pipelines.
ETL (Extract, Transform, Load) is the process of extracting, transforming, and loading data. CDC (Change Data Capture) captures changes in the source DB and delivers them to another system in near real time.
This setup is still useful, but moving data around creates two costs.
First, data reaches analytics late. With a batch job that loads once a day, a screen viewed in the afternoon may still show the previous day's data. That delay is acceptable for a monthly report, but work that must detect anomalies before approving a transaction needs a faster path. Sending changes in near real time with CDC cuts the delay to seconds, but the pipeline gets more complex and harder to maintain.
Second, the pipeline has to be run continuously. Every time the source schema changes, you have to review the load settings and transformation rules, and when the operational DB and the data warehouse show different numbers, you have to trace whether the cause is load delay or a transformation rule. Either way, the same data is stored in two places.
The industry makes the same diagnosis. At the same event, Jeonghee Han, CEO of SingleStore Korea, pointed out that architectures combining several databases develop bottlenecks as data movement such as ETL and CDC repeats.
2. Not splitting them: HTAP
When the operational DB and the analytics DB are separate, you need a step that moves data between them. If you analyze data right where it was written, in the same database, you can cut that step and make decisions on the latest data. According to the SingleStore blog, the IT research firm Gartner called this approach of handling transactions and analytics together in one system HTAP (Hybrid Transaction/Analytical Processing).
But being able to run both workloads in one DB is not the same as running both efficiently. Short, frequent transaction requests and analytical queries that read lots of data compete for the same resources. So storage structure, indexes, and query execution have to be designed together, and each HTAP product solves this differently. Logs, external APIs, and data from other systems still have to be loaded. What HTAP can reduce is re-moving data that is already in the same DB just for analytics.
SingleStore's product history shows how it has tackled the problem of two workloads competing for the same resources. It started in 2011 as an in-memory rowstore database called MemSQL, then added a disk-based columnstore and analytics features. When the company was renamed in October 2020, its official blog explained that "SingleStore" was originally the name of an internal project. The project aimed to move away from choosing between two table types and handle both transactions and analytics with a single table type.
The result of that project is today's "Universal Storage." The rowstore stayed as it was, and the columnstore was developed to take on both workloads.
Describing today's SingleStore as an in-memory database is inaccurate. The default table type is Universal Storage, a disk-based columnstore, and the in-memory rowstore is specified only for the tables that need it.
3. How SingleStore handles transactions and analytics together
So how does SingleStore handle both workloads efficiently in one engine? It stores data across multiple nodes and runs queries in parallel, and it extended the storage layout so the columnstore, originally for analytics, also handles point lookups and updates. Instead of building a new access method, it supports the MySQL wire protocol so existing tools keep working.
3-1. Splitting nodes: distributing storage and compute across nodes
As transaction requests grow or the data to analyze increases, you need both more storage and more compute. SingleStore splits this work by organizing a cluster into two roles: aggregators and leaves.
① Aggregator
An aggregator receives client queries, passes them to the leaves, and gathers the results to respond. There is only one master aggregator per cluster, which coordinates state management, failover, and DDL operations; when query and connection load grows, you add child aggregators. The documentation recommends that, in a configuration with a redundant master, applications connect to a load balancer in front of the child aggregators; administrative operations such as DDL are then forwarded by a child to the master.
② Leaf
Leaves store data and perform query computation. Tables are split into pieces called partitions and spread across leaves, with each leaf holding several partitions. Which partition a row goes to is decided by a reference column called the shard key. Analytical queries that read a wide range run in parallel across many partitions, while lookups that target rows by shard key value can finish in a single partition.
With this split, as data and throughput grow you can add leaves to scale capacity and performance together, but this only works when the shard key distributes data evenly.
3-2. Merging storage: extending the columnstore to transaction processing
Adding nodes alone does not make both point lookups/updates and large aggregations efficient. In early SingleStore, you chose an in-memory rowstore or a disk-based columnstore depending on what a table was for. Orders went in a rowstore, and history for aggregation went in a columnstore.
Universal Storage, the current default table type, is an evolution of the columnstore. According to the documentation, it keeps the aggregation benefits of columnar storage while adding hash indexes, subsegment access, row-level locking, upserts, and more, so it also supports finding and changing specific rows.
Small writes are not written directly into compressed column chunks. They are first received into an in-memory rowstore segment, and once enough accumulates, they are compressed in the background and flushed to disk segments. Because this buffer absorbs the frequent small updates that columnar storage handles poorly, a single columnstore table can serve both transaction processing and analytical queries.
The 2020 article's description of using memory and disk together still fits this structure. SingleStore recommends this table type for all kinds of workloads, and it is the default in clusters created on version 7.3 or later.
The in-memory rowstore is still available. For workloads with very frequent updates and deletes, or where millisecond response is the top priority, a rowstore may fit better, but you have to account for the cost of keeping table data in memory. So when creating tables, use Universal Storage by default and choose rowstore based on the workload.
3-3. Keeping the access method: connecting existing tools
The storage layout changed, but the access method stayed the same. SingleStore supports the MySQL wire protocol, so you can connect with MySQL drivers and many tools. Connection compatibility, however, does not guarantee every MySQL syntax and behavior. For example, foreign key constraints and triggers are not supported, so you need to review schemas and queries when migrating an existing application.
SingleStore Kai, for MongoDB clients, became generally available in January 2024. It is offered as a separate endpoint in Helios, SingleStore's managed cloud service. According to the documentation, though, Kai is currently in maintenance mode for existing customers and is not recommended for new workloads.
4. What Korean companies use SingleStore for
The Korean presentations at SingleStore AI NOW 2026 show that SingleStore plays a different role in each workload.
Workload | What SingleStore handles | Presenter |
Real-time AI fraud detection (FDS) | Transaction records and detection within a few milliseconds, plus fraudulent account detection using vector search | K Bank |
Hybrid search | A single SQL query that combines keyword search and vector search with rank fusion (RRF) | Kakao |
Ad analytics platform | Ad analytics based on real-time video understanding, cutting AI analysis response time from several minutes to 1~2 seconds | PYLER |
On-premises AI platform | Proposed platform architecture including SingleStore (Sovereign AI) | Hyosung Information Systems |
Of these, K Bank is the case closest to an HTAP setup that handles transactions and analytics together in one engine. Fraud detection must finish before a transaction is approved, so there is no time to move incoming transaction data into a separate analytics system. K Bank said it built AI fraud detection that analyzes transaction data within a few milliseconds on SingleStore.
Kakao's case combines keyword search and vector search in one query, and PYLER's case is about cutting AI analysis response time. PYLER said that after adopting SingleStore, analysis response time dropped from several minutes to 1~2 seconds and operating costs fell by about 70%. These are figures PYLER reported in its presentation, so you cannot assume the same results in other environments.
Hyosung Information Systems' presentation is different in nature. The company is a vendor that presented an on-premises AI platform architecture including SingleStore. From the public presentations alone, you cannot conclude that any of these organizations merged their existing transaction and analytics DBs or eliminated a data movement step. When evaluating adoption, you need to check what data will be stored in SingleStore and through which paths data comes in from external systems.
When the SingleStore blog announced an exclusive partnership with Agile Platform for the Korean market in April 2024, it named Kakao, POSCO, LG Innotek, K Bank, Kiwoom Securities, and SK Telecom as customers in Korea.
SingleStore's AI features have also expanded, including the vector search seen in the K Bank and Kakao cases. At first only exact search, comparing vectors one by one, was available, but index-based search was added in January 2024, making it fast even on large datasets. In October 2025, AI·ML Functions, which call LLMs from SQL, and Aura Analyst, which takes natural-language queries, were added. At the Seoul event in July 2026, Aura AI, which supports AI agent development, was unveiled.
K Bank, Kakao, and PYLER all used SingleStore for work that needs real-time responses. Conversely, monthly aggregation can tolerate batch delay, so there is little reason to merge it into one engine.
5. What you need to watch for in a distributed cluster
To take real-time load in one engine, SingleStore stores data across multiple nodes. That creates problems you won't see by looking at a single node.
① Nodes look healthy, but only service response is slow
Sometimes CPU and memory across the leaves are within normal range on the cluster average, yet service responses are slow. When data concentrates in certain partitions, the leaf holding them becomes the bottleneck, but averages hide this difference. This imbalance is called skew. As a rule of thumb, the documentation says skew of less than 10% across partitions usually has little impact on performance. Skew is calculated as the relative standard deviation of row counts and memory usage per partition, and a poorly chosen shard key drives it up.
② Only one node hits its memory limit first
In on-premises clusters, the memory limit tables can use (maximum_table_memory) is set per node. As in the figure above, if data concentrates on one leaf or a particular leaf's setting is low, that leaf hits the limit before the other nodes. Once it does, reads and deletes still go through, but inserts (INSERT), updates (UPDATE), and table or index changes are rejected with errors. Writes look blocked even though disk space remains, and the cause is hard to find unless you compare settings and usage on each leaf.
③ Delays that don't show in node status
When you replicate data to another cluster for disaster recovery (DR), replication can fall behind while every node shows as online. Online only means the node is alive; it doesn't tell you how far replication has progressed. That is why the documentation says to check replication progress in a separate status view, using lag and estimated catch-up time. The same goes for loading from Kafka or external storage through pipelines: if you don't watch ingest progress separately, you may only find out after the service team asks why the data is stale.
All 3 problems only show up when you compare per-node numbers side by side. Skew or a setting difference on one node can also surface as a different symptom. Which metrics to watch depends on the paths through which the service writes and reads data.
6. What the decision to use one DB changes
Handling transactions and analytics in one database means fewer ETL pipelines, but the node layout and table types change, and the same metrics have to be read by comparing them across nodes. This approach fits work that needs real-time responses.
Because one cluster handles many kinds of work, operations need to watch data distribution per partition, resource usage per leaf, and data freshness lag together. Being able to connect with a MySQL driver does not mean every SQL feature is the same. The query plan also shows whether a query finishes in one partition, reads multiple partitions, or moves data between nodes.
SingleStore doesn't keep a separate analytics DB because some workloads can no longer tolerate the delay of moving data, and the columnstore can now handle transaction processing too.
Sources
SingleStore unveils "Aura AI" for the AI agent era - Electronic Times (2026.07.08) "Better Context, Better AI": SingleStore unveils a data platform for the AI agent era - TechDaily (2026.07.07) MemSQL renames itself SingleStore - ZDNet Korea (2020.11.11) MemSQL is Now SingleStore - SingleStore (2020.10.21) SingleStore Announces Exclusive Partnership with Agile Platform to Develop the Korea Market - SingleStore (2024.04.16) SingleStore Announces Real-Time Data Platform to Further Accelerate AI, Analytics and Application Development - SingleStore (2024.01.24) SingleStore Drops Three Major Upgrades to Power the Next Decade of AI Applications - SingleStore (2025.10.01) SingleStore Documentation - SingleStore Docs: Choosing a Table Storage Type, Writing Columnstore Data, Cluster Components, Master Aggregator Redundancy, Universal Storage, Creating a Columnstore Table, Unsupported MySQL Features, SingleStore Kai, Detecting and Resolving Data Skew, maximum_table_memory, Monitoring Replication, PIPELINES, Query Plan Operations
Related articles
