21–30 of 119 posts
Just pick something and build an MVP with it. Then get on with the hard part of finding paying customers. You can fix the bad tech decisions later. Without customers it won't matter which database you used before your startup failed.
Earlier quoted context omitted.
I think that there are various reasons to pick DBs. Blindly picking a SQL DB (mysql/postgres etc.) is quite expensive from the get-go (a production ready mysql/postgres would cost ~30$/m). Mongo costs ~$10/m (MongoDB Atlas), Google's Datastore is Pay as you Go (so your initial cost is close to $0 till you get paying customers), AWS's DynamoDB is similarly priced as well. Sure, sadly all those noSQL solutions get real…
Hmm, how are you deploying things that a database costs $30/m? I just put it on the same server as the application worker and split it off if I need more performance later.
I feel like MongoDB/NoSQL is a horse that's been beaten so much in the last few years that no one is actually making that choice nowadays. Hasn't everyone already learned to stick with Postgres?
MongoDB/NoSQL is deployed and used at large scale by companies like Facebook, Ebay and many others. That's quite far from "no one is actually making that choice nowadays".
I feel like MongoDB/NoSQL is a horse that's been beaten so much in the last few years that no one is actually making that choice nowadays. Hasn't everyone already learned to stick with Postgres?
MongoDB/NoSQL is deployed and used at large scale by companies like Facebook, Ebay and many others. That's quite far from "no one is actually making that choice nowadays".
Just pick something and build an MVP with it. Then get on with the hard part of finding paying customers. You can fix the bad tech decisions later. Without customers it won't matter which database you used before your startup failed.
Postgres is far from a boring relational database. Don’t make the mistake of building a mvp on rickety stilts and then swap them out later for proper columns while trying to run.
Just pick something and build an MVP with it. Then get on with the hard part of finding paying customers. You can fix the bad tech decisions later. Without customers it won't matter which database you used before your startup failed.
But I always wonder exactly "what" is easier with mongo or another NoSQL db. Just get a relation db like PostgreSQL, MySQL or SQLite for that matter. If your site starts to get performance problems go to the pub, celebrate a bit of success and then optimise!
> startup mistakes > .io domain oh my.
Earlier quoted context omitted.
Unfortunately, no. Some friends of mine picked another nonrel database (not Mongo) for their new company, which prompted this article. I still have to give this advice quite often.
My condolences. I think one thing that's not mentioned enough in the SQL vs NoSQL debate is the benefit of powerful storage types. For example, when storing IP addresses in Postgres, you can use the inet datatype and easily query results if they fall within a given cidr range. Example: SELECT * FROM audits WHERE ip_address gives you any matching address between 10.0.0.1 and 10.0.15.254
TL;DR: "just use Postgres"
Earlier quoted context omitted.
Hmm, how are you deploying things that a database costs $30/m? I just put it on the same server as the application worker and split it off if I need more performance later.
maybe I'm doing this wrong, but if I use RDS / Cloud SQL / Compose etc - a normal base cluster + another failover cluster + hourly/daily backups (based on your release schedule) all add up to around 30 - 50 based on various cloud providers.