Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Startup Mistakes: Choice of Datastore

stavros.io

Post reply on HN
Print view View original

11–20 of 119 posts

Re: Startup Mistakes: Choice of Datastore

#11

Post by ohstopitu »

StavrosK wrote: post #7
elvinyung wrote: post #4

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?

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.

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 really expensive as your usage goes up to normal non-webscale proportions, but at that point you have the $ to invest in a SQL solution.

The above was mentioned with bootstrapped startups/services in mind. Not your usual million funded valley companies.

Re: Startup Mistakes: Choice of Datastore

#13

Post by StavrosK »

ohstopitu wrote: post #11
StavrosK wrote: post #7

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.

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.

Re: Startup Mistakes: Choice of Datastore

#15

Post by jlebrech »

StavrosK wrote: post #7
elvinyung wrote: post #4

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?

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.

same thing goes with single page applications. i've haven't seen the benefit yet, a fast full stack app sprinkled with react/vue at the last minute does just as good a job.

Re: Startup Mistakes: Choice of Datastore

#16

Post by mamcx »

onion2k wrote: post #2

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.

BIG ERROR.

Like, MONUMENTAL.

That something (if chose very wrong) will totally derail you progress and will cost a lot of fix it later.

Is incredible. Nobody remember that the most cost effective way to fix a problem is in the early stages?

And, yes, the best overall primary datastore, like 90% of the cases, is a RDBMS. Very few actually need to use something else.

Re: Startup Mistakes: Choice of Datastore

#17

Post by mamcx »

StavrosK wrote: post #3
onion2k wrote: post #2

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.

I agree, but it's better if later you only have to fix ten bad decisions instead of twenty.

Is even worse to fix 1, but big.

DataStore is 1 that is too big to pick wrong.

Re: Startup Mistakes: Choice of Datastore

#18

Post by maephisto »

elvinyung wrote: post #4

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".

Re: Startup Mistakes: Choice of Datastore

#19

Post by StavrosK »

jlebrech wrote: post #15
StavrosK wrote: post #7

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.

same thing goes with single page applications. i've haven't seen the benefit yet, a fast full stack app sprinkled with react/vue at the last minute does just as good a job.

Those are more frequently useful, mainly for CRUD apps where you're changing a lot of state often and don't want to have to reload every time. I agree that for news-type sites, for example, they are overkill.

Re: Startup Mistakes: Choice of Datastore

#20

Post by spamizbad »

StavrosK wrote: post #7
elvinyung wrote: post #4

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?

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
Post reply on HN