I've been using Marten for maybe 3 years now, and I absolutely love it! It's extensible too, so you can do just about anything with it - for example, I use it with views, multi tenancy, a base for aggregate queries and all sorts, and it works great.
The core team is really responsive on both GitHub and Gitter too, and are happy to both accept and help with PRs - it's (almost) the model of a well run OSS project.
One small thing tho... the original developer, Jeremy Miller, can be a bit... spiky; like you ask a question and he just assumes bad faith and will snark at you. I imagine this behaviour has put at least a few people off contributing and using Marten. I almost feel bad about mentioning this, because I'm a fan of his work, but OTOH I kind of hope Jeremy reads this comment and takes it constructively.
I came across Marten on someone's blog where they were talking about their ups and downs with RavenDB. It looks interesting.
Since you're using it, I'd like to know more about it's performance profile. Can't really find any performance/speed comparisons online. And what kind of scale are you running.
I'm right at the beginning of a project for a client and I'm roughing out the foundational code with pgsql already, so it would be a perfect time to take a look at it.
We're not running at scale, at least not the kind where performance of the library is likely to be an issue. We have around 50 tenants with a handful of users each. Tenants have up to 100's of millions of rows in Postgres - not exactly big data levels, but pretty big still.
I don't have perf numbers anymore, but I did some performance testing before I started using it a few years ago, and even back then it was much faster than EF/EFCore. The team have made many performance improvements since then. Considering the ease of use, and the fact you get NoSQL-style JSON documents that work alongside regular relational tables, basically the performance impact is as good as neglibible, IMO.
If you want to work with JSON documents, I highly recommend Marten.
It does have a Benchmarks project if you'd like to run some tests[0], and I'm sure the team would be happy to answer any questions over in Gitter[1].
Jeremy finds your “comment” behind an anonymous name on a very public board to be extremely obnoxious and a prime example of the kind of online interaction that tends to sour me on OSS.
What I absolutely miss from Postgres is Column store support. For many analytics related workloads, columnstore beats traditional row store. I really wish they can add this soon.
We used it for a production project which I inherited.
Honestly I'm not a bit fan of anything Orm like, as such there is some magic, I believe out of the box it will literally just create tables and keys for you.
For what it is, it's very fast for prototyping things out.
I would personally just use the in built jsonb functionality of postgres and build out my own repositories. Saves confusion from all of the magic.
We used EventStore [0] as an Event Store in a previous project (yes, this does get tedious to explain).
I'm quite curious who this is aimed at. .NET shops are often so deeply invested in the Microsoft ecosystem. In that previous project, needing to run/administer PostgreSQL instead of SQL Server would have been a significant administrative detriment to getting the project greenlit.
(The fact that EventStore doesn't use any RDBMS as a store at all paradoxically helped. At least that meant we weren't getting DBA split-brain problems between SQL dialects.)
We wanted some instances, had to get our hosting provider to dig up previous generation CPU machines so we could have a lower core count. They were like "We'll give you the extra cores for free", Until we explained that it was for SQL License reasons.
> I'm quite curious who this is aimed at. .NET shops are often so deeply invested in the Microsoft ecosystem.
The cloud (even Microsoft's Azure) has changed this somewhat, and continues to do so.
I work as a architect for companies in the enterprise world, and most businesses are now much more open to using Linux and non-Microsoft systems. I recently finished a project for a Microsoft shop, using Postgres, RabbitMQ, Linux and dotnet Core, and this is no longer unusual for me. This current situation was utterly unimaginable before the cloud - I love finally having the freedom to choose something because it's a good fit, rather than being forced to use something "because policy".
Furthermore, dotnet is not purely for Microsoft shops any more - dotnet Core helped change that. Personally, I use dotnet Core for all my side projects, and it works great on Linux.
All of this was deployed in the Azure. I could perhaps have been clearer - all the enterprises I've worked at in recent times have been happy to deploy non-Microsoft services, but only when those services are deployed to the cloud. As far as on-prem goes, they exclusively stick with Microsoft (and sometimes Oracle).
There is a growing number of ".NET shops" nowadays that are using non-MS open-source infrastructure. You don't hear much about it because the .NET community has always been culturally less exhibitionist than others. So much so that there are still tons of people out there who don't know that .NET runs on Linux, and has done for quite a number of years now.
These days, being able to leverage Azure helps... Of course, you can also just as easily use Azure SQL, and for that matter, the dockerized version of SQL Server is really useful for development.
Getting to the point we have a couple projects targetting kubernetes... one for hosting/deployment and testing, one only for testing, and another getting there for testing. Our apps have various differing configurations for various client deployments, so being able to spin up and test with different client configurations for applications is helpful.
Once at that point, introducing something new, such as a redis instance for connection throttling/tracking, or using Postgres locally/remotely for our app databases (service hosted for prod, k8s temporary instances for testing/dev), or spinning up rabbitmq even, or leveraging azure storage queues.
Of course we've also been writing more in node, and less in C# for some things. Getting away from all things C# has been hard in a historically .Net shop though.
This is interesting in that it seems to organize tenants into their own database.
I've built a few SaaS products with on the order of a few thousand customers per application. Performance can sometimes be a problem when each customer can have millions of rows but no relation between those customers. I believe this is pretty typical.
What's the purpose of mixing different customer rows? You rarely aggregate them all together. A million rows is easy for a database but when there are billions together, it starts requiring deeper optimizations.
The idea of each getting their own separate database makes intuitive sense to me but most tools for dB access aren't built with this in mind.
24 comments
[ 4.6 ms ] story [ 80.1 ms ] threadThe core team is really responsive on both GitHub and Gitter too, and are happy to both accept and help with PRs - it's (almost) the model of a well run OSS project.
One small thing tho... the original developer, Jeremy Miller, can be a bit... spiky; like you ask a question and he just assumes bad faith and will snark at you. I imagine this behaviour has put at least a few people off contributing and using Marten. I almost feel bad about mentioning this, because I'm a fan of his work, but OTOH I kind of hope Jeremy reads this comment and takes it constructively.
Since you're using it, I'd like to know more about it's performance profile. Can't really find any performance/speed comparisons online. And what kind of scale are you running.
I'm right at the beginning of a project for a client and I'm roughing out the foundational code with pgsql already, so it would be a perfect time to take a look at it.
Thanks!
I don't have perf numbers anymore, but I did some performance testing before I started using it a few years ago, and even back then it was much faster than EF/EFCore. The team have made many performance improvements since then. Considering the ease of use, and the fact you get NoSQL-style JSON documents that work alongside regular relational tables, basically the performance impact is as good as neglibible, IMO.
If you want to work with JSON documents, I highly recommend Marten.
It does have a Benchmarks project if you'd like to run some tests[0], and I'm sure the team would be happy to answer any questions over in Gitter[1].
[0] https://github.com/JasperFx/marten/blob/07d99ed80a1f0c436c4f...
[1] https://gitter.im/JasperFx/marten
Just go through the documentation of MartenDb and I'll bet you'll like it.
Note: If you are interested in DDD/microservices on. Net, you probably know Mass-Transit.
But I would advice you to check out everything under JasperFX ( https://github.com/JasperFx ), which MartenDb is a part of.
Fyi: they hang out on gitter.me
Honestly I'm not a bit fan of anything Orm like, as such there is some magic, I believe out of the box it will literally just create tables and keys for you.
For what it is, it's very fast for prototyping things out.
I would personally just use the in built jsonb functionality of postgres and build out my own repositories. Saves confusion from all of the magic.
My 2 pence
I'm quite curious who this is aimed at. .NET shops are often so deeply invested in the Microsoft ecosystem. In that previous project, needing to run/administer PostgreSQL instead of SQL Server would have been a significant administrative detriment to getting the project greenlit.
(The fact that EventStore doesn't use any RDBMS as a store at all paradoxically helped. At least that meant we weren't getting DBA split-brain problems between SQL dialects.)
[0] https://eventstore.com/
Nobody likes MS's SQL License fees, however.
If you're going all cloud, then you can't get away with using unlicensed/insufficiently licensed RDS instances.
The delta between Postgres an SQL Server instance pricing per hour doesn't take much to add up to a salary for a mid range DBA.
Then SQL Server went per-core and our pricing went up 8-fold.
Been using PostgreSQL ever since.
We wanted some instances, had to get our hosting provider to dig up previous generation CPU machines so we could have a lower core count. They were like "We'll give you the extra cores for free", Until we explained that it was for SQL License reasons.
I agree with you, leadership didn't shrug. Keeping to as few technologies as possible is a more pricey, but also more conservative choice.
The cloud (even Microsoft's Azure) has changed this somewhat, and continues to do so.
I work as a architect for companies in the enterprise world, and most businesses are now much more open to using Linux and non-Microsoft systems. I recently finished a project for a Microsoft shop, using Postgres, RabbitMQ, Linux and dotnet Core, and this is no longer unusual for me. This current situation was utterly unimaginable before the cloud - I love finally having the freedom to choose something because it's a good fit, rather than being forced to use something "because policy".
Furthermore, dotnet is not purely for Microsoft shops any more - dotnet Core helped change that. Personally, I use dotnet Core for all my side projects, and it works great on Linux.
Hm, I see - that sounds like they're already very far on the journey out of the Microsoft ecosystem.
I personally haven't seen a company like that, only ones heading further into "1st party Azure services" lock-in.
Getting to the point we have a couple projects targetting kubernetes... one for hosting/deployment and testing, one only for testing, and another getting there for testing. Our apps have various differing configurations for various client deployments, so being able to spin up and test with different client configurations for applications is helpful.
Once at that point, introducing something new, such as a redis instance for connection throttling/tracking, or using Postgres locally/remotely for our app databases (service hosted for prod, k8s temporary instances for testing/dev), or spinning up rabbitmq even, or leveraging azure storage queues.
Of course we've also been writing more in node, and less in C# for some things. Getting away from all things C# has been hard in a historically .Net shop though.
I've built a few SaaS products with on the order of a few thousand customers per application. Performance can sometimes be a problem when each customer can have millions of rows but no relation between those customers. I believe this is pretty typical.
What's the purpose of mixing different customer rows? You rarely aggregate them all together. A million rows is easy for a database but when there are billions together, it starts requiring deeper optimizations.
The idea of each getting their own separate database makes intuitive sense to me but most tools for dB access aren't built with this in mind.