Hello Mifos Community, There is no need to explain the technical advantages of Postgres (by the way I think that a very good Postgresql-like is CockroachDB) and for good reference we can use the Jepsen analysis https://jepsen.io/ .
I also share the concept of engineering "less pieces, less maintenance & and faster fixing" ;) After my last comments... I will share my thoughts after reading the Apache Fineract community's replies I am going to repeat my concerns that were not properly replied during the conversation *- We are promoting the Forks instead of sending upstream code* ----- How can we minimize this? I mean it seems that the only way to have end-user feedback now is using this devlist... which I think is not enough for this important change. The latest Apache Fineract survey shows that there are more forks rather the upstream code https://cwiki.apache.org/confluence/display/FINERACT/Survey+Results+2025+August *- Disruption to existing deployments* ----- How can we have a high level #number of deployments? How do we connect to that end user community? only the https://hub.docker.com/r/apache/fineract has 1M+ downloads The latest Apache Fineract shows that a user replied "Rather than MariaDB/MySQL only, either work with other RDBMS, or at least PostgreSQL" https://cwiki.apache.org/confluence/display/FINERACT/Survey+Results+2025+August so then seems that the user is unaware that PostgreSQL started to be supported since version 1.7 (four years ago) *- Complicating the user adoption and community backlash* ----- How can we do a smooth migration? https://hub.docker.com/_/mariadb - 1B+ https://hub.docker.com/_/mysql - 1B+ https://hub.docker.com/_/postgres - 1B+ MariaDB+MySQL > Postgresql so then Postgresql has less users... *- Technical and compatibility Issues (there are connectors or applications developed by financial institutions connected to the Apache Fineract DBs) * ----- If we are going to support 1 database, how are we going to communicate the "best practices" for that migration to the end users? How long will that migration take? we should mark as deprecated the MySQL/MariaDB for how long before ending the support? Should we have a Long Term Support version? Should we raise a new survey and now include which database is being used? *- 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).* ----- Same thoughts as previous one + The migration tool that we select/suggest should be compatible with the ASF? And for closing I would add --- "Mind the gap" A very British phrase, but it became a personal mantra. Not everyone sees, hears, interprets or processes a message the same way, especially in virtual rooms filled with different accents and cultures. I learned to listen beyond words, paying attention to intention, context and even the "silences" in the room. Tapping into the power of diversity becomes possible when people feel safe. Safe to speak imperfectly. Safe to disagree. Safe to be themselves. It sounds obvious, and yet we could practice it more. That is the reason that I quoted the reason that was given for the Mifos Apache Fineract code donation to the ASF. not about being tied to a DB or technology. I am looking for how we can move forward using PostgreSQL as the only supported DB and how we can provide a safe, smooth, painless (as much as possible) to those loyal Apache Fineract users. Regards Victor Romero El mié, 11 mar 2026 a las 22:23, Mohammed Saifulhuq (< [email protected]>) escribió: > Hi Adam and all, > > +1 to standardizing on PostgreSQL. > > Beyond the excellent points already raised regarding sequences and > partitioning, dropping lowest-common-denominator SQL support directly > solves critical performance bottlenecks in concurrent command processing. > > In mapping out the architecture for the system-wide Idempotency > Interceptor (FINERACT-2169), one of the biggest constraints of supporting > MySQL is relying on JVM exception handling (e.g., catching > DataIntegrityViolationException) to manage concurrent duplicate requests. > This introduces unacceptable stack trace overhead on the critical execution > path during high-throughput load. > > By standardizing on PostgreSQL, we can leverage native features like INSERT > ... ON CONFLICT DO NOTHING. This shifts the concurrency lock down to the > database engine and allows the Spring backend to evaluate a clean boolean > state ($O(1)$) rather than retroatively rolling back transactions and > throwing heavy JVM exceptions. > > This single PostgreSQL capability fundamentally changes how safely and > efficiently we can scale the core command engine. > > Regards, > > Mohammed Saifulhuq > > > > On Wed, Mar 11, 2026 at 7:42 PM Aman Mittal <[email protected]> > wrote: > >> Hi All, >> >> +1 for discussion, and + 1 for Postgresql (Only if proper migrations are >> tested enough). >> >> Regards, >> Aman >> >> On Wed, Mar 11, 2026 at 7:27 PM Aleksandar Vidakovic < >> [email protected]> wrote: >> >>> +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 >>>>>>> >>>>>> >>>>>>
