Please contact me. My Background: founder of successful VC backed company with a successful exit. Professor of Practice at University of Wyoming (now) retiring at the end of this semester. I teach full stack development and database. My product company was a database performance tuning and storage management tool. pschlump@gmail.com
There's no reasonable way to compare performance between PostgreSQL and MongoDB because they're not the same kind of product and they don't have a similar query interface.
You can take a particular application and compare performance when using two different databases on the back-end, but then the database itself might not necessarily be your bottleneck, it might also be the way the application is written. Because the database is only a part of the equation, the comparison also doesn't tell you anything about the performance of any other application.
You can get amazing performance results if you don't care about data persistence. Anyway when postgresql introduced JSONB there was a benchmark for CRUD operations, can't find it now, because it was long time ago, but I remeber postgresql was doing circles around mongodb.
I (with my family) lived 5 years on a 13 m sailboat. I added AIS and EPIRB to the boat as we had many off-shore passages. AIS (class b) costs about $500 (US $). EPIRB is about $400 with a $200 every 24 month cost.
I have had a number of contracts where my entire job was to fix the performance problems introduced by using a ORM. ORMs add a layer of complexity to your code and a huge risk of really bad SQL.
ORMs can be used poorly sure, but anything I can design using raw SQL I can typically do with an ORM. The question is, are people using ORMs as a way to avoid having to figure out proper database design? If so, they should not be using an ORM and should really learn how the database they will be using works. Heck! There's micro ORMs like Dapper which let you run raw SQL and match it to an actual object for you, to be fair almost all ORM's support doing raw SQL and getting back an object which can be handy for performance bottlenecks. Badly coded software will usually have performance issues, whether using raw SQL or not.
Do you think the performance would have been better if the same programmers who introduced them using the ORM had been forced to use raw SQL?
I've seen far too many cases where programmers get around their lack of SQL knowledge by writing a bunch of basic queries and then post-processing the results client side.
But it is a problem. And also a difference in philosophy. NTFS gives the user and the process the guarantee that the filesystem will remain consistent. Also as a user, I have a guarantee that the file I have open, represents a file that actually exists on the file system, and not a deleted file.
This is not relevant to the on-disk filesystem, just how the OS handles files.
The philosophy is also flawed: open a file, then create a hard link to it. You now can't delete that hard link (because the file is open), even though you just created it. This is not a problem on POSIX because it correctly distinguishes a file name (represented by a directory entry) from a file (represented by the inode).
Its not clear to me what "flaw" you're referring to. NTFS is reference counted and can easily accommodate other behaviors. By default, it prevents deletion, unless a process specifically permits deletion, in which case, the file can be deleted.
This makes a whole lot of sense to me as a user, because I don't want to worry about open files being possibly deleted from disk.
>open a file, then create a hard link to it. You now can't delete that hard link (because the file is open), even though you just created it. This is not a problem on POSIX because it correctly distinguishes a file name (represented by a directory entry) from a file (represented by the inode).
Nothing like not being able to delete a directory because Explorer is keeping the folder's thumbnail database open and in use even though you are no longer in the directory.
My experience is that ORMs fail at dealing with reports, searching data and all large data updates. If all your application needs is a single row of data tied to some other set of single rows of data then an ORM might be of limited benefit to you. I have had multiple contracts to fix the performance problems introduced by ORMs. In the test database the ORM was good - in the real world not so good.
