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