# Plan the number of tables and databases

Do not plan capacity from an undocumented maximum object count. Coordinator DB exposes managed database and table inventories, while practical limits depend on the workload and resources available to your deployment. A successful CREATE alone does not prove that a very large catalog meets your latency goals.

```sql
SELECT database, count(*) AS objects
FROM system.tables
WHERE schema_name = 'main'
GROUP BY database
ORDER BY database
FORMAT csv;
```

## Choose a useful object boundary

A table should represent a meaningful schema and access pattern. Avoid creating one table per event, customer or time bucket solely to imitate a partition feature. A shared table with explicit identifiers can make application queries and schema changes easier to manage, provided it matches the required data contract.

## Measure catalog growth

Test the expected number of databases and tables in a nonproduction environment. Include startup, metadata discovery, ordinary queries and the schema changes your application performs. Record resource usage and client-visible duration as the catalog grows.

Use `system.databases`, `system.tables` and `system.columns` to confirm what actually exists. Filter by database and namespace when identical table names are intentional. Do not treat a table-size estimate as an exact count of its rows.

See [database inventory](https://coordinatordb.com/docs/reference/system-tables/databases), [table inventory](https://coordinatordb.com/docs/reference/system-tables/tables) and [schema design](https://coordinatordb.com/docs/guides/clickhouse/data-modelling/schema-design).