Thanks to visit codestin.com
Credit goes to github.com

Skip to content

[req]: Optional PostgreSQL Support for Persistent Configuration Data #16069

@Serena-Sophie

Description

@Serena-Sophie

Is there already a request for your feature?

  • I have checked older issues, open and closed

Is your feature request related to a problem? Please describe.

First of all, thank you for your continued work on this great project!

I’d like to propose adding optional support for PostgreSQL as a backend for persistent configuration data — specifically for:

  • User-defined settings
  • Indexer configurations
  • Global application options/settings

Why PostgreSQL (but not for logs or cache)?

  1. No need for local config file storage
    Storing configuration data in a PostgreSQL database would eliminate the need for local folders or mounted volumes — especially useful in Docker or cloud deployments where persistent volumes add extra complexity. With a database backend, only the DB connection is required.

  2. Centralized and secure storage
    A relational database like PostgreSQL enables centralized, reliable, and secure data storage. It allows for easier backup, replication, and migration of data between instances.

  3. Improved technical flexibility and future potential
    Clean separation of application logic and persistent storage via a database interface would improve modularity, allow better maintenance, and open the door for future features (e.g. easier configuration migration, potential multi-user setups, etc.).

  4. Fully optional
    To be clear: this feature should be optional. Current setups using the filesystem for configuration should continue to work as-is, without any required changes.

  5. Synchronized multi-instance support
    In scenarios where two or more Jackett instances are running (e.g. in different containers or on separate servers), having a shared PostgreSQL database would allow them to automatically synchronize their configurations — especially for indexer settings. This eliminates the need for manual syncing and ensures consistency across all running instances.

What should not be stored in the database:

  • Logs – these are short-lived and better suited to file-based storage
  • Cache – high-frequency, temporary data best handled by the filesystem

I believe optional PostgreSQL support would bring real value, especially for advanced or professional environments, while keeping things simple and unchanged for the majority of users.

Thanks for considering it!

Describe the solution you'd like

Best regards,
Sophie

Describe alternatives you've considered

No response

Metadata

Metadata

Assignees

No one assigned

    Labels

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions