+1... mostly because we currently have 3-4 different ways to write database queries... that means we currently maintain 3 (query types) x 2 (database systems) = 6 technology stack combinations (I know, JPA... still)... down the road there might be a low hanging fruit to get MySQL back on board with QueryDSL, if somebody is interested enough... at that point support for it (MySQL) would become more configuration than the current mix of code and configuration. Even if that happens I would maintain this in a different repo...
I'd still favor PostgreSQL only, that would make the introduction of type safe queries also a ton easier. And then there are more reasons: - proper support for JSON column types (could one day make data tables a thing of the past... just saying) - PG 18 has support for UUID v7 (our current IDs are pretty much all guessable...) - pgvector extension for AI applications (read: we would not be forced to introduce something else like Milvus, Pinecone or other vector storages) - ... and finally PG's transaction performance is a lot higher than MySQL's (I want to say 4x... but not sure anymore where I read this...) ... here's a nice feature comparison: https://www.bytebase.com/blog/postgres-vs-mysql/ As for data migration: for those who have production systems on MySQL: have a look at this https://pgloader.io ... should allow you to migrate without any downtime... of course needs to be battle tested, but if this works then basically no additional work for us other than documenting things a bit. Cheers, Aleks On Tue, Mar 10, 2026 at 11:28 PM Attila Budai <[email protected]> wrote: > Hi all, > > +1 for this discussion, and +1 for moving to PostgreSQL-only, provided we > do it with a proper migration path. > > I looked into some statistics which might help inform the decision. > > Based on the Stack Overflow Developer Survey, there is a clear trend > toward PostgreSQL: > > - In 2018, PostgreSQL had 33% developer usage vs MySQL at 59%. > - By 2025, PostgreSQL reached 55.6% vs MySQL at 40.5% > > Based on the stats the trajectory is clear. > > Beyond current usage, PostgreSQL's extension ecosystem opens doors that > MySQL/MariaDB simply cannot. pgvector, for example, enables native vector > similarity search — directly relevant if Fineract ever integrates > AI-powered features like fraud detection, credit scoring models, or > semantic search over loan documents. MySQL 9.x technically added a VECTOR > type, but it lacks HNSW indexing, meaning searches scale linearly — > unusable in practice at any real dataset size. > > Regarding Victor's valid concerns about disruption: there is a > well-documented precedent. OpenProject — an open-source project management > platform — deprecated MySQL in version 9.0 (2019) and removed it in version > 10.0. They provided pgloader-based migration scripts, detailed guides for > every installation type (packaged, Docker, legacy), and gave users a full > major release cycle to migrate. The transition was successful with no > significant community split. Their reasoning was identical to ours: > inability to leverage advanced SQL features due to cross-database > compatibility constraints. > > I think the key lesson from OpenProject is that the *how* matters as much > as the *what*. A phased approach — declare deprecation now, ship migration > tooling, remove support 1-2 releases later — would address most of the > concerns Victor raised while still giving the project a clear path forward. > > Regards, > Attila > > > James Dailey <[email protected]> ezt írta (időpont: 2026. márc. 10., K, > 21:32): > >> +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 >>>> >>> >>>
