So...I think a decent choice to make here is to switch from OCaml to F#. You'll get almost all of the benefits and most of the drawbacks go away. And for the most part, you can directly translate the code from OCaml to F#.
The big reason to not use F# vs OCaml tends to come down to the lack of functors... but it looks like your current codebase might not be using them much.
I enjoy f# a lot, but it doesn't necessarily help with all of their problems.
One of the biggest problems they mention is with postgres. F# has a postgres problem as well.
Your options in f# for postgres usage include the following high-level categories:
• Dapper/RepoDb/Other community libs
• Typeprovider based like Fsharp.Data.Npgsql
• EF core (where you build the fsharp design-time support yourself)
• Using C# in another project as a database interaction abstraction
I've had to mix and match for the projects I've worked on because I've had trouble finding a single library where:
1) Joins are supported in a sane way
2) Batch inserts work
3) Interacting with native features (views, functions, SET variables) works
4) It's still in fsharp
It's not bad, but when I work on $DAYJOB projects in Typescript/etc where database access is smooth, I wonder how long it might take to rewrite for the database heavy projects.
Also should mention that I'm very thankful for the libraries that _do_ exist, and the effort put into making them as feature as they are. It's just one of the areas that I don't think is a strength of F# right now.