# Storage and compute (/docs/concepts/storage-and-compute) Storage and compute [#storage-and-compute] Storage holds table data. Compute executes queries, accepts inserts, and does background work on that data. A cluster brings those resources together for its databases. Separate databases provide separate namespaces, but queries within a cluster still compete for its compute resources. RawTree manages table parts, query execution, replication, and background work. RawTree Cloud and RawTree BYOC provision and operate the infrastructure around those database mechanisms. SQL workloads share available resources, while service controls change capacity and cluster state. Tables consist of parts [#tables-consist-of-parts] A table is a logical collection of rows. The engine stores those rows in parts, which contain data, indexes, and metadata. Inserts create new parts. A query can read several parts to produce one result. RawTree reads selected columns and JSON paths instead of requiring every query to load the complete JSON object. The requested fields and filters therefore affect how much data a query reads. A logical table can have parts with different physical layouts. Automatic [sorting keys](/docs/concepts/sorting-keys) can differ between parts, and a new [projection](/docs/concepts/projections) might not yet exist in older parts. Merges and mutations [#merges-and-mutations] Background merges combine parts into new parts. They can reduce the number of parts and change their physical layout. RawTree can also select a new sorting key during a merge when automatic selection is enabled. A [mutation](/docs/concepts/mutations) applies a requested change to existing parts, such as materializing a projection. Merges and mutations consume compute and storage bandwidth alongside inserts and queries. These operations take time. A change to table metadata does not mean every existing part immediately uses the new layout. Querying the table and building its new physical structures are separate activities. Replicas and capacity [#replicas-and-capacity] A replica is a database server instance within a cluster. Cluster configuration specifies the replica count and the CPU and memory available per replica. Those are separate capacity choices. Replication coordinates table data and changes across replicas. It does not make every operation finish everywhere at the same instant. Data availability, background work, and request outcomes need separate checks. Cluster size determines available compute. [Workload scheduling](/docs/concepts/workload-scheduling) determines how queries share server resources. It does not create extra capacity, and its CPU controls apply per server rather than as one cluster-wide budget. Object storage and ownership [#object-storage-and-ownership] RawTree Cloud supports managed storage and customer-owned S3 storage. A cluster can have separate data and backup destinations. A database can use its own configured destinations when the cluster supports the required storage access. Storage ownership and compute placement are separate choices. A customer-owned bucket does not mean the database servers run in that customer's cloud account. Storage credentials and permissions must allow the cluster to access its data. RawTree BYOC places the database infrastructure in the customer's cloud account. It is distinct from assigning customer-owned buckets to a RawTree Cloud cluster. See [Bring your own bucket](/docs/deployment/bring-your-own-bucket). The storage configuration alone does not establish a backup schedule or a recovery guarantee. Replication also does not replace a backup policy. Scaling and cluster lifecycle [#scaling-and-cluster-lifecycle] Autoscaling bounds define the permitted minimum and maximum replica size. Available sizes and replica limits come from the cluster size catalog. They can differ between environments. An idle timeout can pause a cluster after inactivity. An administrator can also pause and resume it. A paused cluster retains its data, but it cannot serve data requests. Cluster management remains available. A request to create or resume a cluster starts a lifecycle operation. Acceptance does not mean the database is ready. Cluster status and successful data requests establish readiness. Installing an app does not start or resume a cluster. Related [#related] * [Resource model](/docs/concepts/resource-model) * [Deployment](/docs/deployment) * [Cluster API](/docs/reference/api/clusters) * [Monitor usage](/docs/guides/operate/monitor-usage)