You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Is your feature request related to a problem? Please describe.
Whenever we start up connection to SQL based feature registry, it attempts to create schema. Allowing app to modify schema is not recommended, if it comes with a bug it might corrupt something or worse case delete it.
Describe the solution you'd like
Schema should be pre-created but since new version of feature registry might need new schema, the sql based registry connection should read schema to see if schema is compatible first, then recommend running a schema tool to create it.
Describe alternatives you've considered
We run the registry service with admin and then redeploy with read-only privileges but that is very manual and time consuming.
Additional context
Not necessary for non-sql based feature registry.
Hi @nquinn408 ,
I looked into the issue and here's the approach I have in mind.
schema_mode configuration
Add a new schema_mode option to SqlRegistryConfig with three modes:
auto(default) – Preserves the current behavior by running CREATE TABLE on every startup. This is fully backwards compatible.
verify – Skips DDL entirely and verifies that all expected tables already exist. If any are missing, Feast raises a clear error instructing the user to run feast registry create-schema.
skip – Performs neither DDL nor verification. This is intended for users who manage the schema externally (e.g. Alembic, Flyway, etc.).
New CLI command
Add a new command:
feast registry create-schema
This command reads feature_store.yaml, connects using the configured credentials, and executes the required CREATE TABLE statements. Since it's idempotent, it's safe to run multiple times.
The intended workflow is:
Run feast registry create-schema once during deployment using a privileged database user.
Deploy the application using a non-DDL user with schema_mode: verify.
Overall, this addresses the workflow described under the alternative considerations. Instead of deploying once with an admin user and then redeploying with a restricted user, users can initialize the schema a single time and deploy with schema_mode: verify from the beginning.
Activity
AdityaPatil22 commentedon Aug 3, 2026
Hi @nquinn408 ,
I looked into the issue and here's the approach I have in mind.
schema_modeconfigurationAdd a new
schema_modeoption toSqlRegistryConfigwith three modes:auto(default) – Preserves the current behavior by runningCREATE TABLEon every startup. This is fully backwards compatible.verify– Skips DDL entirely and verifies that all expected tables already exist. If any are missing, Feast raises a clear error instructing the user to runfeast registry create-schema.skip– Performs neither DDL nor verification. This is intended for users who manage the schema externally (e.g. Alembic, Flyway, etc.).New CLI command
Add a new command:
This command reads
feature_store.yaml, connects using the configured credentials, and executes the requiredCREATE TABLEstatements. Since it's idempotent, it's safe to run multiple times.The intended workflow is:
feast registry create-schemaonce during deployment using a privileged database user.schema_mode: verify.Example configuration:
Overall, this addresses the workflow described under the alternative considerations. Instead of deploying once with an admin user and then redeploying with a restricted user, users can initialize the schema a single time and deploy with
schema_mode: verifyfrom the beginning.Happy to open a PR if this direction makes sense.
cc: @ntkathole
nquinn408 commentedon Aug 4, 2026
@AdityaPatil22 I love this approach. Feel free to tag me on the review. Thanks for your effort!
AdityaPatil22 commentedon Aug 5, 2026
@nquinn408 - Raised a PR with suggested changes.
Could you please have a look : #6704
Thank you