Mongo and other nosql databases are still the absolute fastest way to get started particularly you don't know what your data is eventually going to look like.
If you don't know what your needs are, you should always start with an RDBMS -- it's not that difficult to go "up" to a NoSQL db from there (you're only losing information, and if you can't safely move because of loss of ACID... you'd probably have been really fucked if you started off without it), but you can't easily migrate back "down" to the RDBMS -- a NoSQL database stores almost no information about your data or its constraints.
And your application will almost always want transactional guarantees and to model relationships properly -- generally only small chunks of the design (design-wise; data-wise it might be 90% of the app) can be treated with eventual consistency and have real scaling needs, which you can shift over to your nosql system.
Apps are generally just metadata tracking with a dash of real work.
Unless you mean for solo projects? In that case, it may work for you, but if you're not a database expert, it makes sense you would work around your limitations. That doesn't necessarily mean it's a best practice.
All my proof of concept (and some production) stuff just uses that until I need features or concurrency that it can’t provide.
but even still, you can always use json columns in postgres if you don't want the db to enforce a schema.
Complaining mongo doesn't scale is like saying your Mita can't off-road
Oh you always have a schema. Its just about whether you want to enforce it or not.
My prototyping always starts with
DB = {}
The idea is if you have just a couple of days to crack out of MVP you don't want to waste time with postgres or whatever. The problem ends up being then your boss is like, all right this works keep going with it
It's less work than setting up mongo, postgres, or whatever long-running data store. Just deploy the web application... and you're done.
I generally dislike when people try to write off a technology just because they don't know how to use it. Don't hammer in screws, but it doesn't mean you should throw out all of your hammers
It's very easy to get going quickly and find out that you've tripped over antipatterns, and now your database is "a database, a Ruby app, and 30ms of latency on every call". It's easy to think "I'll model this later" and end up hitting the database five times in a row to answer a question.
With these systems, up front modeling of your data model and access patterns is essential if the trade off you are trying to make (far less functionality for smooth performance at ridiculous scale) will ever make sense.
There's never a good moment to switch database, but there is always a new problem caused by storing relational data in a document store.
You probably shouldn't use that too much, not for anything remotely production, but it's there if you need that flexibility or an easy place to dump javascript objects.
When you are just getting started, it's super easy to manipulate SQL data structures regardless.