# Choose between Map fields and typed columns

A `Map` is useful for a variable collection of keys. Frequently filtered business fields often deserve dedicated typed columns so their meaning and validation are explicit. Compare both representations with your actual queries before changing a schema.

## Preserve Map semantics

Map keys can repeat and their order is retained. `map_element` returns the first matching value; a missing key returns the value type's default. Use `map_contains` when zero or an empty string could also be a real stored value.

```sql
SELECT id, map_element(counters, 'views') AS views
FROM pages
WHERE map_contains(counters, 'views')
FORMAT csv;
```

## Move a hot field carefully

Create a replacement table with an explicit column for the commonly queried value. Backfill it with `INSERT ... SELECT`, validate row counts and compare representative values. Decide how missing keys and duplicate keys should map to the new column before migrating; this is a data-contract decision.

Measure the actual query plan, elapsed time and memory after the change. Coordinator DB does not provide a Map-specific optimization switch or promise that one representation is always faster.

See [Map](https://coordinatordb.com/docs/reference/data-types/map), [map functions](https://coordinatordb.com/docs/reference/functions/regular-functions/tuple-map-functions) and [schema changes](https://coordinatordb.com/docs/reference/statements/alter/column).