SingleStore 9 vs. Previous Versions: A Practical Guide to the Real-Time, Hybrid Database

Modern applications increasingly need to process transactions, analyze fresh data, search text and vectors, and support AI workloads—often at the same time. Traditionally, organizations solved these requirements with several specialized systems: an operational database, a data warehouse, a search engine, a streaming layer, and sometimes a separate vector database.

SingleStore takes a different approach. It is a distributed SQL database designed to serve transactional and analytical workloads on the same data platform. With SingleStore 9, the product continues its evolution from a fast HTAP database into a broader real-time data platform for operational applications, analytics, search, and AI.

This article explains what SingleStore is, why it is described as hybrid, where it can run, which workloads it supports, and how version 9 compares with the important 8.x releases that came before it.

What Is SingleStore?

SingleStore is a distributed, relational, multi-model SQL database built for applications that require high-speed ingestion, low-latency queries, high concurrency, and horizontal scalability.

It supports familiar SQL and uses a distributed architecture composed of aggregator and leaf nodes. Aggregators receive SQL requests, create distributed query plans, and coordinate execution. Leaf nodes store partitions of the data and perform most of the distributed processing. As capacity or workload grows, the cluster can scale horizontally by adding nodes.

SingleStore also offers native Pipelines for continuously ingesting data from streaming and object-storage sources. This makes it suitable for systems where data must become queryable shortly after it is produced.

Common use cases include:

• Real-time operational dashboards
• Financial-market and risk analytics
• Customer-facing analytics embedded in SaaS applications
• Fraud detection and security monitoring
• IoT and telemetry analysis
• Personalization and recommendation systems
• Full-text, vector, and hybrid search
• Retrieval-augmented generation and other AI applications
• High-volume data ingestion from Kafka and object storage

Why Is SingleStore a Hybrid Database?

The word hybrid can describe two important aspects of SingleStore.

1. Hybrid transactional and analytical processing

SingleStore is an HTAP—Hybrid Transactional and Analytical Processing—database. It can run operational transactions and analytical queries on the same current dataset. An application can insert or update records while dashboards, APIs, or analytical models query that data without first moving it into a separate warehouse.

This architecture can reduce ETL complexity, duplicate storage, and the delay between an event occurring and becoming visible to users. It does not mean that every organization should remove its data warehouse; instead, it means that workloads requiring immediate decisions can operate directly on live data.

2. Hybrid storage

SingleStore combines in-memory rowstore and disk-based columnstore technologies. Its Universal Storage extends columnstore tables with capabilities such as hash indexes, row-level locking, and efficient point access, allowing a columnstore to support workloads that would traditionally require a rowstore.

In practical terms:

• Rowstore is useful for highly selective, latency-sensitive transactional operations.
• Columnstore is efficient for compression, large scans, aggregations, and storing large datasets economically.
• Universal Storage brings more transactional behavior to columnstore tables, helping one table serve mixed operational and analytical access patterns.

This combination is the technical foundation of SingleStore's HTAP model.

Where Can SingleStore Run?

SingleStore can be consumed as a managed cloud service or deployed in a self-managed environment.

Deployment model	Where it runs	Best suited for
SingleStore Helios	AWS, Microsoft Azure, and Google Cloud	Teams that want a managed service with less operational overhead
Self-managed	Supported 64-bit Linux environments on physical servers, virtual machines, or cloud instances	Organizations requiring infrastructure control, private networking, or on-premises deployment
Kubernetes	Kubernetes environments using the SingleStore Kubernetes Operator	Teams standardizing deployment and lifecycle management on Kubernetes

For new self-managed 9.0 deployments, the official requirements list 64-bit RHEL or AlmaLinux 7 or later, or Debian 8 or later, with Linux kernel 3.10 or later and glibc 2.17 or later. Exact certified configurations should always be checked before production deployment.

From an application perspective, SingleStore's MySQL wire-protocol compatibility allows many existing MySQL clients, drivers, SQL tools, BI products, and development frameworks to connect to it. Compatibility should not be interpreted as identical behavior to MySQL in every feature, however, so application-specific SQL and driver behavior must be tested during migration.

The Evolution from SingleStore 8.x to 9.0

SingleStore 9 is easier to understand when viewed as the next step in a sequence of releases rather than as an isolated upgrade.

Version	Main direction	Representative capabilities
8.5	Vector search and workload control	ANN vector indexes, query-plan pinning, extensions, query history and trace events, improved resource-pool memory controls
8.7	Better AI search, ingestion, and adaptive optimization	Vector range search, enhanced full-text search, schema and pipeline inference, Apache Iceberg ingestion, feedback reoptimization
8.9	More mature search, lakehouse connectivity, and resilience	Custom analyzers and tokenizers, enhanced BM25 and global scoring, continuous Iceberg ingestion, additional Iceberg catalogs, enhanced disk spilling, writable views
9.0	Operational maturity and performance for mixed workloads	Sequences, automatic feedback reoptimization, multi-value JSON indexes, enhanced query history, distributed plan cache preview, pipeline and memory-management improvements

The important story is continuity. The 8.x releases added the building blocks for vector search, full-text search, adaptive optimization, and open-table ingestion. Version 9.0 consolidates and operationalizes those capabilities while improving performance and observability for demanding production workloads.

What Is New in SingleStore 9?

Sequences for more predictable generated identifiers

SingleStore 9 adds a `SEQUENCE` modifier for `AUTO_INCREMENT`. It generates unique numeric values while reducing the gaps that can occur in distributed identifier generation. It also allows other integer types and custom starting values.

This is especially useful for applications that want database-generated identifiers with more predictable ordering while preserving uniqueness across a distributed system.

Automatic query reoptimization using runtime feedback

Feedback Reoptimization first appeared in the 8.x line and becomes a headline capability in 9.0. Instead of relying only on estimated statistics, the optimizer can learn from previous executions and generate a better plan using observed runtime behavior.

This matters when estimates do not accurately represent real production data—for example, when distributions are skewed or filters are correlated. Repeated analytical queries can benefit without requiring developers to continually tune them by hand.

Multi-value indexes for JSON arrays

SingleStore 9 introduces a multi-value hash index for values inside JSON arrays. According to SingleStore's release documentation, it can provide up to 100-times faster analytics for relevant JSON-array queries by avoiding full collection scans, particularly for `JSON_MATCH_ANY` access patterns.

This is valuable for event data, product attributes, security records, user preferences, and other semi-structured datasets containing arrays. As always, the actual improvement depends on the schema, data distribution, query, and hardware, so the vendor figure should be validated with a representative benchmark.

Enhanced query history and observability

Version 9.0 expands Query History with high-frequency event tracing and additional measurements, including CPU, disk, network, and lock timing. These details help teams identify expensive or failed queries and understand where execution time is being spent.

The release also adds more pipeline profiling, activity tracking, workload-memory estimation, and visibility into the distributed plan cache. For database teams, these features may be as important as raw query speed because they shorten diagnosis and tuning cycles.

Distributed Plan Cache—preview

SingleStore already had in-memory and persistent on-disk plan caches. The Distributed Plan Cache preview adds a cluster-wide layer through which nodes can share compiled plans. A newly added node can therefore begin with a warmer cache, and plans compiled on one aggregator can be synchronized with other aggregators.

The expected benefit is less repeated compilation, lower CPU use, and steadier performance following scaling or rebalancing. Because the feature is identified as a preview in the 9.0 release documentation, it should be evaluated carefully before relying on it for critical production behavior.

Better pipelines, Iceberg integration, and memory efficiency

SingleStore 9 adds pipeline profiling, Parquet inference, automatic Iceberg schema inference, CSV header-detection control, and improved retry behavior. It also introduces a join memory-reduction optimization that can divide qualifying large hash joins into more manageable pieces, reducing memory pressure and the risk of spills or out-of-memory errors.

These are practical improvements for data platforms that continuously ingest large volumes and execute complex joins under constrained resources.

A new default collation for new clusters

New 9.0 clusters use `utf8mb4_bin` as the default collation instead of `utf8mb4_general_ci`. Binary collation can improve string-comparison performance but is case-sensitive, so `Product`, `product`, and `PRODUCT` may compare differently.

Existing upgraded clusters retain their current collation. Even so, teams creating a new 9.0 environment should test sorting, equality comparisons, joins, uniqueness rules, and application search behavior before migration.

SingleStore 9 Compared with 8.9

For organizations already on 8.9, the difference is not that 9.0 suddenly adds every modern capability. Version 8.9 already provides advanced full-text search, improved BM25 scoring, continuous Apache Iceberg ingestion, broader catalog support, writable views, vector-index improvements, and enhanced disk spilling.

Version 9.0 builds on that base with stronger operational intelligence and more targeted performance improvements:

• Runtime feedback is used more directly to improve recurring query plans.
• JSON arrays become much more practical to search at scale through multi-value indexes.
• Query history exposes richer information for performance troubleshooting.
• Plan compilation can be shared across nodes through the preview Distributed Plan Cache.
• Pipeline inspection and schema inference cover additional formats and sources.
• Large joins gain an optimization intended to reduce memory pressure.

In short, 8.9 expanded the database's search and lakehouse capabilities, while 9.0 focuses more heavily on making complex, mixed workloads easier to operate and optimize.

Who Should Consider Upgrading?

SingleStore 9 is particularly relevant when an organization:

• Runs recurring queries whose plans are sensitive to inaccurate estimates
• Stores and searches arrays inside JSON documents
• Needs deeper query, pipeline, CPU, disk, network, or lock diagnostics
• Regularly scales or rebalances clusters and wants to reduce plan warm-up costs
• Uses pipelines with Parquet, CSV, or Iceberg sources
• Experiences memory pressure during large hash joins
• Wants more flexible, database-generated sequential identifiers

An upgrade should still be treated as an engineering project. Review deprecated and preview features, validate client and SQL compatibility, test new-cluster collation behavior, reproduce critical workloads with production-like data, and confirm backup and rollback procedures. Do not rely on headline benchmark numbers without measuring the actual workload.

Final Thoughts

SingleStore's central value proposition remains straightforward: transact on data, ingest streams, and analyze current and historical information through one distributed SQL engine.

The 8.x releases broadened the platform with vector indexing, full-text search, adaptive optimization, schema inference, and Apache Iceberg integration. SingleStore 9 turns that foundation into a more operationally mature platform through runtime-informed optimization, faster JSON-array access, richer diagnostics, improved pipeline tooling, and more efficient plan and memory management.

That makes version 9 less of a complete reinvention and more of a production-focused milestone. For organizations building real-time analytics, intelligent applications, fraud or risk systems, customer-facing dashboards, and hybrid search experiences, it offers a compelling combination: transactional freshness, analytical power, and AI-oriented data access without requiring a separate database for every workload.

Official Sources

• SingleStore 9.0 release notes
• SingleStore 8.9 release notes
• SingleStore 8.7 release notes
• SingleStore 8.5 release notes
• SingleStore Helios documentation
• How SingleStore works
• Universal Storage