Switching to a proprietary database, instead of PostgreSQL
Summary
During the Cells project multiple people suggested evaluating alternatives to our current database architecture. The current platform is organically grown and optimizations or a new architecture are required.
However, some suggestions went beyond changing the underlying platform (e.g., VM to container) or the automation (e.g., Chef to k8s operator), but to migrate away from PostgreSQL to a different or even proprietary database.
From my point of view we should decide if this step is wanted and beneficial, before we invest significant time into evaluating multiple solutions.
Some obvious disadvantages
- Every property database will be the road less traveled, by at least an order of magnitude
- Vendor lock-in
- Moving away from a managed DB is hard, from a proprietary even more
- Dependency on a single vendor, and their pricing
- Even if a DB claims to be somewhat compatible, at one point in time we need to make specific optimizations. Do we want to support multiple databases in our application, or do we want to force our customers to use proprietary infrastructure?
Considerations
- Do we anticipate that our requirements in the next X years are not solvable with PostgreSQL?
- Do we anticipate that a proprietary DB will reduce our costs, over the next X years?
- Does this impact our standing in the Open Source Community negatively?
- Do we anticipate that this change will be seen positive or negative by our customers?
Context
Edited by Alexander Sosna