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] > <mailto:[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] >> <mailto:[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] <mailto:[email protected]> >> 972-768-6940
