Replies: 8 comments 10 replies
-
|
I agree that Postgres should ultimately be the database for the registry. I really like how Musicbrainz does their db and would opt for traditional RDBS tables. They also do a dump twice a week, which I think would be a cool idea for the registry as well. I think for now, Mongo is ok while we work on the data that needs to be exposed to MCP Hosts for successful installation. Maybe once #3 is settled, we can model it in Postgres. We're also in discussions with a couple of platforms about hosting options, so it would be good to decide on Postgres to ensure it's available in the environment we go with. |
Beta Was this translation helpful? Give feedback.
-
|
+1 for this feature, this would at least help my organization to onboard the implementation. |
Beta Was this translation helpful? Give feedback.
-
|
Why is the suggestion to move from one DBMS to another. How about a DBMS-independent approach? |
Beta Was this translation helpful? Give feedback.
-
|
I agree with this proposal, think it is good! I think the reasons that are most convincing to me are:
I'd also add:
Would be keen for us to make a hard decision to commit or not to Postgres. Probably leaning yes given both me (Anthropic) and Toby (GitHub) already agree? And I think Tadas (PulseMCP) was open/supportive, although not sure. I'm going to go ahead assuming we're all in alignment/agreed on this, but shout if not. |
Beta Was this translation helpful? Give feedback.
-
Alternative Approach: Support Multiple MongoDB-Compatible BackendsSummaryInstead of migrating from MongoDB to PostgreSQL, support both through MongoDB wire protocol compatibility. This solves SSPL licensing concerns while preserving existing work and requiring zero application code changes. ProposalThe MCP Registry already uses MongoDB drivers through an abstracted database interface. Self-hosters can choose their preferred backend: Option 1: MongoDB (Current/Default)
Option 2: FerretDB + PostgreSQL (New)
How It WorksFerretDB is a transparent proxy that:
The application is completely unaware which backend is being used. ImplementationStep 1: Add FerretDB Docker Compose Configuration
Step 2: Update DocumentationAdd to README.md:
Step 3: Add CI Testing (Optional but Recommended)
That's it. No other changes needed. Pros and ConsPros✅ Zero code changes - Application code remains identical Cons
Comparison to Full PostgreSQL Migration
About FerretDB
FerretDB was specifically created to address MongoDB's SSPL licensing concerns:
Response to RFC Concerns"Licensing and community preference" "Broader adoption" "Taking advantage of early stage" "PostgreSQL benefits (mature tooling, replication)" "Go implementation considerations" Why I Think This Is Better Than Replacing MongoDB Outright
RecommendationImplement this proposal first, then evaluate full migration later if needed. This gives the project:
The registry can support both options indefinitely, or transition to PostgreSQL-only in the future if evidence shows it's beneficial. Next StepsIf this approach is acceptable:
Estimated effort: 1-2 weeks of work vs. months for full migration Questions for discussion:
Would this alternative approach work for the community's needs? |
Beta Was this translation helpful? Give feedback.
-
|
Is there a reason why this couldn't simply be DBMS independent via the following?
|
Beta Was this translation helpful? Give feedback.
-
|
Heya, on the recent discussion about supporting multiple DBs see this from the FAQ:
We discussed yesterday at the MCP summit building a better registry for self-hosting, that could more easily aggregate MCP servers from different sources. E.g. for internal private deployments. Perhaps we should start another thread about this? (cc @rdimitrov who has more context here) |
Beta Was this translation helpful? Give feedback.
-
|
Closing this discussion as we did end up implementing the RFC to move from MongoDB to PostgresSQL, I think discussions regarding self-hosting with other databases probably should go into a separate discussion. Again, this is not currently supported but we'd be open to a separate project pursuing this (perhaps with better controls for moderation, filtering and aggregating from multiple registries - and less on publishing itself. i.e. features more tailored to subregistries). |
Beta Was this translation helpful? Give feedback.
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
-
Pre-submission Checklist
Your Idea
RFC: Migrating MCP Registry from MongoDB to PostgreSQL
Summary
This RFC proposes migrating the MCP Registry from MongoDB to PostgreSQL.
Background
The MCP Registry is currently implemented using MongoDB as its database backend. The project is in early development stages with no production deployments, making this an opportune moment to reconsider our database technology choice before wider adoption.
Motivation
Several factors motivate this proposed change:
Technical Details
Data Modeling Options in PostgreSQL
PostgreSQL offers multiple approaches that can accommodate our needs:
JSONB for Document Storage:
Traditional Relational Model:
Hybrid Approach:
Scaling and Performance
Go Implementation Considerations
Benefits
Risks and Mitigations
Open Questions
Which PostgreSQL data modeling approach is most appropriate for the registry?
What specific performance characteristics are most important for the registry?
What deployment environments must we support?
Who will be responsible for implementing this change?
References
Scope
Beta Was this translation helpful? Give feedback.
All reactions