# Feast Registry Types Explained: File, SQL, Snowflake, and Remote Backends > Explore Feast registry types: File, SQL, Snowflake, and Remote. Understand their differences in storage, concurrency, and complexity for your specific use case. - Repository: [Feast/feast](https://github.com/feast-dev/feast) - Tags: deep-dive - Published: 2026-03-01 --- **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`](https://github.com/feast-dev/feast/blob/main/feast/infra/registry/file.py), the `FileRegistryStore` class initializes by resolving the registry path relative to the repository root: ```python 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:** ```yaml # feature_store.yaml project: my_project registry: registry_type: file path: ./registry.pb ``` ```python 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`](https://github.com/feast-dev/feast/blob/main/feast/infra/registry/sql.py), the `SqlRegistry` class creates separate read and write engines: ```python 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:** ```yaml # feature_store.yaml project: my_project registry: registry_type: sql path: postgresql://feast_user:password@db.example.com:5432/feast_meta cache_ttl_seconds: 300 thread_pool_executor_worker_count: 4 ``` ```python 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`](https://github.com/feast-dev/feast/blob/main/feast/infra/registry/snowflake.py), the `SnowflakeRegistry` uses Snowflake-specific connectors and SQL: ```python 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:** ```yaml # feature_store.yaml project: my_project registry: registry_type: snowflake.registry account: xy12345 user: feast_user password: "" warehouse: COMPUTE_WH database: FEAST_DB schema: PUBLIC cache_ttl_seconds: 60 ``` ```python 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`](https://github.com/feast-dev/feast/blob/main/feast/infra/registry/remote.py), the `RemoteRegistry` acts as a stateless gRPC client: ```python 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:** ```yaml # 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 ``` ```python 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.