Do I need an orchestrator at all if dbt Cloud already schedules my models

The trigger is not model count, it is cross system dependencies. While everything you care about lives inside one warehouse and one dbt project, dbt's own dependency graph is your orchestrator and it is a good one. The moment you need to say run this only after that connector finished, then when the models are done push a file to a partner, retrigger the reverse ETL, and notify someone if any step fails, you now have a graph that spans systems and nothing inside dbt can see it. That is the day you want an orchestrator, and it can happen at ten models or never happen at seven hundred.

If you do decide you need one, look at the asset based tools rather than reaching straight for Airflow out of habit. Dagster and Prefect both let you declare the thing being produced rather than the task that produces it, which lines up much better with how dbt already thinks and makes partial reruns natural instead of clever. Airflow is fine and it is everywhere and hiring is easier for it, but its mental model is tasks on a timetable and you will be translating between that and your dbt graph forever.

Disagreeing with the wait until it hurts crowd, partly. Adopting an orchestrator is much easier when you have five things to move than when you have fifty and three of them are load bearing. I would not install Airflow today at your size, but I would keep the scheduling logic in one file rather than scattered across the dbt Cloud UI, so that the migration is a port rather than an excavation.

Ran cron plus dbt for four years at roughly your size and never regretted it. One shell script, a lock file so two runs cannot overlap, output piped into a log, and a check that alerts if the run has not written a success marker by a given time. The whole thing was under a hundred lines and I could explain it to a new hire in five minutes. Airflow at that size would have been a bigger system than the thing it was scheduling, and I have watched two teams spend more time on their orchestrator than on their models.

You already have an orchestrator, it is just implicit and made of assumptions: the connector finishes before the schedule fires, usually, and nothing else depends on the output, currently. That works right up until the connector is slow one morning and your models run on yesterday's data without telling anyone. Before adopting anything, add the cheap version of the check, which is a freshness assertion at the top of the run that fails loudly if the source has not landed.