This is key and often overlooked - MongoDB is so popular not because it's the best database but because it's so easy to get started with. Download/unzip/run to have a database engine ready. It also helps that you can also immediately store anything without any prior setup steps.
Postgres/mysql/sqlserver/etc are nowhere near as easy to install, as fast to get started with or as portable to move around.
Postgres members should listen this and have a simple getting started guide for osx, Windows, Linux. I tried brew install postgresql. There was no single place which tells me how to start server, access command line, create db etc.
On OSX there is the fantastic http://postgresapp.com/ . It installs into /Applications so it is easy to remove, and comes with a start/stop GUI and taskbar icon. Great for local development.
But installing and configuring Postgres "properly" on a server is still something of a challenge. Do I need to modify random_page_cost on a SSD or not? What are good memory limits on modern big servers? What exactly needs to go into pg_hba.conf?
None of these seem too difficult after reading a few tutorials and wikis, but it would be nice if the server set itself up with reasonable defaults based on the machine its running on.
Getting started with PostgreSQL on Linux is actually trivial. What is annoying though that there are lots of guides which talk about editing pg_hba.conf which is not necessary for the simplest setup. The default pg_hba.conf is good in most distros.
We must have different definitions of trivial compared to what I had to go through every time - it's a mess of an install process that takes tweaking config files just to have it even listen to external requests.
With the ease of services like AWS, we never installed a database server. Pick a database flavor, version, click, click and you're up. I suppose designing the schema take a little effort, but I find it much easier than properly architecting software.
Many if not most installations are still being done on actual dev machines and servers. While RDS and other managed services are nice, they're just a small fraction of the usage.
Also the fact that managed services help so much only speaks to the fact of how difficult these relational databases typically are to work with operationally.
if you're on a mac you can download postgresql.app[0] which produces a small icon in the top right status bar. You don't have to install users or permissions or anything it's super easy to set up. Getting it on prod can come later but for the first five minutes it works.
(granted, this neglects contrib extensions like hstore)
It's not just installing for development, mongodb (other than its ridiculous clustering) is very easy to install on production servers as well and moving an installation is basically just zipping up the folder and moving it somewhere else.
That sets up postgres. It doesn't let you get started doing CRUD operations inside your postgres though - which is where MongoDB shines, "just store my data, fuck it"
> Mongo is a dumb, dead-end platform, but they know how important ease-of-use is.
By “ease of use”, do you mean “ease of making something that seems to work” or “ease of making something that actually works”? I've never used a schema-free database, and ended up thinking to myself “I'm completely sure this database can't possibly contain garbage data”. Or do programmers simply not care about data integrity anymore?
The single biggest source of grief in our production database has been the one JSON field we used once to avoid adding another table. That goddamn thing has crashed the server so many times with invalid data, that I'm never using anything schemaless again. We recently migrated to a proper table and I'm thanking my lucky stars I finally got rid of that devil.
You can insult the developers that use Mongo or you can look at how to get those users onto a better platform. With the modern expectations of full-stack development, is it any wonder that something promising simplicity and zero-configuration data storage does well?
Well, I have used one and had that assertion. Ease of use means making something that works. It seems we're condoning lack of knowledge or experience with programming. If you've never used databases in your life, whether you're using SQL orNoSQL you'll likely end up with rubbish data. In the SQL world it could be that you're storing time in the wrong format, concatenating long fields, or not normalising when you should or the other way around.
In NoSQL you could be reinventing the wheel, or storing data that you can't query efficiently because you can't index it well etc.
All the excuses of not using some document stores beyond ACID really sound like people won't know what the heck they're doing.
> Well, I have used one and had that assertion. Ease of use means making something that works.
For me, it means, under no circumstance, no interleaving of transactions or scheduling of commands, nothing, nichts, nada, can the database be in a state where a business rule is violated. If I need to worry what silly intermediate transaction state can be observed from another transaction, or if I need to worry whether a master record can be deleted without cascade-deleting everything that references it, then the DBMS has failed me.
> not normalising when you should or the other way around.
I've never seen a situation where anything less than 3NF (actually, ideally, at least EKNF) is acceptable.
What they neglect to mention is not that you don't need a DBA, that you are the DBA yourself. With all the responsibilities that go along with that role. Who's getting paged at 3am now...?
If thats really a problem host your database on a cloud platform and let those guys do the job of a DBA. Works for me at present. I am aware its not going to be a solution for everyone, though it still sounds a lot better than being your own Mongo DBA.
The DBA is the role who is reponsible for the organizations data. Even if you outsource the routine tasks such as "doing backups" you still need someone to assume that role.
Yes, it will help you to cover cases like where the server phyically explodes, but that's basically irrelevant, most problems where you need a DBA are caused either by data corruption caused by application code or developer, or performance issues caused by DB structure - in those cases the cloud platform won't do anything for you, they just host the server. They can restore backups, do monitoring and tune the server, not your particular app/db structure - but all the big problems are there.
"most problems where you need a DBA are caused either by data corruption caused by application code or developer, or performance issues caused by DB structure"
Is running Mongo going to solve any of those problems?
Without a rigidly enforced schema I would guess those problems are going to be amplified rather than solved.
Mongo is a dumb, dead-end platform, but they know how important ease-of-use is.