Hi everyone, I'm working on a Salesforce data extraction pipeline using tap-salesforce (MeltanoLabs variant) with target-postgres, and I'm running into a schema evolution challenge that I'd love some community input on. Current Setup - Extractor: tap-salesforce (MeltanoLabs variant v1.9.0) - Loader: target-postgres (MeltanoLabs variant) - Goal: Store all Salesforce data as JSONB for schema evolution flexibility The Problem Despite configuring target-postgres with flattening disabled, it's still creating individual typed columns for each Salesforce field instead of storing records as JSONB objects:

loaders:
    - name: target-postgres
      variant: meltanolabs
      config:
        # ... connection details ...
        flattening_enabled: false
        flattening_max_depth: 0
        add_record_metadata: true

Current result (unwanted):

-- Creates 270+ individual columns
  CREATE TABLE raw.user (
    Id TEXT,
    Username TEXT,
    LastName TEXT,
    FirstName TEXT,
    -- ... 260+ more columns
  );

Desired result:

-- Single JSONB column for flexibility
  CREATE TABLE raw.user (
    Id TEXT PRIMARY KEY,
    data JSONB,
    _sdc_extracted_at TIMESTAMP,
    -- ... other Singer metadata columns
  );

What I've Tried 1. Flattening configuration: Set flattening_enabled: false and flattening_max_depth: 0 - still creates individual columns 2. Schema transformation: Modified the catalog.json to declare all fields as "object" type - tap-salesforce ignores this and sends typed schemas 3. Source investigation: Found that target-postgres uses field-specific type handlers, and Salesforce sends strongly-typed schemas Questions 1. Is there a target-postgres configuration I'm missing that forces all fields to be stored as JSONB regardless of their declared types? 2. Are there any Singer transformations or middlewares that can convert typed field schemas to generic objects before they reach the target? 3. Has anyone successfully achieved JSONB storage with Salesforce data while using the standard target-postgres? If so, what's your approach? 4. Alternative targets: Should I be using a different PostgreSQL target that's designed for schema-flexible JSONB storage? Use Case I need JSONB storage because Salesforce schemas change frequently (custom fields added/removed), and I want my raw data layer to gracefully handle these changes without pipeline failures. The plan is to use dbt for typed transformations downstream. Any insights, workarounds, or alternative approaches would be greatly appreciated! Thanks in advance for your help! 🙏

Re: your use case, Meltano does that on its own -> gracefully handle changes to the schema. each run of meltano sends a schema message that will have the latest schema of your salesforce stream, which target-postgres will use to conform the schema of the Postgres table. so the addition and removal of custom fields will not fail your pipeline