Because postgres doesn't focus on the first-five-minutes experience the way Mongo does. Even the name is hard to say.
Mongo is a dumb, dead-end platform, but they know how important ease-of-use is.
Mongo is a dumb, dead-end platform, but they know how important ease-of-use is.
Postgres/mysql/sqlserver/etc are nowhere near as easy to install, as fast to get started with or as portable to move around.
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.
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)
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?
All that I can say is congrats, man!
How many times have you promised to fix something later and then later comes and...
Prototyping is not an excuse for laziness. It does feel like some programmers don't care.
Why not just prototype with Sqlite? You don't even need a server.
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.
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.
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.
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.