# Choose SQL by the reader task

When evaluating Coordinator DB, start with the operations your application needs rather than inferring capabilities from a database category label. The public contract covers typed tables, constraints, transactions, joins, grouped aggregates and window functions.

A reporting task can be expressed directly:

```sql
SELECT account_id, count(*) AS event_count, sum(amount) AS total_amount
FROM events
WHERE day >= '2025-01-01' AND day < '2025-02-01'
GROUP BY account_id
ORDER BY total_amount DESC
LIMIT 20;
```

This example assumes the table contains the named columns. Define representative data and verify the result before measuring it. Use `EXPLAIN QUERY PLAN` to inspect access choices and query history to inspect the actual execution's duration and read work.

For a keyed application lookup, primary keys and targeted indexes may matter more than a wide grouped report. For a multi-step change, transaction scope and constraints matter. These are separate reader tasks, so a single benchmark or a storage label cannot stand in for validating them all.

Choose declared types for the actual value range and precision, and avoid projecting columns the caller does not need.

See [SQL queries](https://coordinatordb.com/docs/reference/statements/select), [indexes](https://coordinatordb.com/docs/reference/statements/create/create-index) and [query measurements](https://coordinatordb.com/docs/guides/clickhouse/performance-and-monitoring/isolate-query-bottlenecks).