Summary
Explanation of the implications of disabling the container orchestrator feature in Airbyte
Question
Hi!
Are there any practical downsides of setting CONTAINER_ORCHESTRATOR_ENABLED=false ?
The documentation explains that there is no separate process handling the orchestration but it does not explain why I should care.
Not having a separate orchestrator is the default in the docker compose setup but not in Kubernetes - again I didn’t find an explanation and it does not make sense to me intuitively 
I’d like to avoid unnecessary resource consumption and the current setup already eats a lot of resources.
This topic has been created from a Slack thread to give it more visibility.
It will be on Read-Only mode here. Click here if you want
to access the original thread.
Join the conversation on Slack
["container-orchestrator-enabled", "resource-consumption", "docker-compose", "kubernetes"]
Hi, the orchestrator not existing in docker is more a historical reason.
Technically, I think you could run in kubernetes without orchestrators but that comes with a few downsides.
The orchestrator provides the ability for a sync to survive a redeploy of the platform, without it, redeploying airbyte will interrupt all running syncs, same as what happens on docker. The other piece it provides is isolation, without an orchestrator, one sync having memory issue could affect all running syncs.
As we’re moving forward, the orchestrator will most likely becomes the default and this configuration should disappear.
In terms of what the orchestrator does, the orchestrator is the airbyte piece that’s is managing some of the specificities of the replication process. Validation and other schema checks, checkpointing and other bookkeeping tasks.