# Cluster Architecture

## Unique Design

SingleStore is a real-time hybrid transaction/analytics processing (HTAP) database designed with a distributed SQL architecture. This means that compute can be scaled out using a clustered architecture, rather than only scaling up using larger machines.

Clusters further enhance this distributed architecture by freeing databases from the confines of a single workload, delivering true separation of compute and storage.

## Cluster Architecture

Clusters are built using the native data replication engine. A collection of compute nodes are clustered on top of cloud hardware. These compute nodes have dedicated vCPU, memory, and persistent cache to deliver immediate query responsiveness, while operating on top of scale-out object storage.

Combined with SingleStore's query code generation and Universal Storage architecture, this allows clusters to deliver extremely low latency query response, highly concurrent access and fast parallel streaming ingest while removing the need to copy data across workloads.

## Implementation

Each cluster is fully isolated with its own compute, settings, and connection endpoints. Clusters can be deployed in any supported cloud provider and region, and can span multiple Availability Zones within a region for fault tolerance. A single organization can deploy many clusters across cloud providers and regions simultaneously.

Databases can be attached to multiple clusters simultaneously using “[smart attach](https://docs.singlestore.com/#section-id235740666346275.md)”. Each database can have one R/W attachment and many R/O attachments. This allows data to be shared across workloads, providing scalability and isolation.

![](https://cdn.sanity.io/images/h3bp8c98/production/488dc7d755f2580a54da10d8a2e0f7ac6424f735-1272x1110.png)

The R/W attachment writes logs/blobs to shared storage and sends logs to the R/O attached clusters asynchronously. The R/O attached clusters replay these logs, creating local blobs. For example, a customer-facing SaaS application could be running on one cluster and writing data into a database. An internal telemetry application could be running on another cluster and reading data from that same database. In this scenario, the database has an R/W attachment to the first cluster and a R/O attachment to the second.

Attachments are created on each database, and it is possible for a cluster to have a combination of R/W and R/O attachments.

Writes made to a database from a cluster with an R/W attachment will appear on clusters with R/O attachments almost instantaneously. The transaction log tail is sent to the replica and applied there asynchronously in real time. Thus, R/W-R/O sync is eventually made consistent.

All new writes to a database are typically replicated immediately, allowing clusters with R/O attachments to serve real-time workloads without waiting for data to load or going through complex ETL processes.

When sizing the cluster ensure that the selected size can accommodate the size of the working data set for that cluster's workload. A small cluster attaching a database with a large working set will not have sufficient resources to process the active data, which can cause cache misses and affect overall workload performance.

Use cases for read replicas include:

* Offloading analytical queries from a transactional workload
* Providing distributed read access
* Isolating reporting workloads from production ingest

Read replicas can be promoted to read/write in failover scenarios.

## Smart Attach

Smart Attach is the method by which databases can be attached to multiple clusters simultaneously in SingleStore Helios.

It is the underlying mechanism for the `READ ONLY` option in the [`ATTACH DATABASE`](https://docs.singlestore.com/cloud/reference/sql-reference/operational-commands/attach-database.md) command.

Key points:

* Each database can have one R/W (read-write) attachment and many R/O (read-only) attachments.
* This allows data to be shared across workloads, providing scalability and isolation.
* The R/W attachment writes logs/blobs to shared storage and sends logs to R/O attached clusters asynchronously.
* R/O attached clusters replay these logs, creating local blobs.
* It is a zero-copy approach, no full data copy is needed for read-only attachments.

Following is the syntax:

```sql
ATTACH DATABASE <database-name> READ ONLY;
```

## Limitations

* Cross-region read replicas require Database Replication and may have higher replication latency.
* Promoting a read-only replica to read/write will automatically detach the current writer.

***

Modified at: August 18, 2026

Source: [/cloud/getting-started-with-singlestore-helios/cluster-architecture/](https://docs.singlestore.com/cloud/getting-started-with-singlestore-helios/cluster-architecture/)

(An index of the documentation is available at /llms.txt)