Hello! Just one quick note about the migration tool mentioned, pgloader, In my experience is not to useful when you have huge amount data, mainly for transactions, journal entries, accounts, etc
But yes Ideally we need a plan and migration guide Thanks and best regards Alberto On Fri, Mar 13, 2026 at 11:37 AM Aleksandar Vidakovic < [email protected]> wrote: > ... reposting to the public list: > > ... I'm still in "camp PostgreSQL"... but I'd like to add - after reading > Victor's notes - maybe a couple of requirements (maybe everyone already > thought about them, but don't remember that we wrote them down here): > > - removing MySQL/MariaDB can't happen overnight (aka in the next release), > but needs some planning to understand what the blast radius is; we need to > investigate any connectors/integrations out there that we know of and see > how dependent they are on those specific databases > - if we can't provide patches ourselves then maybe we can provide at least > migration instructions > - for migrating fineract data in MySQL/MariaDB to PostgreSQL I suggest to > look into PGLoader; this is something (I think) we cannot ignore and has to > be provided by us... including battle testing the solution and giving > instructions (aka documentation)... or even a way how to (mostly) automate > this transfer > > Maybe there are more bullet points? These are the ones that come up on my > radar for now... > > Cheers, > > Aleks > > On Fri, Mar 13, 2026 at 4:33 PM VICTOR MANUEL ROMERO RODRIGUEZ < > [email protected]> wrote: > >> ************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 >>>>>>>>>> >>>>>>>>> >>>>>>>>>
