1The Spice Runtime instances can be sharded based on specific criteria, such as by customer, state, or other logical partitions. Each shard operates independently, with a 1:N Application to Spice instances ratio.
2
3<img
4  width='740'
5  alt='sharded'
6  src='https://github.com/user-attachments/assets/5730d108-6d22-4ea4-8c14-8e87ad6d0079'
7/>
8
9**Benefits**
10
11- Helps distribute load across multiple instances, improving performance and scalability.
12- Isolates failures to specific shards, enhancing resiliency.
13- Allows tailored configurations and optimizations for different shards.
14
15**Considerations**
16
17- More complex deployment and management due to multiple instances.
18- Requires effective sharding strategy to balance load and avoid hotspots.
19- Potentially higher cost due to multiple instances.
20
21**Use This Approach When**
22
23- Distributing load across multiple instances for better performance is needed.
24- Isolating failures to specific shards to improve resiliency is desired.
25- The application can benefit from tailored configurations for different logical partitions.
26- The complexity of managing multiple instances can be handled.
27
28**Example Use Case**
29A multi-tenant application where each customer has a dedicated Spice Runtime instance. This helps ensure that heavy usage by one customer does not impact others, and allows for customer-specific optimizations.
30
31**Sharding vs. partitioning**
32
33Sharding splits load across **multiple Spice instances**, each backing a logical slice of the system (a customer, a region, a workload). Each shard runs an independent runtime with its own datasets, accelerations, and resources.
34
35Within a single Spice instance, [acceleration partitioning](../../features/data-acceleration/partitioning) splits a single dataset into multiple physical units (files, tables, or in-memory tables) so that filtered queries only read the relevant subset. The two are complementary: a shard can also use partitioning internally to keep individual datasets pruneable.
36
37| Concern                    | Sharded deployment                                       | Acceleration partitioning                                       |
38| -------------------------- | -------------------------------------------------------- | --------------------------------------------------------------- |
39| Splits across…             | Multiple runtimes/processes                               | One acceleration on one runtime                                 |
40| Routing                    | Application picks which Spice instance to query           | Spice prunes partitions automatically based on filter pushdown  |
41| Failure isolation          | Per-shard                                                 | None — single runtime                                           |
42| Use when                   | Tenants/regions have very different load or data volumes  | A single dataset is too large to scan whole on every query      |
43

1The Spice Runtime instances can be sharded based on specific criteria, such as by customer, state, or other logical partitions. Each shard operates independently, with a 1:N Application to Spice instances ratio.
2
3<img
4  width='740'
5  alt='sharded'
6  src='https://github.com/user-attachments/assets/5730d108-6d22-4ea4-8c14-8e87ad6d0079'
7/>
8
9**Benefits**
10
11- Helps distribute load across multiple instances, improving performance and scalability.
12- Isolates failures to specific shards, enhancing resiliency.
13- Allows tailored configurations and optimizations for different shards.
14
15**Considerations**
16
17- More complex deployment and management due to multiple instances.
18- Requires effective sharding strategy to balance load and avoid hotspots.
19- Potentially higher cost due to multiple instances.
20
21**Use This Approach When**
22
23- Distributing load across multiple instances for better performance is needed.
24- Isolating failures to specific shards to improve resiliency is desired.
25- The application can benefit from tailored configurations for different logical partitions.
26- The complexity of managing multiple instances can be handled.
27
28**Example Use Case**
29A multi-tenant application where each customer has a dedicated Spice Runtime instance. This helps ensure that heavy usage by one customer does not impact others, and allows for customer-specific optimizations.
30
31**Sharding vs. partitioning**
32
33Sharding splits load across **multiple Spice instances**, each backing a logical slice of the system (a customer, a region, a workload). Each shard runs an independent runtime with its own datasets, accelerations, and resources.
34
35Within a single Spice instance, [acceleration partitioning](../../features/data-acceleration/partitioning) splits a single dataset into multiple physical units (files, tables, or in-memory tables) so that filtered queries only read the relevant subset. The two are complementary: a shard can also use partitioning internally to keep individual datasets pruneable.
36
37| Concern                    | Sharded deployment                                       | Acceleration partitioning                                       |
38| -------------------------- | -------------------------------------------------------- | --------------------------------------------------------------- |
39| Splits across…             | Multiple runtimes/processes                               | One acceleration on one runtime                                 |
40| Routing                    | Application picks which Spice instance to query           | Spice prunes partitions automatically based on filter pushdown  |
41| Failure isolation          | Per-shard                                                 | None — single runtime                                           |
42| Use when                   | Tenants/regions have very different load or data volumes  | A single dataset is too large to scan whole on every query      |
43