Ask HN: It's 2012, what database solution do you now pick for a Web 2.0 site? | Hacker News Reader

Ask HN: It's 2012, what database solution do you now pick for a Web 2.0 site?

5 pointsdiminium17 comments

Congratulations, it's now the year 2012. Your ready to start a brand new Web 2.0 Website. Now all you need to do is pick a persistent storage (aka a database). Which one do you pick now?

You can choose the traditional paid SQL Server, Oracle or maybe the traditional unpaid MySQL. Older ones came up to replace it such as PostGresql. Then comes the nontraditional such as Cassandra, HBase, MongoDB, and so forth. With all these choices, which one does one now pick? How about if your not 100% sure how your site will scale in the future?

It's a startup, the idea will change as time goes on.

View on HN

Pick whatever one the founding team will be most productive on. Now, try your damnedest to find a business where scaling problems are even on your radar.

How do you know which ones the founding team will be most productive on? Especially if none on your team are database pros?

Ask them what they have used most. Or if they haven't used a database, what framework are you using? Use the recommended one for that framework.

Ask whoever will be doing the programming.

After a couple of years of trying out most of the cool new NoSQL databases that have shown up as of late, I keep finding myself coming back to Postgres. The only new 'database' that I still use (and love) is Redis.

I love PostgreSQL. I'm using it now on a startup project to seamlessly store and use graphs with 1M+ nodes and 25M+ links. The lack of pain surprises me.

I'd say pick the one that's compatible (or has great libraries) for what you are working in (eg. .NET, Rails, Django etc.). Especially in the beginning of a startup project, it's important to maintain efficiency.

From what I've seen, most start out with a RDBMS and switch to hybrid RDBMS/OODB later on. I've also seen some switch entirely to OODB from RDBMS and back into a hybrid.

There's also a case for schemaless document oriented databases like MongoDB. Honestly, I haven't seen 'serious' uses of document oriented databases other than for distributed caching.

In general, 'big' data needs structure.

One of days it might even become common to see most browsers support indexeddb (sql like) and local storage (kvp like).

So back to my point; efficiency, compatibility and familiarity is key for rapid application development, which is a must have for start-ups.

I think patio11 give great advice. Pick one that your founding team is comfortable with but I have a few suggestions.

If you are going to bring in off shore guys/gals it will be hard to find them proficient in some of the newer dbs. So the learning curve and cost inefficiencies maybe create a lost of momentum (time) for you. If I were to build my framework from scratch I would probably still use MySQL for certain thing but definitely move to a NoSQL (mongodb/dynamodb).

"older ones"? PostgreSQL is not an "older database". It is still being actively developed and used.

I was trying to say older that lost ground for a bit but is now turning into a highly recommended database option.

As for old, doesn't PostgreSQL have roots dating all the way back to 1982?

So does emacs, vim, BSD, Microsoft Windows, etc.! Just because some started a long time ago doesn't mean it hasn't been updated and should be ignored.

Go with MySQL or PostgreSQL. Most of the programmers are savvy with them. This will give time to put your MVP in place and then you can work out a more scalable solution when time comes.

Early optimization is the root of all evil.

It definitely depends on your team and what you guys are most experienced with. I like with with MySQL, but lately I've been working on some .NET projects where I had to use SQL Server and I love it.

If you don't have an informed opinion, then pick the one that your framework lists as compatible. Multiple? Pick the one that seems to be first among equals in your framework's choices.

Redis + PostgreSQL - best of both worlds.

Depends on your use case, the app you're building and the structure of your data.

There isn't a one size fits all solution.

Appengine + BigTable, bam. And I can move on to building the business (or finding one)

Reply on news.ycombinator.com