What would it take for you to adopt Marten?

[jeremydmiller]

Starting a bigger conversation about what it would take to grow Marten adoption into larger, more conservative .Net shops.

The Marten community is working very hard on our forthcoming (and long delayed) V4.0 release. We've already made some big strides on the document database side of things, and now we're deep into some significant event store improvements (this link looks best in VS Code w/ the Mermaid plugin active).

I'd really like to hear from other folks what it would really take for them to seriously consider adopting Marten. What is Marten lacking now that you would need, or what kind of community or company support options would be necessary for your shop to use Marten in projects? I'm happy to hear any and all feedback or suggestions from as many people as I can get to respond.

Existing Strengths

• Marten is only a library, and at least for the document database features it's very unobtrusive into your application code compared to many other persistence options
• The Marten community is active and I hope you'd say that we're welcoming to newcomers
• By building on top of Postgresql, Marten comes with good cloud support from all the major cloud providers and plenty of existing monitoring options
• Marten comes with many of the very real productivity advantages of a NoSQL solution, but has very strong transactional support from Postgresql itself
• Marten's event sourcing functionality comes "in the box" and there's less work to do to fully incorporate event sourcing -- including the all important "read side projection" support -- into a .Net architecture than many other alternatives
• Marten is part of the .Net Foundation
• If you need commercial support for Marten, you can engage with Calavista Software.

Does any of that resonate with you? If you've used Marten before, is there anything missing from that list? And feel free to tell me you're dubious about anything I'm claiming in the list above.

What's already done or in flight

• We made a lot of improvements to Marten's Linq provider support. Not just in terms of expanding the querying scenarios we support, but also in improving the performance of the library across the board. I know this has been a source of trouble for many users in the past, and I'm excited about the improvements we've made in V4.
• The event store functionality will get a lot more documentation -- including sample applications -- for V4
• An important part of many event sourcing architectures is a background process to continuously build "projected" views of the raw events coming in. The current version of Marten has this capability, but it requires the user to do a lot of heavy architectural lifting to use it in any kind of clustered application. In V4, we'll have an in the box recipe that will be used to do leader election and work distribution through an application cluster in "real server applications."
• Using native Postgresql sharding for scalability, especially for the event store
• Allowing users to specify event archival rules to keep the event store tables smaller and more performant
• Adding more integration with .Net's generic HostBuilder and standard logging abstractions for easier integration into .Net applications
• Improving multi-tenancy usage based on user feedback
• Document and event store metadata capabilities like you'd need for Marten to take part in end to end Open Telemetry tracing within your architecture.
• More sample applications. To be honest, I'm hoping to find published reference applications built with Entity Framework Core and shift them to Marten. This might be part of an effort to show Jasper as a replacement for MediatR or NServiceBus/MassTransit as well.
• And again, does any of that address whatever concerns you might have about adopting Marten? Or that you'd already had in the past?

Other Ideas?

Here are some other ideas that have been kicked around for improving Marten usage, but these ideas would probably need to come through some sort of Marten commercialization or professional support.

• Cloud hosting recipes. Hopefully through Calavista projects, I'd like to develop some pre-built guidance and quick recipes for standing up scalable and maintainable Marten/Postgresql environments on both Azure and AWS. This would include schema migrations, monitoring, dynamic scaling, and any necessary kind of database provisioning. I think this might get into Terraform/Pulumi infrastructure as well.
• Cloud hosting models for parallelizing and distributing work with asynchronous event projections. Maybe even getting into dynamic scaling.
• Multi-tenancy through separate databases for each client tenant. You can pull this off today yourself, but there's a lot of things to manage. Here I'm proposing more cloud hosting recipes for Marten/Postgresql that would include schema migrations and distributed work strategies for processing asynchronous event projections across the tenant databases.
• Some kind of management user interface? I honestly don't know what we'd do with that yet, but other folks have asked for something.
• Event streaming Marten events through Kafka, Pulsar, AWS Kinesis, or Azure Event Hubs
• Marten Outbox and Inbox approaches with messaging tools. I've already got this built and working with Jasper, but we could extend this to MassTransit or NServiceBus as well.

[cocowalla]

what it would take to grow Marten adoption into larger, more conservative .Net shops

The more conservative Microsoft shops are unlikely to use anything other than SQL Server or CosmosDB. I fully realise it would of course be a huge undertaking to make something like that happen, but I'm sure someone else would have brought it up 😃

[Hawxy]

We've recently settled on PostgreSQL as the standard database technology over SQL Server, so getting teams to decide between Marten and EF Core is left up to the project's requirements and not much else.

The biggest thing I've heard from people outside of work that looked at Marten and decided against it were the quality/look of the docs. Some people get the perception that Marten is "old technology" or "barely maintained" due to the docs looking fairly dated in the OSS world and not having a great layout.

I don't know how much Jeremy is attached to his own documentation system, but I've looked into it, and moving from the current documentation system to a more industry-standard one like Vuepress with the layout/design people tend to expect wouldn't really take too long. It's something myself and other community members could pick up whilst Jeremy + core maintainers are busy with V4 work.

Cloud hosting recipes

This is a big one for us. We use Pulumi, Github Actions and Octopus Deploy and guidance/best practices for using Marten in production would be truly useful.

[Hawxy]

Criticizing my web layout skillset is like picking on the very smallest kid in your class.

Haha, I didn't mean to imply anything regarding your web design skills. I'm personally coming from the perspective that stdocs is yet-another-thing for you to maintain on top of the libraries themselves.

The big thing that stdocs gives us is the navigation elements and the live code samples that are extracted from the actual code. Whatever you think is "better", absolutely must solve that code sample inclusion issue too or it's a complete non-starter

Sure, AFAIK most doc solutions support this either out of the box or via a plugin, for example.

Masstransit's docs use the same system

(I'm using Vuepress as an example as I personally know Vue.js, but there's also other popular frameworks like the React-based Docusaurus)

I can't even begin to tell you how much that irritates me. It's a pet peeve of mine to see OSS projects with shiny, flashy websites and pathetic tech. FFS, I'd argue that Marten has far better documentation in terms of content that some commercial tools.

Unfortunately perception is everything these days and technical frameworks suffer the same marketing problems as traditional websites, whereby the big and shiny will win out the majority of the time. After all, that's how MongoDB got to where it is, regardless of its actual performance :)

[mysticmind]

@Hawxy I had a look at VuePress quite a while back, it has vastly improved now. I think it is pretty good to use at this point for docs. I also personally know Vue.js, will take a first crack at it in a branch, will put some initial stuff and keep you posted.

Edit: I would also want to add https://tailwindcss.com/ into the mix so that the site can look a bit distinct/unique than the standard VuePress docs layout/styling.

[Hawxy]

I had a look at VuePress quite a while back, it has vastly improved now.

Cool, there's also VitePress being worked on by the core Vue.js team, as well as vuepress-next, which are both at various stages of feature completion.

I would also want to add https://tailwindcss.com/ into the mix so that the site can look a bit distinct/unique than the standard VuePress docs layout/styling.

You might be interested in Nuxt.js's new content extension, which is uses tailwind by default. Nuxt is a lot more complex than VuePress though, and is probably overkill unless there are plans to attach a full website/blog etc to the docs themselves.

[mysticmind]

You might be interested in Nuxt.js's new content extension, which is uses tailwind by default. Nuxt is a lot more complex than VuePress though, and is probably overkill unless there are plans to attach a full website/blog etc to the docs themselves.

Nuxt content extension allowing Vue components and Tailwind by defaults looks quite interesting. It reminds me of Eleventy in terms of data handling portion.

[cocowalla]

To add another perspective, I've been using Marten for a long time, and I think the docs are great - far better than a lot of OSS projects. I like the existing styling too 🤷

[JoeMarkov]

As a non Postgres user, my personal wish is that it would support SqlServer, perhaps with a "reduced" "document model" support.

Otherwise I really like the idea of Marten combining EventSourcing and Document database in the same database.

The alternative is to combine database liked GetEventStore and RavenDB, but I would rather prefer to have it all in the same place to reduce complexity.

[jeremydmiller]

@JoeMarkov I almost lined to this in the post: https://jeremydmiller.com/2018/03/07/marten-2-6-2-7-and-why-we-dont-support-sql-server-yet/#:~:text=Marten%20depends%20on%20Postgresql%20and,more%20efficient%20storage%20and%20querying

Sql Server support probably doesn't happen this year. Maybe next, it's starting to be more feasible.

[JoeMarkov]

A second suggestion is to provide some more technical and feature comparisons between Marten and the alternatives like EventStoreDB, RavenDb, MongoDb...

[Arithmomaniac]

Postgres-as-a-service in Azure. (Not that that's in your control...)

[Hawxy]

Azure Database for PostgreSQL already exists, it's a fully managed PaaS... 🤔

[Arithmomaniac]

Hay, go figure 😊 Not sure how I missed that...

[btull89]

When looking at Marten for our organization a little over a year ago, support was the reason we decided against using it. Since this is a database and not a nuget package, it can’t be easily replaced if it is no longer kept up-to-date. We felt that enterprise level support was extremely important for our databases.
Even today, looking at the Marten website it doesn’t appear to offer support even though in this blog post you mentioned that support is offered through Calavista.

[JoeMarkov]

One suggestion is to have more youtube videos around Marten from different angles, as I find its a good way to get a better overview of what it does , but also some more hands on getting started videos.

I also was surprised that it also did read-side projections, I always assumed it only did the event-store and document database parts.

for projections then I would like to see more details about what transactional guarantees I have (exact-once vs at-least once...) .

[johncj-improving]

Make Postgres invisible. Here's what I mean. If I recommend a new .Net tool to a client, I generally have to sell that to the development organization. If I recommend a new database, now I have to sell it to the DBAs. I love DBAs, I don't love selling a new database to them. They're typically going to want training, time to develop standards, backup scripts, etc. Now I've just extended the timeline of the project to something approaching infinity.
So, give me a recipe to run this thing with Postgres in Azure PaaS. Let me tell my client that they will never have to manage a Postgres Instance. (If it's on Azure, we can "manage" it for them).

[jeremydmiller]

That's gonna require having some actual corporate support -- which I might be able to pull off through Calavista

[Healios]

I'd like a better way of including related documents when querying. I'd really like to go with MartenDb instead of MongoDb, but dealing with related documents in MartenDb is simply to cumbersome.

Something along the lines of what Entity Framework, RavenDB or MongoDB does, where the related document is automatically assigned to a property on the retrieved document.