Migrate from built-in data sources v26.4+

The built-in KUBERNETES, REDIS and CASSANDRA data source implementations were removed in Kubling 26.4. A VDB that still uses one of these types fails during startup with a migration error.

The legacy type names may still be recognized by configuration parsing so the engine can report a targeted error. They do not enable the former embedded adapters.

What changes

Previously, source endpoints, credentials and adapter configuration lived in the Kubling VDB or engine filesystem. With providers, that information belongs to a separate provider process. The VDB registers only a PROVIDER_GRPC endpoint and keeps federation-level concerns such as cache, health and Soft Transactions.

Removed type	Replacement	Migration considerations
`KUBERNETES`	Kubernetes provider	Run one provider instance per cluster. The provider discovers resources dynamically, so compare the resulting schema with the former built-in DDL before migrating queries.
`REDIS`	Redis provider	Move Redis connection and table definitions into provider configuration. The current official provider exposes configured Redis Hash tables; legacy String and Sorted Set models are not drop-in compatible.
`CASSANDRA`	Cassandra provider	Move hosts, credentials, TLS and keyspace settings into provider-owned namespaces. Schema metadata is discovered from Cassandra.

Migration sequence

Select and pin an immutable official provider image version.
Create the provider-specific configuration outside the Kubling VDB.
Deploy the provider where both Kubling and the remote source can reach it.
Replace the legacy data source with a PROVIDER_GRPC registration.
Start Kubling and inspect the schema discovered from the provider.
Update queries, VDB enrichment and write paths for any schema or capability differences.
Validate health, representative queries, mutations and transaction behavior before removing the legacy configuration.

Migration is not a blind replacement of dataSourceType. Configuration ownership and, depending on the provider, the discovered schema both change.

Do not copy legacy native connection settings into the PROVIDER_GRPC configObject, assume the old and new schemas are identical, or leave source credentials in the VDB. Configure the native source in the provider and validate the model returned by GetSchema.

Example: Kubernetes

The old VDB configured the Kubernetes client inside the engine:


dataSources:
  - name: "production-cluster"
    dataSourceType: "KUBERNETES"
    configObject:
      configFile: "/etc/kubling/kubeconfig"
      blankNamespaceStrategy: "ALL"
    schema:
      type: "PHYSICAL"

In 26.4, the kubeconfig and resource discovery settings move to the Kubernetes provider:


# provider.yaml
kubeconfig: /etc/kubling/kubeconfig
blankNamespaceStrategy: ALL
 
schema:
  fieldExpansionDepth: 3
  include:
    - "v1/*"
    - "apps/v1/*"

Kubling then registers that process as the physical data source:


# VDB descriptor
dataSources:
  - name: "production-cluster"
    dataSourceType: "PROVIDER_GRPC"
    configObject:
      address: "kubernetes-provider"
      port: 50051
      timeoutMillis: 30000
      securityConfig:
        mode: "PLAINTEXT"
      contributesToHealth: true
    schema:
      type: "PHYSICAL"

The provider exposes one cluster. To federate several clusters, deploy one provider instance for each cluster and register each instance as a separate Kubling data source. Aggregator schemas or virtual models can then present a unified view.

Validate the migrated VDB

Before switching production traffic, verify at least:

provider and aggregate Kubling health.
the discovered schemas, tables, column types and keys.
representative filters, ordering, pagination and joins.
insert, update and delete paths used by the VDB.
generated values and row identity where applicable.
native or Soft Transaction behavior used by the workload.
cache behavior and invalidation if engine-side caching is enabled.

Treat a schema or capability change as an application compatibility change, even when the provider reaches the same native source.

Provider-owned configuration

Use the provider’s versioned documentation as the source of truth for native connection settings:

Credentials remain inside the provider boundary and are not sent to Kubling through the provider protocol.