

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

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?<p>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?<p>It's a startup, the idea will change as time goes on.
======
patio11
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.

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

~~~
rmc
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.

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

~~~
traxtech
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.

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

------
antonioevans
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).

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

~~~
diminium
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?

~~~
rmc
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.

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

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

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

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

------
bsg75
Redis + PostgreSQL - best of both worlds.

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

