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
Porter currently only supports MongoDB, but we're implementing direct PostgreSQL support due to limitations with MongoDB-compatible layers like FerretDB. This change will offer more deployment options, better licensing terms, and wider compatibility with other databases. We're actively working on this in our fork, aiming to merge it back into the main Porter repository. This will increase Porter's adoption, reduce vendor lock-in, and provide more performance and scalability options. We're seeking collaboration from the Porter community on this implementation.
Background
Currently, Porter strictly supports MongoDB as its database backend. While considering options for database expansion, I extensively tested FerretDB as a potential MongoDB-compatible layer for PostgreSQL. However, this approach proved problematic for several reasons:
Edge Cases: FerretDB has limitations that impact functionality, such as the rule that "keys should not contain dots". This and other edge cases make it challenging to use as a drop-in replacement for MongoDB.
Debugging Difficulties: I encountered a hard-to-debug "out of bounds" index issue, which raises concerns about production readiness and maintainability.
Deployment Complexity: Running FerretDB as a sidecar proxy next to Porter is not a clean solution and would likely result in a poor user experience compared to native PostgreSQL support.
These findings have led to the decision to implement direct PostgreSQL support in Porter, which will provide a more robust and user-friendly solution.
Rationale for PostgreSQL Support
There are several compelling reasons to expand our database support to include PostgreSQL:
PostgreSQL: There are more mature and widely-adopted options, such as the CloudNativePG operator, among others.
While Porter isn't strictly tied to Kubernetes, its dependency decisions significantly influence its adaptability and adoption supported by the availability of hardened k8s controllers
Wire Protocol Compatibility:
PostgreSQL's wire protocol compatibility opens up possibilities for using other databases such as:
Open Source Licensing:
PostgreSQL's more permissive license is often preferred in enterprise environments concerned about licensing restrictions.
Enterprise Adoption and Ecosystem:
PostgreSQL's widespread adoption in enterprise environments comes with a rich ecosystem of tools, extensions, and third-party support, beneficial for development and maintenance.
Managed Services Availability:
There are more fully managed PostgreSQL services available across cloud providers, which can ease adoption and management for businesses.
Current Implementation and Proposed Changes
The current architecture includes interfaces like storage.InstallationProvider that could potentially support PostgreSQL. However, the lower-level storage.Store interface is tightly coupled to MongoDB-specific concepts.
Implementation Plan
I am actively working on implementing PostgreSQL support in our fork of Porter. This is not a proposal, but a notification of ongoing work with the intention of merging these changes back into the main Porter repository.
The implementation will follow these steps:
Implement the storage.InstallationProvider, storage.ParameterSetProvider, storage.CredentialSetProvider interfaces for PostgreSQL.
Refactor the use of the storage.Store and storage.Provider interfaces to be less dependent on them.
Benefits of Database Flexibility
Wider Adoption: Supporting PostgreSQL could make Porter more attractive to organizations that prefer or require PostgreSQL or its wire-compatible alternatives. (re: Our CNCF status is based on having adopters.Are you using Porter? #1596)
Reduced Lock-in: Offering multiple database options reduces vendor lock-in concerns and aligns with cloud-native principles of flexibility and choice.
Performance and Scalability Options: Different databases may offer varying performance and scalability characteristics, giving users more optimization possibilities for their specific use cases.
Call for Collaboration
While I am proceeding with the implementation, I welcome collaboration and input from the Porter maintainers and community. Your expertise and insights would be valuable in ensuring that this enhancement aligns well with Porter's architecture and future direction.
Next Steps for the Porter Team
Review the proposed changes and provide feedback on the approach.
Discuss any potential challenges or considerations for integrating PostgreSQL support into the main Porter codebase.
I believe this enhancement will significantly benefit Porter and its users, enhancing its appeal in various deployment scenarios and enterprise environments. I look forward to working with the team to integrate these changes and expand Porter's database flexibility.
@robinbraemer Thank you so much for taking a stab at that. It is one of the things, that we never really got around to, but talk about once in a while.
It would be a great addition to Porter. Looking forward to see more details, and hope it will open up for other types of storage implementations, both relational and non-relational storage types 🤞
@robinbraemer Again thank you for working on this. Would it be possible for you to attend the community meeting tomorrow, Thursday, 6PM CEST? Where a couple of the maintainers will be present
TL;DR:
Porter currently only supports MongoDB, but we're implementing direct PostgreSQL support due to limitations with MongoDB-compatible layers like FerretDB. This change will offer more deployment options, better licensing terms, and wider compatibility with other databases. We're actively working on this in our fork, aiming to merge it back into the main Porter repository. This will increase Porter's adoption, reduce vendor lock-in, and provide more performance and scalability options. We're seeking collaboration from the Porter community on this implementation.
Background
Currently, Porter strictly supports MongoDB as its database backend. While considering options for database expansion, I extensively tested FerretDB as a potential MongoDB-compatible layer for PostgreSQL. However, this approach proved problematic for several reasons:
These findings have led to the decision to implement direct PostgreSQL support in Porter, which will provide a more robust and user-friendly solution.
Rationale for PostgreSQL Support
There are several compelling reasons to expand our database support to include PostgreSQL:
Kubernetes Deployment Options:
Wire Protocol Compatibility:
PostgreSQL's wire protocol compatibility opens up possibilities for using other databases such as:
Open Source Licensing:
PostgreSQL's more permissive license is often preferred in enterprise environments concerned about licensing restrictions.
Enterprise Adoption and Ecosystem:
PostgreSQL's widespread adoption in enterprise environments comes with a rich ecosystem of tools, extensions, and third-party support, beneficial for development and maintenance.
Managed Services Availability:
There are more fully managed PostgreSQL services available across cloud providers, which can ease adoption and management for businesses.
Current Implementation and Proposed Changes
The current architecture includes interfaces like
storage.InstallationProvider
that could potentially support PostgreSQL. However, the lower-levelstorage.Store
interface is tightly coupled to MongoDB-specific concepts.Implementation Plan
I am actively working on implementing PostgreSQL support in our fork of Porter. This is not a proposal, but a notification of ongoing work with the intention of merging these changes back into the main Porter repository.
The implementation will follow these steps:
storage.InstallationProvider
,storage.ParameterSetProvider
,storage.CredentialSetProvider
interfaces for PostgreSQL.storage.Store
andstorage.Provider
interfaces to be less dependent on them.Benefits of Database Flexibility
Our CNCF status is based on having adopters.
Are you using Porter? #1596)Call for Collaboration
While I am proceeding with the implementation, I welcome collaboration and input from the Porter maintainers and community. Your expertise and insights would be valuable in ensuring that this enhancement aligns well with Porter's architecture and future direction.
Next Steps for the Porter Team
I believe this enhancement will significantly benefit Porter and its users, enhancing its appeal in various deployment scenarios and enterprise environments. I look forward to working with the team to integrate these changes and expand Porter's database flexibility.
Checklist
The text was updated successfully, but these errors were encountered: