Hi Adam, I completely agree with this direction. During my work on FINERACT-2517, I identified and resolved data consistency issues where legacy MySQL-compatible test data caused validation failures in PostgreSQL 18. This reinforces the need for a unified database strategy. Specifically, during that upgrade, I had to adjust date/year ranges in the integration tests because of how differently the engines handle certain constraints. Moving to a single, robust engine like PostgreSQL would allow us to:
- We can finally stop writing "lowest common denominator" SQL. - Native partitioning for m_journal_entry and advanced indexing would solve several performance bottlenecks I've seen in the COB processes. - As we saw in my recent PRs, running the test suite across three different database types (MySQL, MariaDB, Postgres) significantly slows down the feedback loop and increases the maintenance of our Liquibase scripts. If the community is open to this, I would be very interested in exploring this as part of my GSoC proposal. I could help draft a migration path for existing MySQL users or focus on refactoring a specific module to take full advantage of PostgreSQL's native features (like the sequences or partitioning you mentioned). It would simplify the codebase tremendously and allow us to focus on innovation rather than engine compatibility. Regards, Nidhi 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
