************Apache Fineract Community!*********** El vie, 13 mar 2026 a las 9:30, VICTOR MANUEL ROMERO RODRIGUEZ (< [email protected]>) escribió:
> 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 >>>>>>>> >>>>>>> >>>>>>>
