"Easy to use" is a perfectly legitimate criteria to optimize for. For most startups performance/scale is a total non-issue, most of the time even something like berkleydb would do. At most early stage startups developer time is the single biggest bottleneck.
If you make a non-optimal choice upfront you can always migrate to another database later on (database migrations are painful but in practice is something you have to do sooner or later in any case).
(obviously this applies to the scaling argument; if you need transactions you should pick a database which supports them)
If you make a non-optimal choice upfront you can always migrate to another database later on (database migrations are painful but in practice is something you have to do sooner or later in any case).
(obviously this applies to the scaling argument; if you need transactions you should pick a database which supports them)