Proposal: Moonfin × PG Provider — PostgreSQL backend and private storage for Moonbase

[BORNIOS]

Hi Moonfin team,

I'm the maintainer of Jellyfin Database Providers – PostgreSQL (PG Provider):

I've been following Moonfin and Moonbase for some time, and I think there is an opportunity for collaboration that goes beyond simply offering PostgreSQL as an alternative database backend for Jellyfin.

PG Provider was originally built to allow Jellyfin to run on PostgreSQL through Jellyfin's database provider architecture, without requiring a custom Jellyfin fork.

However, the project has evolved beyond that.

A PostgreSQL backend that plugins can also use

One of the most important capabilities now implemented by PG Provider is a public integration contract specifically designed for other Jellyfin plugins:

Jellyfin.Database.Providers.Postgres.Api.IPluginSchemaHost

Developer integration documentation

Through this API, a plugin can use PostgreSQL for its own persistent state without receiving the PostgreSQL connection string and without being given access to Jellyfin's public schema.

Each plugin receives its own private PostgreSQL schema, permanently associated with its plugin GUID.

PG Provider then provides the infrastructure around it:

• Private PostgreSQL schema per plugin
• Transactional and versioned schema migrations
• Parameterized queries and commands
• Isolation from Jellyfin's public schema
• Isolation from other plugin schemas
• Integration discovery and observability from the Jellyfin administration UI
• Inclusion of plugin schemas in PostgreSQL backups
• Administrator-controlled ANALYZE, VACUUM (ANALYZE) and REINDEX
• A capability/protocol model allowing integrations to detect whether PG Provider is available
• The ability for consuming plugins to retain their existing storage mechanism as a fallback when PG Provider is not installed

The intention is not to give plugins unrestricted database access.

Plugins should continue obtaining Jellyfin data through Jellyfin's normal contracts. PG Provider only provides managed PostgreSQL storage for data owned by the plugin itself.

Why I'm approaching Moonfin

This is the main reason I wanted to contact the Moonfin team.

Moonbase is exactly the kind of real server-side plugin that could help validate this architecture.

Rather than building another artificial example integration, I would be very interested in exploring whether Moonbase could optionally use PG Provider for some of its own persistent state when PostgreSQL is available, while keeping its current storage implementation as the fallback.

That would give both projects a real integration to work against.

For PG Provider, Moonbase would provide an important real-world consumer of the plugin storage contract.

For Moonfin, PG Provider could provide a managed PostgreSQL persistence layer without Moonbase having to manage PostgreSQL credentials, connections, maintenance policies or unrestricted database access itself.

Neither project would need to become dependent on the other.

A broader PostgreSQL collaboration

I'm also interested in having Moonfin evaluate PG Provider as an optional PostgreSQL backend for Jellyfin servers used by Moonfin users.

I don't expect Moonfin to simply declare PG Provider an official requirement or recommendation without evaluating it first.

What I'm proposing is a collaboration around:

• Testing Moonfin and Moonbase against PostgreSQL-backed Jellyfin installations
• Using Moonbase as a real consumer of the private plugin-schema API where appropriate
• Identifying limitations in the current integration contract
• Building integration and regression tests
• Finding PostgreSQL-specific performance opportunities through real workloads
• Improving observability and diagnostics
• Designing a more stable shared abstractions package for plugin integrations if the current contract proves useful
• Improving documentation for Moonfin users interested in PostgreSQL deployments

If the integration proves stable and useful, I would obviously appreciate Moonfin mentioning or recommending PG Provider as an optional solution for users interested in PostgreSQL.

But I would prefer that recommendation to come from real experience with the project rather than simply asking for an endorsement.

Why Moonfin specifically

Moonfin is an independent project with an active ecosystem around Jellyfin, and that independence is valuable for something like this.

I would like PG Provider to demonstrate through real-world adoption, integrations and production workloads that there is practical demand for a PostgreSQL-backed and extensible persistence model in the Jellyfin ecosystem.

If independent projects can demonstrate that this model works and solves actual problems, the technical discussion around PostgreSQL no longer has to remain theoretical.

Even if PG Provider itself is never adopted upstream, successful implementations can provide useful architecture, code, operational experience and evidence for anyone eventually working on a solution with the same purpose.

For me, that would already be a success.

Transparency about development

I also want to be transparent about how this project has been developed.

PG Provider has been created with substantial AI-assisted development — or "vibe coding", using the common term.

I don't want to hide that fact or present the project as something it isn't.

At the same time, I want the project to be evaluated on its architecture, behavior, tests, reproducibility and actual results rather than solely on how the code was produced.

One of the reasons I'm actively looking for collaboration is precisely to bring additional technical perspectives into the project.

I'm open to shared stewardship

I'm not only looking for users or promotion.

I'm open to giving experienced Moonfin contributors a much deeper role in PG Provider.

If members of the Moonfin team are interested and have stronger experience or a better architectural direction for parts of the project, I would welcome:

• Code reviews
• Design discussions
• Pull requests
• Changes to the public integration API
• Integration tests
• Performance work
• Security reviews
• Documentation improvements
• Architectural proposals

And, where there is mutual interest and sustained involvement, I'm also open to adding trusted Moonfin contributors as direct collaborators/maintainers of PG Provider.

I don't consider the current implementation untouchable.

If there is a better way to solve part of the problem, I want to hear it.

My objective is to make PostgreSQL a serious and practical option in the Jellyfin ecosystem, not to protect a particular implementation from change.

What I'd like to explore first

As a concrete first step, I'd like to discuss whether the Moonfin team would be interested in one or both of these experiments:

1. Run Moonfin/Moonbase against a Jellyfin server using PG Provider as its database backend.

This would help identify compatibility issues and provide real workload data.

2. Create an optional Moonbase integration with IPluginSchemaHost.

Moonbase could keep its existing storage implementation as the default/fallback, but use a private PostgreSQL schema when PG Provider is available.

That second experiment is particularly interesting to me because it would be the first substantial external validation of the plugin persistence architecture.

If either direction is interesting to you, I'm happy to work on the PG Provider side and adapt the API where necessary.

Thanks for taking the time to read this, and thanks for the work you're doing around Moonfin.

I'd be very interested in hearing your thoughts — including criticism of the current design.

— BORNIOS