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 >> >
