---
title: "The cluster underneath (DASE)"
slug: "dev-database-concepts-architecture-cluster-architecture"
description: "Explore VAST's disaggregated architecture, enabling seamless scaling, efficient data management, and robust durability without complex configurations."
updated: 2026-10-30T18:19:01Z
published: 2026-10-30T18:19:01Z
canonical: "docs.vastdata.com/dev-database-concepts-architecture-cluster-architecture"
---

> ## Documentation Index
> Fetch the complete documentation index at: https://docs.vastdata.com/llms.txt
> Use this file to discover all available pages before exploring further.

# The cluster underneath (DASE)

*Applies to VAST Cluster 5.5.*

Every VAST data service runs on the same VAST cluster and keeps its data in one store, the **Element Store**. The cluster is built on what VAST calls the **disaggregated, shared-everything (DASE)** architecture ([VAST Database overview](/docs-5-5/docs/vast-database-overview)). You don't configure any of this, but it explains behaviour you'll see: why files, objects and tables share permissions and snapshots, why tables never need re-sharding, why any endpoint can serve any request, and why there are no replicas to manage.

![The DASE layout. Clients connect to virtual IPs. Each virtual IP is held by a CNode, and a virtual IP moves to another CNode if its CNode goes offline. Every CNode reaches every SSD in every storage enclosure over an NVMe fabric. Each storage enclosure (DBox) holds storage-class memory, used as the write buffer and for metadata, and flash SSDs for long-term data. CNodes add compute; DBoxes add capacity; you scale them separately.](https://cdn.us.document360.io/89b91113-5dc6-49db-86ec-57b16dc8ce56/Images/Documentation/dase-cluster.svg?sv=2026-02-06&spr=https&st=2026-11-08T08%3A55%3A43Z&se=2026-11-08T09%3A55%3A43Z&sr=c&sp=r&sig=G8R4KhhOOswly%2FLyQ2YjQp2Jx%2FR9LScMpXjABAdolI4%3D)

*Any CNode can reach any data, so compute and capacity scale separately.*

## One Element Store

This is background. You don't need to know about the Element Store to use any VAST service: you work through the service's own API, and each section tells you what to do. It explains three things you'll notice: the same data can be a file, an object and a table row, with one set of permissions; snapshots, quotas and QoS apply across protocols; and data reduction works across the whole cluster.

If you design VAST DataBase tables, one part of this does matter: how a table is laid out inside the Element Store decides how much data a query reads. Each column is stored separately, so a query reads only the columns it uses; and each small chunk of a column keeps its minimum and maximum, so a filter skips the chunks that can't match, as long as matching values sit together, for example because the table is sorted on that column. That's covered in [how tables are stored](/develop/docs/dev-database-concepts-architecture-element-store-layout), [read path and pruning](/develop/docs/dev-database-concepts-architecture-read-path-and-pruning) and [data modeling](/develop/docs/dev-database-guides-data-modeling).

A VAST cluster doesn't store your data in a file system or in an object store underneath, but in its own namespace, the Element Store. Files and S3 objects are elements in it, and the same element can be both a file and an object. Tables are elements too ([Overview of Multi-Protocol Storage Access](/docs-5-5/docs/overview-of-multi-protocol-storage-access)). Each tenant has its own part of the namespace, and a **view** exposes one path in it to clients over one or more protocols.

Each data service is a way of working with the same elements:

| Service | What it is in the Element Store |
| --- | --- |
| [VAST DataStore](/develop/docs/dev-datastore-overview) | Files and objects, exposed by views as NFS exports, SMB shares and S3 buckets. |
| [VAST DataBase](/develop/docs/dev-database-overview) | A database is a bucket on a view with the Database protocol. A schema is stored like a directory and a table like a file. See [concepts](/develop/docs/dev-database-concepts-index#databases-schemas-and-tables). |
| [VAST Event Broker](/develop/docs/dev-event-broker-overview) | A Kafka view creates a database, and each topic is a table in it, which you can also query with SQL ([KB](/docs-5-5/docs/publishing-events-to-vast-event-broker)). |
| [VAST Catalog](/develop/docs/dev-catalog-overview) | A table that indexes the elements' metadata, rebuilt from periodic snapshots of the Element Store ([KB](/docs-5-5/docs/configuring-vast-catalog)). |
| [VAST DataEngine](/develop/docs/dev-dataengine-overview) | An element trigger watches a view and sends an event when an element is created or deleted, or when an object's tags change ([KB](/docs-5-5/docs/creating-a-trigger)). |

Because it's one store, the cluster's data services work the same way whatever the protocol:

- **Permissions** are stored in one protocol-independent form and checked for every protocol; the view's security flavor decides whose rules apply ([DataStore concepts](/develop/docs/dev-datastore-concepts-index#what-decides-whether-a-request-is-allowed)).
- **Snapshots** cover a path, with the files, objects and tables under it, at one point in time. A snapshot copies nothing: it holds on to data that would otherwise be released when it's deleted or overwritten ([Snapshots](/docs-5-5/docs/snapshots)).
- **Quotas and quality of service** are set on directories, views and users, and count all the protocols that write there ([DataStore concepts](/develop/docs/dev-datastore-concepts-index#quotas-and-quality-of-service)).
- **Data reduction** is cluster-wide (below).

## The two halves

| Part | What it is | What it holds |
| --- | --- | --- |
| **CNodes** (compute) | Servers that run the cluster's protocols and database logic: S3, the VAST DataBase API, the VAST Query Engine, the Kafka protocol and the rest. | No data of their own. A CNode doesn't cache writes or metadata, in memory or anywhere else ([whitepaper](https://www.vastdata.com/whitepaper)). |
| **DBoxes** (storage enclosures) | NVMe storage shelves. Each has redundant controllers (DNodes) that run active-active. | Storage-class memory (SCM), used as the **write buffer** and for the cluster's metadata, and **flash** SSDs for long-term data ([whitepaper](https://www.vastdata.com/whitepaper); [write buffers](/docs-5-5/docs/write-buffers-on-vast-clusters)). |

Some clusters use EBoxes, which combine both roles in one box. The model is the same.

## Shared everything

**Every CNode reaches every SSD in the cluster** over an NVMe fabric, and the cluster's metadata lives on that shared storage, not on any one CNode. Each CNode can carry a request through to completion without asking other CNodes, and because CNodes don't cache, there's no cache to keep consistent between them ([whitepaper](https://www.vastdata.com/whitepaper)).

For you, that means:

- **Any endpoint can serve any request.** You connect to virtual IPs, not to a server that owns your data. A virtual IP is held by one CNode at a time, and it moves to another CNode if that CNode goes offline, for an upgrade or a failure, without affecting clients ([KB](https://kb.vastdata.com/docs/best-practice-on-load-balancing-cnodes)).
- **Nothing is partitioned by server.** A table isn't split into shards owned by particular servers, so there's nothing to re-shard as data grows ([VAST Database overview](/docs-5-5/docs/vast-database-overview)).
- **Compute and capacity scale separately.** More CNodes add processing; more DBoxes add capacity ([whitepaper](https://www.vastdata.com/whitepaper)).

## Writes and durability

A write lands first in the **write buffer**, on storage-class memory, and background work moves it to flash later. VAST DataBase rows follow this path; see [write path](/develop/docs/dev-database-concepts-architecture-write-path). Data is protected by erasure coding across many SSDs, including data that's still in the write buffer ([whitepaper](https://www.vastdata.com/whitepaper)). There are no copies of your data on several servers for you to manage: durability is a property of the storage, not of the protocol you use.

## Data reduction

The cluster reduces data after the write, not during it. A write lands in the write buffer synchronously, and the cluster reduces the data before moving it to flash ([Data reduction](/docs-5-5/docs/data-reduction)). So reduction doesn't add to the time a write takes.

The cluster first removes blocks it already stores (deduplication). For the rest, it uses compression or similarity-based reduction, which stores a block as its difference from a similar block the cluster already has, whichever saves more. Similarity works across the whole cluster, not per view or per bucket, so data that resembles other data anywhere on the cluster can benefit ([Similarity-based data reduction](/docs-5-5/docs/similarity-based-data-reduction)).

For you, that means:

- **Write data uncompressed and unencrypted if you want the cluster to save space.** Encrypted data hardly reduces, and data you've already compressed reduces much less ([whitepaper](https://www.vastdata.com/whitepaper)). For Kafka messages there's no choice: VAST Event Broker doesn't accept compressed batches ([Kafka compatibility](/develop/docs/dev-event-broker-reference-kafka-compatibility)).
- **Logical and usable capacity differ.** Logical capacity is what you wrote; usable capacity is what it takes after reduction. A quota can count either, and a quota on usable capacity can change when the cluster's reduction ratio changes, without any change to your data ([Overview of quotas](/docs-5-5/docs/overview-of-quotas)).

## Copies on other clusters

Erasure coding protects your data inside one cluster. Copies on **other** clusters, for disaster recovery or to read the data somewhere else, come from replication, which your platform team sets up per protected path ([Overview of VAST Replication](/docs-5-5/docs/overview-of-vast-replication)):

- **Asynchronous replication** is built on snapshots. On a schedule, the cluster takes a snapshot of the path and sends what changed since the last one to each destination cluster. A VAST database on the path is replicated this way, like files and buckets. On the destination it's a read-only image that holds only committed transactions, until a failover makes it writable.
- **Synchronous replication** copies every write to one other cluster as it happens, so a failover loses nothing. It's documented for S3 buckets; ask your platform team whether it covers your databases before you rely on it.

Snapshots themselves cost no copy: a snapshot holds on to data that would otherwise be released when rows are deleted or overwritten ([Snapshots](/docs-5-5/docs/snapshots)). Some table structures rule out replication: see [limits](/develop/docs/dev-database-reference-limits#combining-table-structures). How to read snapshots and replicas is in [snapshots and replication](/develop/docs/dev-database-operations-snapshots-and-replication).

## What it means for each product

| Product | Consequence | More |
| --- | --- | --- |
| VAST DataBase | A query is split into pieces that run on many CNodes at once, all reading the same table, and the requests of one transaction can go to different CNodes. Tables grow without re-sharding. | [Read path](/develop/docs/dev-database-concepts-architecture-read-path-and-pruning), [transactions](/develop/docs/dev-database-concepts-architecture-transactions) |
| VAST Vector Search | The vector index is part of the table, on the same shared storage, and the VAST Query Engine on its CNodes walks it. | [Vector Search architecture](/develop/docs/dev-vector-search-concepts-architecture) |
| VAST DataStore | Clients spread over many virtual IPs reach the same data through many CNodes, so throughput comes from many connections, not one. | [DataStore performance](/develop/docs/dev-datastore-guides-performance) |
| VAST Event Broker | Every virtual IP in a Kafka view's pool is a broker, and any CNode can read and write any partition. There are no follower replicas, and no partition data tied to a broker to move. | [Event Broker architecture](/develop/docs/dev-event-broker-concepts-architecture) |
| VAST Catalog | The Catalog is built from snapshots, so it shows the namespace as it was at the last snapshot, not live. | [Catalog concepts](/develop/docs/dev-catalog-concepts-index) |

## See also

- [How tables are stored](/develop/docs/dev-database-concepts-architecture-element-store-layout)
- [Write path](/develop/docs/dev-database-concepts-architecture-write-path)
- [VAST Database overview](/docs-5-5/docs/vast-database-overview)