Based on the knowledge sources, setting

useConnectorResourceDefaults: false

is not the correct approach to override memory limits for your Postgres connector. Here's what you should do instead: ## Proper Way to Configure Connector Resources Airbyte has a configuration hierarchy for resource allocation with four levels of precedence (from lowest to highest): 1. Instance-wide - Applies to all containers 2. Connector definition - Applies to all connectors of that type (e.g., all Postgres sources) 3. Connector-specific - Applies to one specific connector instance 4. Connection-specific - Applies to a specific source/destination combination According to the [configuring connector resources documentation](https://docs.airbyte.com/platform/operator-guides/configuring-connector-resources), you have several options: ### Option 1: Instance-Wide Configuration (Recommended First Step) Set these in your `values.yaml`:

yaml global:   workloads:     resources:       mainContainer:         memory:           request: "4Gi"  # or higher           limit: "8Gi"    # or higher

### Option 2: Connector Definition Level If you only want to increase memory for Postgres connectors specifically, you can update the connector definition in the database: 1. Find the connector definition ID:

sql select * from actor_definition where actor_definition.docker_repository like '%postgres%';

2. Update the resource requirements:

sql update actor_definition set resource_requirements = '{"jobSpecific": [{"jobType": "sync", "resourceRequirements": {"memory_limit": "8Gi", "memory_request": "4Gi"}}]}' where id = '<id-from-step-1>';

## Important Notes - The 2GB default memory limit is a common issue mentioned in [this forum discussion](https://discuss.airbyte.io/t/3472), where users experienced OOM errors with Postgres syncs - As noted in [GitHub issue #48816](https://github.com/airbytehq/airbyte/issues/48816), you may also need to set resources for other job types (CHECK, DISCOVER, SPEC) if you're experiencing OOM during connector setup:

yaml global:   env_vars:     CHECK_JOB_MAIN_CONTAINER_MEMORY_REQUEST: "4Gi"     CHECK_JOB_MAIN_CONTAINER_MEMORY_LIMIT: "8Gi"

The

useConnectorResourceDefaults

flag is not mentioned in the knowledge sources as a way to override memory limits. Instead, use the configuration hierarchy described above.

Based on the knowledge sources, there's a known issue where global/instance-wide resource configurations are being ignored for connector-level resources in recent Airbyte versions. This is documented in several GitHub issues. ## The Problem According to [GitHub issue #38178](https://github.com/airbytehq/airbyte/issues/38178), users report that syncs don't respect the

resource_requirements

set in the

actor_definition

table, and instead fall back to instance-wide defaults from the configmap. However, there are also reports in [GitHub issue #30814](https://github.com/airbytehq/airbyte/issues/30814) where users state that instance-wide settings are being ignored entirely. One user in [GitHub issue #38178](https://github.com/airbytehq/airbyte/issues/38178) using Airbyte v1.7.1 reported: > "We self-host Airbyte on AKS and want to set specific CPU/memory requests and limits per source (type)... we adjusted the source connector actor definition in Airbyte's PostgreSQL database... but it is completely ignored. Instance-wide defaults defined in Helm chart are used instead." ## Current Workarounds Based on the knowledge sources, here are your options: ### 1. Connection-Specific Configuration (Most Reliable) According to [the documentation](https://docs.airbyte.com/platform/operator-guides/configuring-connector-resources#configuring-connection-specific-requirements), connection-specific settings have the highest precedence and appear to work more reliably: 1. Extract the connection ID from the URL (format:

<base_url>/workspaces/<workspace-id>/connections/<connection-id>/status

) 2. Update the connection in the database:

sql update connection set resource_requirements = '{"cpu_limit": "4", "cpu_request": "1", "memory_limit": "8Gi", "memory_request": "4Gi"}' where id = '<connection-id>';

As noted in [GitHub issue #30814](https://github.com/airbytehq/airbyte/issues/30814): "works at the connection-level, but not at the instance-level or connector-level" ### 2. Connector Definition Configuration You can try updating the

actor_definition

table for your Postgres connector:

sql update actor_definition set resource_requirements = '{"jobSpecific": [{"jobType": "sync", "resourceRequirements": {"cpu_limit": "4", "cpu_request": "1", "memory_limit": "8Gi", "memory_request": "4Gi"}}]}' where id = '<connector-definition-id>';

However, multiple users report this doesn't work reliably in recent versions. ## Answer to Your Question Yes, unfortunately you likely need to make the configuration change directly in the Airbyte database at the connection level, as global/instance-wide settings appear to be ignored for connector resources in recent versions. This is a known issue that affects multiple users across different Airbyte versions (1.2.0, 1.7.1, and others). The connection-specific approach is currently the most reliable workaround according to the reported experiences in the knowledge sources.

Based on the knowledge sources, you're correct that the orchestrator container is not picking up your global memory settings. This is a known behavior in Airbyte. ## Orchestrator Container Resources According to [this forum discussion](https://discuss.airbyte.io/t/3775), the orchestrator container **inherits its resource requirements from the

JOB_MAIN_CONTAINER_*

environment variables**. As stated in the official answer: > "Yes, the orchestrator pods get their resource requirements from the

JOB_MAIN_CONTAINER_*

environment variables. These environment variables are used to configure the resource requirements for the job containers, which include the orchestrator pods." So when you set:

yaml global:   workloads:     resources:       mainContainer:         memory:           request: "8Gi"           limit: "16Gi"

This should affect the orchestrator as well. However, based on your output showing the orchestrator still at

2048:2048

(2Gi), it appears these settings aren't being applied. ## Why Your Global Settings Aren't Working From your earlier conversation, you discovered that

global.jobs.resources

doesn't work in Helm chart v2. You need to ensure you're using the correct path:

global.workloads.resources.mainContainer.*

Additionally, according to [GitHub issue #48816](https://github.com/airbytehq/airbyte/issues/48816), you may need to set separate environment variables for different job types:

yaml global:   env_vars:     JOB_MAIN_CONTAINER_MEMORY_REQUEST: "8Gi"     JOB_MAIN_CONTAINER_MEMORY_LIMIT: "16Gi"     CHECK_JOB_MAIN_CONTAINER_MEMORY_REQUEST: "8Gi"     CHECK_JOB_MAIN_CONTAINER_MEMORY_LIMIT: "16Gi"     DISCOVER_JOB_MAIN_CONTAINER_MEMORY_REQUEST: "8Gi"     DISCOVER_JOB_MAIN_CONTAINER_MEMORY_LIMIT: "16Gi"     SPEC_JOB_MAIN_CONTAINER_MEMORY_REQUEST: "8Gi"     SPEC_JOB_MAIN_CONTAINER_MEMORY_LIMIT: "16Gi"

## Verifying Configuration You can verify what resources are being applied by checking the job logs. According to the [debugging documentation](https://docs.airbyte.com/platform/operator-guides/configuring-connector-resources#debugging), Airbyte logs the resource requirements when containers are created:

2024-10-28 23:58:10 platform > [orchestrator] image: airbyte/container-orchestrator:build-256f73c6c2-20488-master resources: ResourceRequirements(claims=[], limits={memory=2Gi, cpu=1}, requests={memory=2Gi, cpu=1}, additionalProperties={})

## Next Steps 1. Verify your

values.yaml

is using

global.workloads.resources.mainContainer.*

(not

global.jobs.resources.*

) 2. After updating, run

helm upgrade

and restart your worker pods (this is often necessary for changes to take effect) 3. Check the configmap:

kubectl get configmap airbyte-airbyte-env -o yaml | grep JOB_MAIN_CONTAINER

4. If the environment variables are still empty, you may need to set them explicitly as shown above For the Snowflake destination, yes, you would need to update its connection-specific settings in the database as well if you want different limits than the global defaults.