+1 for this discussion. Thank you Victor for outlining the concerns and Adam S for the response.
For me it boils down to the importance of building a community of experts and maintaining forward motion. If Postgres is now the *defacto* best technical solution, AND IF moving to only Postgres materially accelerates our dev and maintainability of the project, then I would be a +1. If this move causes us to lose a known set of in-depth knowledge, contributions, and expertise, I would vote against it perhaps. Victor's message starts to make that case but I don't know what contributors or contributions we lose. And, I don't see database neutrality as an inclusive value in itself. Is postgres that much harder to run in production? I also want to highlight a key part of Adam Monsen's message: *Assuming we decide to proceed, users should also step up and volunteer to > write or sponsor mariadb/mysql to postgresql migration guides, scripts, > case studies, etc.* Also, when we first started the project, one of our key people on the project (v1) was the developer of Mayfly, an in-memory database, in 2005. So we used that. My point is that tech change is a constant. How fast we move to replace key pieces is always a healthy debate topic. I think we need to focus now on accelerating contributions and maintainability. James On Tue, Mar 10, 2026 at 11:58 AM Ádám Sághy <[email protected]> wrote: > Hi Victor, > > Thank you very much for sharing your concerns. > > Let me try to organize my thoughts into three areas. > 1. MySQL and MariaDB are holding Fineract back > > In my opinion, continuing to support MySQL and MariaDB is keeping Fineract > anchored to limitations that no longer make much sense for the project. > > One major example is the *lack of proper sequence support for primary key > generation*. PostgreSQL supports real database sequences, while MySQL and > MariaDB rely on auto-increment columns. Because of this, we have to > implement workarounds that introduce additional flushes during transactions > and limit ORM optimizations. This is not just a minor inconvenience: it > directly affects performance and architecture. > > PostgreSQL is simply more capable in many of the areas that matter for > systems like Fineract. > > Some examples: > > *Transactional integrity * > PostgreSQL has historically been stronger in strict ACID compliance and > transactional behavior. This includes: > > - > > more consistent MVCC (multi-version concurrency control) > - > > better handling of complex concurrent transactions > - > > stronger locking and isolation guarantees > > *Sequences and ID generation* > > PostgreSQL sequences allow: > > - > > ID generation without locking tables > - > > efficient ORM optimizations > - > > fewer flushes and fewer round-trips to the database > > In contrast, MySQL and MariaDB rely on auto-increment columns which: > > - > > are tied to the table > - > > can introduce contention > - > > prevent some ORM optimizations > > In systems with high transaction throughput this can noticeably affect > performance. > > *Query planning and complex queries* > > PostgreSQL generally has a more advanced query optimizer and performs > better with: > > - > > complex joins > - > > analytical queries > - > > large datasets > - > > advanced indexing strategies > > MySQL historically optimized more for simpler read-heavy workloads. > > *Advanced database capabilities* > > PostgreSQL provides a number of features that are either missing or less > mature in MySQL/MariaDB: > > - > > JSON/JSONB with indexing > - > > partial indexes > - > > expression indexes > - > > common table expressions (CTEs) > - > > window functions > - > > materialized views > - > > rich extension ecosystem > > This makes PostgreSQL much more flexible for systems that evolve over time. > > *Extensibility* > > PostgreSQL was designed to be extensible. Extensions such as: > > - > > PostGIS > - > > TimescaleDB > - > > pg_partman > - > > pgvector > > allow the database to grow with new requirements. > 2. What is best for the community? > > This part is more *complicated*. > > I understand the concern that if MySQL/MariaDB support is removed, some > users might choose to fork rather than migrate. That is a valid risk. > > But we should also ask ourselves: *is standing still the right decision > for the project?* > > Personally, I would be very interested to hear from users, developers, and > maintainers about how they see this. > > From my perspective, a *single database backend* would bring several > benefits: > > - > > simpler code > - > > more reliable testing > - > > fewer edge cases > - > > faster development > > Focusing on one well-supported database would allow us to fully leverage > its capabilities instead of constantly working around cross-database > differences. > > At the same time, I fully acknowledge that asking users to migrate > databases is not a small request. It is a significant operational task. > > But it would still be helpful to understand the situation better: > > - > > *Who are our users today?* > - > > *How many of them rely on MySQL/MariaDB?* > - > > *How many of them would realistically be unable to migrate?* > > Without understanding that, it is difficult to judge the real impact. > 3. Where should Apache Fineract go in the next five years? > > You referenced the goal of: > > “foster a larger, more collaborative developer community, ensure long-term > sustainability, and accelerate the commoditization of core banking > infrastructure for financial inclusion.” > > I can agree with that vision. > > However, nothing in that statement suggests that the project must > permanently support *three different database engines*. > > Just because a technical decision was made ten years ago does not > necessarily mean it should remain unchanged forever. Revisiting earlier > architectural choices is a normal part of evolving a project. > > So the real question might be: > > Do we want Apache Fineract to remain conservative and maintain the status > quo, or are we willing to make changes that prepare it for *larger > deployments, higher load, and more demanding use cases*? > > If Fineract is going to serve institutions operating at high scale and > handling large volumes of financial data, then we should make sure the > platform is able to support that direction. > > At the same time, I absolutely agree that this discussion should not be > purely technical. We should also consider what kind of project we want > Apache Fineract to be and what kind of ecosystem we want to foster around > it. > > Sometimes it is worth asking whether all the historical baggage we carry > is still necessary, or whether some of it should be left behind so the > project can move forward more effectively. > > Apologies if this became a bit philosophical at the end, but I do think it > is important that we consider not only the technical details but also the > long-term direction of the project. > > > Regards, > Adam > > On Mar 10, 2026, at 7:00 PM, VICTOR MANUEL ROMERO RODRIGUEZ < > [email protected]> wrote: > > Hello, > > *I don't agree with this proposal.* Because keeping all three databases > promotes Fineract's goal of being a versatile, inclusive platform. This > proposal looks like a shortcut for us as developers. > > Removing MySQL and MariaDB would likely outweigh the benefits of > simplification, given the financial sector's emphasis on stability, choice, > and minimal disruption. > > Apache Fineract have loyal users that have been migrating since the first > versions of "Mifos" before it became an Apache project which I think the > original objective of that donation was to have a "foster a larger, more > collaborative developer community, ensure long-term sustainability, and > accelerate the commoditization of core banking infrastructure for financial > inclusion. By moving to Apache, the platform gained neutral governance and > increased industry adoption." taken from > https://groups.google.com/g/mifosdeveloper/c/-_9a-4tldSo > > Fineract's architecture emphasizes database-agnostic design where > possible, using tools like Liquibase (another pain point now) for schema > migrations and standard SQL features that work across these databases. > > Overall, Apache Fineract's multi-database approach reflects Apache > projects' emphasis on inclusivity, allowing Fineract to serve a global user > base without forcing migrations or custom forks. > > If we go in that way (dropping the support of MySQL and MariaDB ) > > - We are promoting the Forks instead of sending upstream code > - Disruption to existing deployments > - Complicating the user adoption and community backlash > - Technical and compatibility Issues (there are connectors or application > developed by financial institution connected to the Apache Fineract DBs) > - Add security implications - Financial regulations often require audited, > stable setups. Abrupt changes could erode trust, especially if users face > security threats during migrations (e.g., exposed credentials or incomplete > data transfers). > > > Limiting Apache Fineract to PostgreSQL might hinder integrations with > MySQL/MarioDB-centric tools in fintech stacks, increasing costs for custom > workarounds, some small financial institutions will be impacted not only > techically but also economically. > > Just some thoughts why we should keep the support of the two Databases > Mysql/MariaDB. > > Regards > > El mar, 10 mar 2026 a las 10:58, Edward Kang (<[email protected]>) > escribió: > >> Hi Adam, >> >> Just chiming in with my experience with this issue as well. We saw in >> FINERACT-274 that there are issues with MariaDB and MySQL behavior on >> transaction DDL commits. Just another reason to swap over to Postgres in my >> opinion. >> >> Best, >> Edward >> >> >> >> On Tue, Mar 10, 2026 at 11:38 AM Adam Monsen <[email protected]> wrote: >> >>> +1 >>> >>> ...for reasons mentioned by others including simpler maintenance and the >>> ability to leverage useful postgresql-specific features. We're tasked with >>> making difficult decisions to be able to maintain our code, including >>> (IMHO) trimming fat like multiple database support. >>> >>> >>> Bharath and Awasum also brought up good points about existing >>> installations depending on other databases. >>> >>> Users (e.g. banks / vendors / other paid support orgs) should chime >>> *here, now* with their real-world needs and data to help inform our >>> decision. Assuming we decide to proceed, users should also step up and >>> volunteer to write or sponsor mariadb/mysql to postgresql migration guides, >>> scripts, case studies, etc. >>> >> >> >> -- >> Edward E. Kang >> [email protected] >> 972-768-6940 >> > >
