[Question] Understanding Marten vs OSS DocumentDb

[omni-htg]

Hey team!
Maybe I'm missing a big piece of understanding here, but I would like to request some help understanding how Morten compares, or better yet, how it fits in an environment where options like The Linux Foundation's (prev. Azure's) DocumentDb (and implementations of it, like FerretDb) exist.
Much appreciated!

[mysticmind]

Please run through this comparison below:

	Marten	DocumentDb
Storage backend	Built on standard Postgres using JSONB data type to store JSON data. JSONB is a native data type provided by Postgres including a list of JSON operators/functions to work on it.	This is built as an Postgres extension extends Postgres by adding a new custom data type BSON. This makes it a drop-in replacement for MongoDb.
Query Language	C#/.NET Language API/LINQ translates to standard SQL queries	MongoDB compatible wire protocol so any MongoDB client in any language can use it.
Performance	Use Postgres JSONB so minimal translation layer	Adds BSON parsing and compatibility layer so adds a slightly more overhead
Cloud environments/Docker	Just use standard Postgres	Requires the DocumentDb postgres extension to be available to use it. Only few cloud providers support this extension.
Miscellaneous	Marten provides both DocumentDb, EventStore, multi-tenancy etc.	Provides only DocumentDb. FerretDB supports MongoDb compatible wire protocol on top of both Postgres and SQLite. For Postgres, it uses the DocumentDb extension as an underlying engine.

[omni-htg]

Thank you for the quick heads-up!

From this table, I so far understand the following:

• Marten is not trying to "simulate" any protocol unlike what DocumentDb / FerretDb do with Mongo to become an alternative (like what MinIO would be to S3, basically).
• Marten can work on a plain Postgres deployment, without extensions or further configuration.
• Marten's use entails writing C# code or LINQ to represent standard SQL in order to write "document" data in a JSONB structure, not BSON / NoSql documents.

With this in mind, there's still a couple of items that I'm struggling to understand properly:

• For a team using Marten, would all that data be "stuck" only being able to be used with Marten, without alternatives that can consume from the same """protocol""" if there's a need for Migration and the like?
• The Miscellaneous entry includes the concept of "DocumentDb", which has unfortunately been coopted by quite a few other projects, making it hard to isolate what Marten is trying to go for here (is it "document database", is it "OSS DocumentDb support"?).

If possible, it would be very appreciated if such explanation can also be available on the site / docs / readme 🙂
And finally, an example of use case where Marten might be a better idea for a team than Mongo and the like!

Thanks a bunch!

[mysticmind]

Marten provides a list of functionality (please read the docs) as a fancy .NET library on top Postgres database as its underlying database. Marten stores all data in Postgres tables where each document type is a table where in the whole of the data is serialized as JSON as stored in a single JSONB column. So Marten has it way to define the table schema etc for storing documents as part of document database. So with regards to your question would the data be "stuck", certainly not if you inspect and understand the table schema created by Marten and you can use plain vanilla SQL queries outside of Marten to query the data etc.

With regards to miscellaneous entry with "DocumentDB", it is a short form for "document database". In this context of this answer, using "DocumentDb" caused a confusion for you since Microsoft cleverly uses this specific term "DocumentDB" as it is library name to make users perceive everyone else copied from it.

From a document database standpoint,both Marten and MongoDb are selling the idea of schema-less storage of data i.e. work with documents without worrying about the schema. Marten provides LINQ and direct SQL based mechanism to work with data and Mongo provides its own API to work with documents. The primary impetus from a selection for a document database would be for you to choose whether you want use Mongo API/Mongo client or .NET LINQ to work with documents.

Beyond the general document database functionality, Marten provides muti-tenancy, event store and lot more as a functionality beyond document database. It is up to you to use what fits your needs.

As a closing note, I am going ask you go and read the Marten documentation, try it out and understand what all functionality it provides. Marten just completed 10 years and the Microsoft OSS DocumentDB announced being OSS in Jan 2025.

[jeremydmiller]

@omni-htg You can happily read anything directly out of a Marten PostgreSQL database with raw SQL and all of its JSONB operators. Maybe not something I'd recommend doing having another service also try to access the Marten tables, but very technically possible.

[omni-htg]

@mysticmind

So with regards to your question would the data be "stuck", certainly not if you inspect and understand the table schema created by Marten and you can use plain vanilla SQL queries outside of Marten to query the data etc.

From a document database standpoint,both Marten and MongoDb are selling the idea of schema-less storage of data. [...] The primary impetus from a selection for a document database would be for you to choose whether you want use Mongo API/Mongo client or .NET LINQ to work with documents.

Thank you, this is the kind of answers and clarification I was looking for!

With regards to miscellaneous entry with "DocumentDB", it is a short form for "document database". In this context of this answer, using "DocumentDb" caused a confusion for you since Microsoft cleverly uses this specific term "DocumentDB" as it is library name to make users perceive everyone else copied from it.

Marten just completed 10 years and the Microsoft OSS DocumentDB announced being OSS in Jan 2025.

Oh for sure! Congrats on the decade! 🥳
I wasn't implying that one came from the other or anything along those lines, rather try to understand properly what we were talking about.

@jeremydmiller

You can happily read anything directly out of a Marten PostgreSQL database with raw SQL and all of its JSONB operators. Maybe not something I'd recommend doing having another service also try to access the Marten tables, but very technically possible.

These are great news. Not that there's any particular reason to do so, but I personally agree more and more with the sentiment for better data governance, which IMO implies having "options" to produce and consume your data.
Much like what happened with Mongo, I hope Marten becomes a "protocol" in and of itself so other products can follow on it's track 🙂

Thank you kindly to both, this was a great help!