Hi Adam, I am strongly in favor of this proposal. As a contributor currently working on the progressive loan schedule (FINERACT-2520), I have experienced firsthand how the differences in database engines complicate the development and testing cycle.
In my recent PR, I encountered unit test failures in the CI (test-core-4) specifically due to how different databases handle decimal precision and trailing zeros. Standardizing on PostgreSQL would drastically simplify these assertions and provide a much more consistent feedback loop for new contributors. I would be happy to assist with any cleanup of the loan module tests or schema refactoring if the community decides to move forward with this direction. Regards, Vignesh On Tue, Mar 10, 2026 at 6:34 PM Awasum Yannick <[email protected]> wrote: > +1 > > What to do with legacy deployments already on MySQL or Maria DB and will > want to upgrade in the near future to latest Fineract (running postgres if > we make the move)? > > Are we going to provide scripts to enable the move? Or just move and leave > that for every provider to handle migration on their own? This may lead to > more private forks... > > Need to think about this carefully. > > On Tue, 10 Mar 2026, 13:43 Ambika, <[email protected]> wrote: > >> I strong support this proposal.As a contributor currently working on API >> standardization (FINERACT-2494) and warning cleanups (FINERACT-2510), I’ve >> experienced firsthand how maintaining multi-engine support slows down the >> development cycle. In my recent PRs, a significant portion of the CI >> failures and rebase conflicts originated from infrastructure-specific >> issues in the MariaDB/MySQL test suites that aren't present in PostgreSQL. >> >> Consolidating to PostgreSQL would not only allow us to use advanced >> features like sequences and native partitioning as Adam mentioned, but it >> would also drastically improve the contributor experience by providing a >> more stable and faster CI feedback loop. >> >> I'm also interested in helping with any cleanup or testing required if we >> move forward with this direction. >> >> On Tue, Mar 10, 2026 at 5:23 PM Tito Mari Francis Escaño < >> [email protected]> wrote: >> >>> In addition to the cited PostgreSQL features, since Fineract is a >>> financial service platform, for example, the use of timestamptz would >>> enable a transaction entry to be flexibly viewable relative to the timezone >>> of the viewer, greatly simplifying the computation of time-sensitive and >>> -dependent data more efficiently. >>> I was frankly wondering why use MySQL/MariaDB when PostgreSQL provides >>> features that make it more efficient and powerful. >>> Thanks for bringing this up, Adam. >>> >>> On Tue, Mar 10, 2026 at 7:40 PM Bharath Gowda <[email protected]> wrote: >>> >>>> Hi Adam, >>>> >>>> In my opinion, it makes sense to move towards supporting a single >>>> database. >>>> However, I believe we should also provide database migration options >>>> and steps for organizations that want to upgrade to the latest version of >>>> Fineract from their existing MySQL-based Fineract deployments. >>>> >>>> >>>> >>>> Regards, >>>> Bharath >>>> Lead Implementation Analyst | Mifos Initiative >>>> PMC Member | Apache Fineract >>>> Mobile: +91.7019635592 >>>> http://mifos.org <http://facebook.com/mifos> >>>> <http://www.twitter.com/mifos> >>>> >>>> >>>> On Tue, Mar 10, 2026 at 4:53 PM Ádám Sághy <[email protected]> wrote: >>>> >>>>> Hi >>>>> >>>>> I’d like to propose that we move Apache Fineract to PostgreSQL as the >>>>> single supported database and stop maintaining MySQL/MariaDB support. >>>>> Maintaining support for multiple database engines (MySQL, MariaDB, and >>>>> PostgreSQL) adds ongoing complexity to Fineract without providing real >>>>> benefits. >>>>> >>>>> PostgreSQL can handle everything we currently rely on from >>>>> MySQL/MariaDB, and it also provides stronger database features that we >>>>> could start using if we were not constrained by multi-engine support. >>>>> Supporting several databases increases the effort required for >>>>> development, testing, schema migrations, and debugging. It also introduces >>>>> subtle differences in SQL behavior that we constantly need to work around. >>>>> PostgreSQL is simply a better fit for a system like Fineract. >>>>> >>>>> A few examples: >>>>> >>>>> - Sequences / identity columns for primary keys >>>>> - PostgreSQL has proper sequence support and identity columns, >>>>> which provide clearer and more flexible primary key generation than >>>>> MySQL-style auto-increment. >>>>> - Native table partitioning >>>>> - PostgreSQL has mature built-in partitioning that could help >>>>> with large tables such as journal entries or transaction tables, >>>>> making >>>>> long-term scaling and maintenance easier. >>>>> - More advanced indexing options >>>>> - PostgreSQL supports partial indexes, expression indexes, and >>>>> better JSON capabilities, which can help with query performance and >>>>> reporting use cases. >>>>> >>>>> >>>>> Given this, it would make sense to move toward PostgreSQL as the >>>>> single supported database. >>>>> This would simplify the codebase, reduce maintenance work, and allow >>>>> the project to take advantage of features that PostgreSQL already >>>>> provides. >>>>> >>>>> What do think? >>>>> >>>>> Regards, >>>>> Adam >>>>> >>>>
