Feast Registry Types Explained: File, SQL, Snowflake, and Remote Backends

Feast supports four registry backends—File, SQL, Snowflake, and Remote—that differ in storage location (local filesystem vs relational database vs data warehouse vs gRPC service), concurrency guarantees, and deployment complexity, enabling everything from single-node experiments to distributed multi-tenant production clusters.

Feast (feast-dev/feast) stores feature store metadata—entities, feature views, and data sources—in a central registry. Selecting the appropriate registry type is critical for balancing simplicity, scalability, and infrastructure alignment. This guide examines the architectural differences, implementation details, and configuration patterns for each backend based on the Feast source code.

File Registry: Local Protobuf Storage

The File Registry persists metadata as a serialized protobuf file on the local filesystem. This is the simplest backend and requires no external infrastructure.

In feast/infra/registry/file.py, the FileRegistryStore class initializes by resolving the registry path relative to the repository root:

class FileRegistryStore(RegistryStore):
    def __init__(self, registry_config: RegistryConfig, repo_path: Path):
        registry_path = Path(registry_config.path)
        self._filepath = registry_path if registry_path.is_absolute() else repo_path / registry_path

Key characteristics:

• Simplicity: Stores the entire RegistryProto as a single binary file (registry.pb).
• No concurrency control: Concurrent write operations will overwrite each other, causing data loss.
• Direct I/O: Every read operation hits the filesystem; there is no caching layer.

When to use: Local development, unit tests, CI pipelines, or air-gapped environments without database connectivity.

Configuration example:

# feature_store.yaml

project: my_project
registry:
  registry_type: file
  path: ./registry.pb

from feast import FeatureStore

store = FeatureStore(repo_path=".")
entity = store.get_entity("customer_id")

SQL Registry: Production-Grade Relational Backend

The SQL Registry uses SQLAlchemy to store metadata in a relational database such as PostgreSQL, MySQL, or SQLite. This backend provides ACID guarantees and supports high-concurrency access.

Implemented in feast/infra/registry/sql.py, the SqlRegistry class creates separate read and write engines:

class SqlRegistry(CachingRegistry):
    def __init__(self, registry_config, project, repo_path):
        self.write_engine = create_engine(registry_config.path, **registry_config.sqlalchemy_config_kwargs)
        self.read_engine = self.write_engine if not registry_config.read_path else create_engine(registry_config.read_path, **registry_config.sqlalchemy_config_kwargs)

Key characteristics:

• Relational schema: Creates tables (projects, entities, feature_views) via SQLAlchemy metadata.
• Transactional writes: All mutations use with self.write_engine.begin() for atomic commits.
• Read replicas: Optional read_path configuration allows routing queries to a read-only replica while writes go to the primary.
• Caching: Inherits from CachingRegistry to maintain an in-memory cache with configurable TTL (cache_ttl_seconds).

When to use: Production deployments requiring concurrent access, transactional safety, or integration with existing RDBMS infrastructure.

Configuration example:

# feature_store.yaml

project: my_project
registry:
  registry_type: sql
  path: postgresql://feast_user:[email protected]:5432/feast_meta
  cache_ttl_seconds: 300
  thread_pool_executor_worker_count: 4

from feast import FeatureStore

store = FeatureStore(repo_path=".")
store.apply_entity(my_entity)

Snowflake Registry: Data Warehouse-Native Metadata

The Snowflake Registry co-locates metadata within your Snowflake data warehouse, leveraging existing security and governance policies.

Found in feast/infra/registry/snowflake.py, the SnowflakeRegistry uses Snowflake-specific connectors and SQL:

class SnowflakeRegistry(BaseRegistry):
    def __init__(self, registry_config, project, repo_path):
        self.registry_path = f'"{self.registry_config.database}"."{self.registry_config.schema_}"'
        # Creates tables via Snowflake-specific DDL

Key characteristics:

• Native Snowflake SQL: Uses execute_snowflake_statement for DDL and DML operations rather than SQLAlchemy.
• Metadata synchronization: Automatically syncs FEAST_METADATA to a PROJECTS table on startup via _sync_feast_metadata_to_projects_table.
• Thread-safe caching: Implements _refresh_lock to manage TTL-based cache refreshes in concurrent environments.
• Enterprise authentication: Supports password, private-key, and external authenticator methods with TLS encryption.

When to use: Organizations with Snowflake-centric data platforms seeking unified security, low-latency access within the warehouse ecosystem, and reduced external infrastructure.

Configuration example:

# feature_store.yaml

project: my_project
registry:
  registry_type: snowflake.registry
  account: xy12345
  user: feast_user
  password: "<secret>"
  warehouse: COMPUTE_WH
  database: FEAST_DB
  schema: PUBLIC
  cache_ttl_seconds: 60

from feast import FeatureStore

store = FeatureStore(repo_path=".")
store.apply_feature_view(my_feature_view)

Remote Registry: Distributed gRPC Service

The Remote Registry connects to a standalone registry server via gRPC, enabling centralized metadata management for distributed architectures.

Implemented in feast/infra/registry/remote.py, the RemoteRegistry acts as a stateless gRPC client:

class RemoteRegistry(BaseRegistry):
    def __init__(self, registry_config, project, repo_path, auth_config=NoAuthConfig()):
        self.channel = self._create_grpc_channel(registry_config)
        self.stub = RegistryServer_pb2_grpc.RegistryServerStub(self.channel)

Key characteristics:

• Stateless client: The local instance holds no persistent state; all storage logic resides on the server.
• gRPC transport: Every operation (e.g., apply_entity, list_feature_views) marshals protobuf requests to the remote service.
• TLS encryption: Supports secure channels via grpc.ssl_channel_credentials when cert or is_tls is configured.
• Pluggable authentication: Optional GrpcClientAuthHeaderInterceptor injects bearer tokens or custom auth headers.

When to use: Multi-cluster Kubernetes deployments, multi-tenant SaaS platforms, or scenarios requiring registry lifecycle decoupling from feature store processes (e.g., independent rolling upgrades).

Configuration example:

# feature_store.yaml

project: my_project
registry:
  registry_type: remote
  path: grpcs://registry.mycompany.com:6565
  cert: /etc/ssl/certs/registry.crt
  is_tls: true

from feast import FeatureStore
from feast.permissions.auth_model import AuthConfig

auth = AuthConfig(token="eyJhbGciOi...")
store = FeatureStore(repo_path=".", auth_config=auth)
feature_views = store.list_feature_views(project="my_project")

Summary

• File Registry stores metadata in a local registry.pb file with no concurrency support, ideal for development and CI.
• SQL Registry provides transactional, concurrent access via SQLAlchemy and supports read replicas, suitable for production RDBMS environments.
• Snowflake Registry leverages native Snowflake tables and authentication, optimized for data warehouses already using Snowflake.
• Remote Registry uses gRPC to connect to a centralized registry server, enabling distributed, multi-tenant deployments with TLS and custom authentication.

Frequently Asked Questions

Which Feast registry type is best for local development?

The File Registry is optimal for local development due to its zero-dependency setup and simple configuration. It requires only a file path and works offline, making it ideal for experiments and unit tests where concurrent access is not a concern.

Can I migrate from a File registry to SQL without losing metadata?

Yes, but Feast does not provide a built-in migration utility. You must manually export the protobuf from the file registry and import it into the SQL registry using the Feast Python SDK to re-apply entities and feature views, or implement a custom script that reads registry.pb and calls apply() methods against a SQL-backed store.

How does the Remote registry handle authentication?

The Remote Registry passes an auth_config parameter to GrpcClientAuthHeaderInterceptor, which injects headers such as bearer tokens into gRPC metadata. You configure this by providing an AuthConfig object when initializing FeatureStore, or by setting TLS certificates via the cert and is_tls configuration fields for mutual TLS authentication.

Does the Snowflake registry require separate infrastructure?

No, the Snowflake Registry utilizes your existing Snowflake warehouse infrastructure. It creates metadata tables within a specified database and schema using Snowflake-native storage, eliminating the need for separate database servers while inheriting Snowflake's security, backup, and governance policies.

{
  "mcpServers": {
    "instagit": {
      "command": "npx",
      "args": ["-y", "instagit@latest"]
    }
  }
}