-
Notifications
You must be signed in to change notification settings - Fork 1.1k
Description
Is your feature request related to a problem? Please describe.
Currently, Keep uses the default 'public' schema when deployed with PostgreSQL. This
creates limitations in enterprise environments where:
- Multiple applications share the same PostgreSQL database and need schema isolation
- Security policies require database objects to be organized in specific schemas
- Multi-tenant deployments need logical separation of database objects
- The 'public' schema is restricted or unavailable due to organizational policies
Additionally, there's a hardcoded reference to 'public' schema in migration
025-04-08-10-43_59991b568c7d.py that prevents Keep from working with non-public
schemas.
Describe the solution you'd like
Add support for configuring a PostgreSQL schema through an environment variable
POSTGRES_SCHEMA
. When set, Keep should:
- Create all database tables in the specified schema
- Configure the PostgreSQL search_path to use the custom schema
- Support all migrations and database operations within the configured schema
- Maintain backward compatibility (default to current behavior when not set)
Implementation requirements:
- Fix hardcoded 'public' schema reference in migrations to use
current_schema()
- Add schema configuration in database connection setup
- Document the configuration in the deployment guide
Describe alternatives you've considered
- Connection string parameter: Using
?options=-csearch_path=myschema
or
?currentSchema=myschema
in the DATABASE_CONNECTION_STRING - but this is less
explicit and harder to validate - Database-level default schema: Setting default schema at PostgreSQL user level -
but this requires database admin access and is less flexible - Manual schema prefixing: Modifying all SQLAlchemy models to include schema prefix
- but this would be a major breaking change
Additional context
This feature enables Keep to be deployed in environments with strict database
organization requirements and improves compatibility with enterprise PostgreSQL
deployments. The implementation maintains full backward compatibility while adding
flexibility for advanced use cases.
Example usage:
export POSTGRES_SCHEMA=keep_prod
export DATABASE_CONNECTION_STRING="postgresql+psycopg2://user:pass@host:5432/db"