ContextQMD
Back to Feast

Guide 4 — Registry Topology

docs/how-to-guides/feast-operator/04-registry-topology.md

0.64.05.6 KB
Original Source

Guide 4 — Registry Topology

The Feast registry stores metadata about feature views, entities, and feature services. The operator supports three topology options:

TopologyUse case
Local (file or DB)Self-contained deployment; registry runs alongside other services
Local + serverLocal registry exposed as a gRPC / REST server for remote clients
RemoteMultiple FeatureStore CRs share a single registry managed by another CR

Local registry

File-backed (default)

yaml
services:
  registry:
    local:
      persistence:
        file:
          path: registry.db
          pvc:
            create: {}
            mountPath: /data/registry

DB-backed (SQL / Snowflake)

yaml
apiVersion: v1
kind: Secret
metadata:
  name: feast-data-stores
stringData:
  sql: |
    path: postgresql+psycopg://feast:feast@postgres:5432/feast  #pragma: allowlist secret
    cache_ttl_seconds: 60
---
services:
  registry:
    local:
      persistence:
        store:
          type: sql
          secretRef:
            name: feast-data-stores   # reads key "sql"

Exposing the registry as a server

Add server: {} under registry.local to expose it on port 6570:

yaml
services:
  registry:
    local:
      server: {}                       # exposes gRPC on 6570
      persistence:
        store:
          type: sql
          secretRef:
            name: feast-data-stores

The registry server also supports REST and gRPC independently:

yaml
registry:
  local:
    server:
      restAPI: true    # enable REST API (default: true when server is set)
      grpc: true       # enable gRPC (default: true when server is set)

MCP on the registry server

When the REST API is enabled, you can additionally expose registry metadata as MCP (Model Context Protocol) tool endpoints for LLM agents:

yaml
services:
  registry:
    local:
      server:
        restAPI: true
        mcp:
          enabled: true
      persistence:
        store:
          type: sql
          secretRef:
            name: feast-data-stores

The operator writes registry.mcp.enabled: true into feature_store.yaml. A validation rule enforces that restAPI must be true when mcp.enabled is true.

See Guide 3 — Serving & Observability for more details and the full MCP configuration reference.

Remote registry

A remote registry lets multiple FeatureStore CRs (e.g. in different namespaces or teams) share a single registry. One CR owns the registry; the others point at it.

Using a hostname

Point at any existing Feast registry server endpoint:

yaml
services:
  registry:
    remote:
      hostname: feast-registry.feast-system.svc.cluster.local:6570

Using feastRef (recommended for operator-managed registries)

feastRef lets one FeatureStore CR reference another CR's registry without hard-coding hostnames. The operator resolves the Service name automatically:

yaml
# CR that owns the registry (in namespace "feast-system")
apiVersion: feast.dev/v1
kind: FeatureStore
metadata:
  name: registry-owner
  namespace: feast-system
spec:
  feastProject: shared_project
  services:
    registry:
      local:
        server: {}
        persistence:
          store:
            type: sql
            secretRef:
              name: feast-data-stores
yaml
# CR that consumes the shared registry (in namespace "team-a")
apiVersion: feast.dev/v1
kind: FeatureStore
metadata:
  name: team-a-store
  namespace: team-a
spec:
  feastProject: shared_project
  services:
    registry:
      remote:
        feastRef:
          name: registry-owner
          namespace: feast-system      # omit if same namespace

Remote registry with TLS

If the remote registry server uses TLS, provide the CA certificate so clients can verify it:

yaml
services:
  registry:
    remote:
      feastRef:
        name: registry-owner
        namespace: feast-system
      tls:
        configMapRef:
          name: registry-ca-cert       # ConfigMap containing the CA cert
        certKeyName: ca.crt            # key inside the ConfigMap (default: ca.crt)

All-remote topology

For teams that deploy services independently, all services can use remote endpoints:

yaml
apiVersion: feast.dev/v1
kind: FeatureStore
metadata:
  name: client-store
spec:
  feastProject: my_project
  services:
    offlineStore:
      remote:
        hostname: feast-offline.feast-system.svc.cluster.local:8815
    onlineStore:
      remote:
        hostname: feast-online.feast-system.svc.cluster.local:6566
    registry:
      remote:
        feastRef:
          name: central-registry
          namespace: feast-system

See also