# Choose compute for a query

Without per-query sizing, every statement can run on the same compute profile—whether it scans ten rows or ten billion.

Pass `"compute_size": "AUTO"` (the default in SQL Explorer) and Altertable picks a size **per query** from the SQL itself. A narrow `LIMIT 100` over a large table can run on `XS`; a full-table aggregate may need `XL`.

```json
{
  "statement": "SELECT id, email FROM users WHERE created_at > now() - interval '7 days' LIMIT 100",
  "compute_size": "AUTO"
}
```

## How `AUTO` works

Before execution, Altertable runs `EXPLAIN` on the statement and walks the physical plan to estimate how much parallelism the query needs. It then selects the smallest tier that fits:

| Size  | Threads | Typical fit                                            |
| ----- | ------- | ------------------------------------------------------ |
| `XS`  | 2       | Point lookups, small scans, queries with early `LIMIT` |
| `S`   | 4       | Moderate scans                                         |
| `M`   | 8       | Larger scans or joins                                  |
| `L`   | 16      | Heavy joins or aggregations                            |
| `XL`  | 32      | Full-table scans and large shuffles                    |
| `2XL` | 64      | Large parallel workloads                               |
| `3XL` | 96      | Large parallel workloads                               |
| `4XL` | 128     | Large parallel workloads                               |

**Constraints:**

- `AUTO` cannot be combined with an explicit `session_id`. Reuse sessions when you need temporary state; pick a fixed size when you need both session reuse and predictable compute.

Requested sizes cannot exceed the environment’s provider maximum. Actual allocation can be lower when compute allowances are constrained.

## Fixed sizes

Override inference when you know the workload or need repeatable performance:

```json
{
  "statement": "SELECT ...",
  "compute_size": "M"
}
```

Use a fixed tier for long-running batch jobs, dashboards that should always warm the same worker profile, or queries where you have already benchmarked the right size.