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

81–90 of 119 posts

Re: Startup Mistakes: Choice of Datastore

#81

Post by notacoward »

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.

> If MongoDB lets you prototype faster

Does it? Even a prototype involves some iteration, which can be derailed by the kind of missing-schema problems that the OP mentions. Throw in a few operational problems, and your prototype isn't really any faster than something with better features and reliability. What's better for that first few lines of code on your laptop might not even get you to a prototype.

Re: Startup Mistakes: Choice of Datastore

#82

Post by davidgh »

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.

If your goal is to build a sustainable business you must address two questions: Will I provide value people are willing to pay for? Will I be able to find those people profitably? Both answers must be yes.

You might be able to answer one of the questions without an MVP but very unlikely to answer both without. So you need to ship something.

It would be clearly stupid to not consider your technology choices at all in the early stages. But the best decisions are usually the ones that allow you to determine the answers to both questions as soon as possible. Because if you aren’t able to eventually answer yes to both questions you will not build a sustainable business.

If you are providing value, people are paying you and you can find customers, the technology sins from the past can be addressed. It might be really hard. But at least you’ll be working on something that matters.

Spending a massive amount of time on getting it “just right” will most likely teach you that you’ve developed the perfect solution to a problem no one cares about.

Speaking from experience of being involved with two acquisitions of companies I started (on the selling side) I can tell you that the “technology stack” discussion is a tiny footnote to the discussions on revenue, sales, customer lifetime value, etc.

Re: Startup Mistakes: Choice of Datastore

#83

Post by StavrosK »

bmh_ca wrote: post #79

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.

My personal anecdote is the exact opposite of yours. I picked GAE for one of my personal projects years ago and it has been terrible. You can't do certain kinds of lookups unless you build the indexes first, there are no delete cascades, no intra-table constraints, etc.

I suspect the difference between us is that you spent the time working around these problems, whereas I expected it to just work.

Re: Startup Mistakes: Choice of Datastore

#84

Post by notacoward »

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

The fact that it's used today might just reflect choices made (and possibly regretted) ages ago. It doesn't prove that anyone's making that choice today, or refute a claim to the contrary. Also "MongoDB/NoSQL" is a slippery phrase. There are plenty of people who use other NoSQL databases who would never have touched MongoDB with a twenty-foot pole, so your statement's truth varies according to which part of the subject you look at.

Re: Startup Mistakes: Choice of Datastore

#85

Post by robinwassen »

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.

RMDBs often has great schema migration tools which usually are no problem to use on small datasets.

NoSQL often rely on handling difference in the data model in the application layer, which can become messy and cumbersome if you switch a lot of requirements.

Re: Startup Mistakes: Choice of Datastore

#86

Post by elvinyung »

Kpourdeilami wrote: post #66
maephisto wrote: post #18

Earlier quoted context omitted.

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

NoSQL is the most useful when you're dealing with event data which aren't the main part of the application. We use MongoDB for analytics on our API endpoints because storing that kind of data in postgres will add unnecessary bloat to it

Hi Kash. Genuinely curious, any other reason to choose MongoDB for analytics? It seems like a poor choice if you want expressive queries for data science.

Why not just directly `COPY` your log files to something like Redshift?

Re: Startup Mistakes: Choice of Datastore

#87

Post by maephisto »

jihadjihad wrote: post #75

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 yo…

yes, yes, yes.

Re: Startup Mistakes: Choice of Datastore

#88

Post by BukhariH »

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.

Also, later on if you decided that a RDBMS doesn't suit your needs it's significantly easier to migrate RDBMS -> NoSQL versus the other way around.

Re: Startup Mistakes: Choice of Datastore

#89

Post by StavrosK »

beagle3 wrote: post #70
StavrosK wrote: post #32

Earlier quoted context omitted.

Don't use SQLite for production, for all the love I have for it, the client libraries are usually locking accesses and don't work properly with concurrent reads/writes.

Concurrent writes block each other, but following one-time "pragma journal=wal", read and writes can work concurrently, and you can expect x2-x5 performance (or ~2% degradation, depending on use pattern, but most people see x2 performance). The cost is that access through network e.g. NFS or SMB in wal mode is impossible (but you shouldn't have done that anyway), and that you can't just ship the sqlite file - ship a…

Agreed, SQLite is a fantastic piece of software. Thanks for the WAL tip, I didn't know it wasn't enabled by default.

Re: Startup Mistakes: Choice of Datastore

#90

Post by logicallee »

StavrosK wrote: post #32
frik wrote: post #29

Earlier quoted context omitted.

TL;DR: "just use an MySQL or Postgres or SQLite"

Don't use SQLite for production, for all the love I have for it, the client libraries are usually locking accesses and don't work properly with concurrent reads/writes.

have you ever had an issue with that?

There are only 7 billion people, most of whom don't need your database updated faster than their ping time...

seems like a non-issue.

Post reply on HN