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

71–80 of 119 posts

Re: Startup Mistakes: Choice of Datastore

#71

Post by notyourday »

mamcx wrote: post #16
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.

It won't.

Re: Startup Mistakes: Choice of Datastore

#72

Post by mannykannot »

izolate wrote: post #9
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.

Exactly. This article typifies premature optimisation. If MongoDB lets you prototype faster, then use it until you have enough paying customers to warrant a refactor.

Knuth's aphorism on premature optimization is perhaps the most misunderstood point in software development. It applies to code-level algorithmic optimization, not architectural decisions, where a bad choice can lead down a very long dead-end. You can recover if you recognize this in time, but you are better of if you do not have to. Obligatory rewriting is not what you want to be doing just as competitors take notice of your initial success.

Re: Startup Mistakes: Choice of Datastore

#73

Post by jijji »

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.

you pick "something" based on the requirements of the application or whatever solution you're building. if your requirements mention that you need to have multiple people accessing the database at the same time, RDBMS environments like MySQL, Postgres, Oracle would be appropriate. If it is a single application instance with no multi-user access, SQLite might be appropriate. However, if you're choosing SQLite, FileMaker, FoxPro, MS Access, etc and your requirements specify that you needed multi-user access, then you've made a large mistake.

Re: Startup Mistakes: Choice of Datastore

#74

Post by beagle3 »

codazoda wrote: post #68

This article is a bit combative but I generally agree with the idea. I use both MySQL and MongoDB in my daily work on a classifieds site that does a few hundred million pageviews a month. Both are pretty solid performers. The article is correct that with Mongo you just move the schema into the code (new versions not withstanding). I think it's nicer to have the schema on the database side but it's really just user pr…

It's more than user preference in the long run; When your schema is encoded in the database (with triggers, constraints, foreign keys, the whole shebang), you can be sure that whichever way you access the database, it is still consistent.

When your schema is "in the code", even if you completely abstract it into a library, it means that the quick-one-off Ruby/Perl/C#/Python script will not have the integrity checks, and may corrupt your DB.

Re: Startup Mistakes: Choice of Datastore

#75

Post by jihadjihad »

The reason MongoDB is simultaneously lauded and derided is because there is a bimodal distribution of people using it: those who build databases for a living, and those who query them.

There is something to be said for being able to rapidly prototype ideas, especially if your primary skillset is jockeying JSON in the context of web/app development. However, deciding whether or not NoSQL is the right fit for you or your project/business depends on how much of your time you will be spending getting down and dirty with the database.

Re: Startup Mistakes: Choice of Datastore

#76

Post by elvinyung »

maephisto wrote: post #18
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".

Well, I meant for startups, which I thought was implicit given that the original blog post was about "Startup Mistakes".

Yes, I agree that an key-value store that lets you do embarrassingly parallel reads and writes is useful for scaling, but has't it been said enough that You Are Not Google[1]?

[1] https://blog.bradfieldcs.com/you-are-not-google-84912cf44afb

Re: Startup Mistakes: Choice of Datastore

#77

Post by extrapickles »

edneypitta wrote: post #67
geophile wrote: post #46

Earlier quoted context omitted.

Yes and no. Yes, choose carefully at the beginning, and use relational. More specifically, use Postgres. But choose the right things to worry about at the beginning. So worry about something that can accommodate changing requirements, i.e., a relational database. Don't worry about scalability. You will be very, very lucky to ever have that problem. Worry about it then.

>something that can accommodate changing requirements, i.e., a relational database Wouldn't NoSQL be better suited for this scenario? Genuinely curious.

In general a SQL db will be a better choice for CRUD apps. They get slow if you try to recreate a SQL engine in your DB abstraction layer rather than letting the SQL engine do all the work.

NoSQL db should be used if you are doing something that they are designed for (eg: storing data that can’t have a schema).

Re: Startup Mistakes: Choice of Datastore

#78

Post by maephisto »

StavrosK wrote: post #51
maephisto wrote: post #41

Earlier quoted context omitted.

Well, this discussion here is now about Mongo

Regrettably :(

Uhmm, the article actually contained the phrases "Don't use Mongo" and "pick PostgreSQL" so it's kinda asking for a duel between the two in the comments.

Re: Startup Mistakes: Choice of Datastore

#79

Post by bmh_ca »

FWIW, my personal anecdote: I chose Google App Engine for a large enterprise application almost a decade ago and it's been absolutely, undeniably one of the best choices we made.

The application is locked into Google, but that hasn't proven a problem yet and can be designed around if need be.

Re: Startup Mistakes: Choice of Datastore

#80

Post by onion2k »

mamcx wrote: post #16
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.

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

A bad tech decision in a problem you can fix later, even if it's an expensive problem[1]. Having no customers isn't a problem you can fix later because your startup will fail and you'll have to close it. Consequently, at the start, you should work on getting paying customers over everything else, including prevaricating about what database to use. Anything is better than not making a decision.

All that said, "just use Postgres" as many people here are suggesting is actually pretty good advice.

[1] Unless it's so bad fixing it will sink your startup, in which case you have to live with it. That does happen but it has to be really bad.

Post reply on HN