Add `database.external` configuration to support external PostgreSQL (parity with redis.external)

[sayerada]

Problem

The chart currently supports external Redis via the redis.external.enabled configuration, which disables the creation of an internal Redis StatefulSet. However, there is no equivalent configuration for PostgreSQL.

When using an external PostgreSQL database (e.g., AWS Aurora, Cloud SQL), LGP custom resources created by LangSmith deployments still have spec.database.enabled: true, which causes the operator to create internal PostgreSQL StatefulSets that cannot start due to missing storage class configuration or are simply redundant.

This results in:

• Permanently pending pods consuming scheduler resources
• Unnecessary PVC creation attempts
• Confusion about which database is actually being used

Current Behavior

# values.yaml - Redis has external support
redis:
  external:
    enabled: true
    existingSecretName: "my-redis-secret"
    connectionUrlSecretKey: "REDIS_URI_CUSTOM"

# No equivalent for database
# database.external does not exist

When external postgres credentials are provided via POSTGRES_URI_CUSTOM in deployment secrets, the operator still creates an internal postgres StatefulSet if the LGP CR has database.enabled: true.

Expected Behavior

The chart should provide a database.external configuration option similar to redis.external:

database:
  external:
    enabled: false  # Set to true when using external postgres
    existingSecretName: ""
    connectionUrlSecretKey: "POSTGRES_URI_CUSTOM"

When database.external.enabled: true, the chart/operator should:

1. Not create internal PostgreSQL StatefulSets
2. Optionally override LGP CR database.enabled settings (similar to how redis is handled)
3. Use the external connection string from the specified secret

Proposed Solution

Add a database.external configuration section to values.yaml that mirrors the existing redis.external structure:

database:
  name: "postgres"
  containerPort: 5432
  external:
    # -- Whether to use an external PostgreSQL instance. This will disable the
    # creation of a postgres stateful-set and service.
    enabled: false
    connectionUrl: ""
    connectionUrlSecretKey: "connection_url"
    existingSecretName: ""

Use Case

We're deploying LangGraph Platform in a hybrid environment with:

• External AWS Aurora PostgreSQL (managed separately via Terraform)
• External AWS ElastiCache Redis (managed separately via Terraform)
• LangSmith Cloud creating LGP deployments via API

Currently, even though we provide POSTGRES_URI_CUSTOM in our deployment secrets, we end up with stuck pods because LangSmith sets database.enabled: true in the LGP CR.

Additional Context

• Chart version: 0.2.14
• This would provide feature parity with the existing redis.external configuration
• Production environments often use managed database services rather than in-cluster postgres
• The operator.templates.db template is always available but there's no chart-level way to prevent its use

[romain-priour-lc]

Hey Adam Sayer (@sayerada)!

To clarify, the redis section in this chart is to create a Redis instance specifically for the listener to reconcile deployments, and is purely used as pub/sub and caching layer for that purpose. This instance is separate from the Redis used by individual agent deployments. Since there is no persistence layer for the purpose of reconciling deployment jobs, a database layer/option here would be redundant.

However, as long as you set POSTGRES_URI_CUSTOM in your agent deployment environment, a Postgres StatefulSet should not get created. I would confirm that your environment variable is correctly bound to the agent deployment at runtime. If it is, then a StatefulSet should not be created inside of your cluster.

Let me know if you have any further questions!

[sayerada]

Hi Romain Priour (@romain-priour-lc), thanks for the clarification on the Redis architecture.

However, I can confirm that a Postgres StatefulSet IS being created despite POSTGRES_URI_CUSTOM being set correctly. Here's the evidence:

1. POSTGRES_URI_CUSTOM is set in the deployment:

$ kubectl get deployment -n langgraph-platform -l app=tdr-helios-test-* \
  -o jsonpath='{.items[0].spec.template.spec.containers[0].env[?(@.name=="POSTGRES_URI_CUSTOM")]}'

{
  "name": "POSTGRES_URI_CUSTOM",
  "valueFrom": {
    "secretKeyRef": {
      "key": "POSTGRES_URI_CUSTOM",
      "name": "tdr-helios-test-5fefd700d596505e9d6485c9f953cf56-secrets"
    }
  }
}

2. Yet a Postgres StatefulSet exists and is stuck in pending:

$ kubectl get statefulset lg-5fefd700d596505e9d6485c9f953cf56 -n langgraph-platform
NAME                                  READY   AGE
lg-5fefd700d596505e9d6485c9f953cf56   0/1     44d

$ kubectl get pod lg-5fefd700d596505e9d6485c9f953cf56-0 -n langgraph-platform
NAME                                 READY   STATUS    RESTARTS   AGE
lg-5fefd700d596505e9d6485c9f953cf56-0   0/1     Pending   0          44d

3. The root cause: LGP CR has database.enabled: true

$ kubectl get lgp tdr-helios-test-* -n langgraph-platform -o jsonpath='{.spec.database}'

{
  "enabled": true,
  "legacyName": true,
  "maxConnections": 350,
  "resources": {...},
  "secretName": "tdr-helios-test-5fefd700d596505e9d6485c9f953cf56-secrets",
  "storageSizeGi": 10
}

The LGP custom resource is created by LangSmith Cloud when we deploy through the UI/API, and it sets spec.database.enabled: true even though we're providing external Aurora credentials via POSTGRES_URI_CUSTOM.

The operator creates the StatefulSet because database.enabled: true in the LGP CR, regardless of whether POSTGRES_URI_CUSTOM is set in the environment.

Is there a setting in LangSmith deployment configuration to prevent it from setting database.enabled: true when external databases are being used?

[sayerada]

Romain Priour (@romain-priour-lc)

Here is relevant helm values snippet. POSTGRES_URI_CUSTOM is in the langgraph-postgres secret in envFrom.

[romain-priour-lc]

Hey Adam Sayer (@sayerada)

I tried deploying an agent with POSTGRES_URI_CUSTOM set, on a hybrid helm chart deployment (latest version), and I can see that .spec.database.enabled is set to false, and no postgres statefulset is ever created. See attached screenshots.

I suspect that either the environment variable is may not be bound properly through the secret. How are you providing it to the agent?

Otherwise, is it possible that the statefulset you are showing is not actually attached to that agent, and is a rogue statefulset left over from a previous agent? I see that the postgres statefulset is 44 days old.

[sayerada]

Thanks for checking Romain Priour (@romain-priour-lc), here's what I've found:

The secret binding IS working correctly:

$ kubectl get secret tdr-helios-test-*-secrets -o jsonpath='{.data.POSTGRES_URI_CUSTOM}' | base64 -d
postgresql://langgraphadmin:***@agentic-test-postgres.cluster-***.us-east-1.rds.amazonaws.com:5432/langgraph

However, the LGP CR currently shows database.enabled: true:

$ kubectl get lgp tdr-helios-test-* -o jsonpath='{.spec.database.enabled}'
true

Timeline:

• LGP CR created: October 22, 2025
• StatefulSet created: November 23, 2025 (32 days later)
• LGP generation: 119 (it's been updated many times)

Previously this did work as expected and as shown in your screenshot when POSTGRES_URI_CUSTOM was set in LangSmith UI. The LangSmith UI screenshot you shared shows Database: Enabled: false, but when I query the actual LGP CR in my cluster, it shows database.enabled: true.

Possible Explanations:

1. The LangSmith UI and the actual LGP CR spec are out of sync
2. There's a race condition where the setting gets toggled during deployments
3. Something in my environment is overriding the LangSmith configuration

How does LangSmith determine whether to set database.enabled: true/false in the LGP CR? Is there a deployment setting I should check?

[romain-priour-lc]

Thanks for the additional info. How are you binding the secret value to the agent deployment, are you using the environment variable in the UI/API, or are you creating the secret manually and binding it through a volume?

[sayerada]

We're creating the secret using External Secrets Operator and binding it through the helm chart's custom deployment template using envFrom.

Here's our setup:

1. Secret Creation (External Secrets Operator):

# argocd/components/langgraph/platform/externalsecrets.yaml
apiVersion: external-secrets.io/v1
kind: ExternalSecret
metadata:
  name: langgraph-postgres
  namespace: langgraph-platform
spec:
  secretStoreRef:
    name: aws-secretsmanager
    kind: ClusterSecretStore
  target:
    name: langgraph-postgres
    creationPolicy: Owner
  data:
    - secretKey: POSTGRES_URI_CUSTOM
      remoteRef:
        key: agentic-test-postgres-connection
        property: connection_url
    # ... other keys

This creates a Kubernetes secret named langgraph-postgres with the Aurora connection string.

2. Binding to Deployments (Helm Chart Override):

# argocd/components/langgraph/platform/values-agentic-test.yaml
operator:
  templates:
    deployment: |
      apiVersion: apps/v1
      kind: Deployment
      spec:
        template:
          spec:
            containers:
            - name: api-server
              # Load common secrets via envFrom - applies to ALL deployments
              envFrom:
                - secretRef:
                    name: langgraph-postgres
                - secretRef:
                    name: langgraph-redis
                # ... other secrets

We're NOT setting the environment variable through the LangSmith UI/API. Instead, we override operator.templates.deployment in the helm chart to inject envFrom references, so every LGP deployment created by LangSmith automatically gets these secrets as environment variables.

This approach was recommended in helm issue #477 for injecting common environment variables into all deployments.

The secret binding is working (I can verify POSTGRES_URI_CUSTOM has the correct Aurora connection string), but the LGP CR still has database.enabled: true, which creates the unwanted StatefulSet.

[romain-priour-lc]

Hey Adam Sayer (@sayerada),

Apologies for the delayed response! After further investigation, the value for POSTGRES_URI_CUSTOM and REDIS_URI_CUSTOM must be specified at the control plane level, so in your case it must be provided through the "secrets" section of your deployment in the LangSmith API/UI.

Would this be a blocker for your team moving forward?

[sayerada]

Romain Priour (@romain-priour-lc) , this would be a blocker moving forward as it would require old school user/pass auth stored in LangSmith which would make password rotation more difficult. Secrets can also be retrieved by a larger audience than needed in LangSmith as opposed to our secrets manager.