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

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.

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.

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

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.

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.

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.

Redis + PostgreSQL - best of both worlds.

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.

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

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

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.

I hate to interrupt and go against the flow here, but it seems that some main points have not been mentioned.

First, the OP is talking about his 'business', no doubt a software and Web site based business, but still a business.

Here is the history of database for businesses in four easy steps:

Step 1.

In the 1950s with computers and then and before for a few decades, people did business computing with, say, files and decks of punched cards.

Step 2.

In the 1960s it was noticed that a small change in the business could result in too much programming; so the idea of 'database' was born. There for new purposes could add fields, links, etc. to the database without need to revise old software -- a huge point.

Approaches in the 1960s included hierarchical and network.

Step 3.

In the 1970s the mature conclusion from the experience of the 1960s was that a 'database' should be 'relational' with tables and relations. Each table had one column for each quantity and one row for each instance of those quantities. E.g., maybe in one table there was one row for each customer and one column for each quantity about a customer -- customer number, phone number, billing address, etc. A table usually had a key, and the table was in 'third normal form' so that each row was a function of the key, the whole key, and nothing but the key. Tables with relatively few columns could be combined, as needed for ad hoc purposes, into new, possibly larger, tables with 'join' operations based on 'relations'.

Leaders in this movement included E. Wong at Berkeley and M. Blasgen at IBM's Yorktown Heights lab. The Wong work resulted in INGRES, and the Blasgen work resulted in R* and later DB/2.

As database theory, the story was in good shape as of 1980. See, e.g.,

Jeffrey D. Ullman, 'Principles of Database Systems, Second Edition', ISBN 0-914894-36-6, Computer Science Press, Rockville, MD, 1982.

A relational database is usually programmed in 'structured query language' (SQL), and it is standard. SQL is easy to learn and fun to use.

Relational database systems take data integrity and security, system reliability, and data backup and recovery very seriously. A key to the functionality is the 'log file', and one result is the ability to backup a database while it is executing reads, writes (inserts, updates, deletes). If there is a hardware failure, say, power outage, in the middle of a large operation, then when the power comes back on the database will be put back in a 'consistent' state. There are extensions for parallelism, redundancy, and distributed implementation. The algorithms are advanced, and the software is mature and very thoroughly tested. E.g., a complicated operation is carefully 'complied' into a 'plan', and that with smart use of caching data in main memory commonly results in shockingly good performance. If a complicated operation is needed, then it will be difficult to beat the performance of just stating what is desired in SQL and letting the database software do the rest. There are mature tests of performance; see, the Transaction Processing Performance Council work at

http://www.tpc.org/

The performance achieved on the tests, from simple to very complicated, is astoundingly high.

For a business, relational database brings high 'flexibility': With well designed tables, relational puts the business in the best position to meet the data manipulation needs a few years in the future where the needs are not understood now. This one point is likely the most important reason for a business to take relational database seriously.

Well known relational database systems now include SQL Server, Oracle, DB/2, MySQL, and some more.

Curiously, conceptually the files in the punched card days were much like relational database now. So, one deck of cards corresponded to one database table. All the decks together corresponded to the whole database. In one deck, each card corresponded to a database row, and each field on the card corresponded to a datab...

I hate to interrupt and go against the flow here, but it seems that some main points have not been mentioned.

First, the OP is talking about his 'business', no doubt a software and Web site based business, but still a business.

Here is the history of database for businesses in four easy steps:

Step 1.

In the 1950s with computers and then and before for a few decades, people did business computing with, say, files and decks of punched cards.

Step 2.

In the 1960s it was noticed that a small change in the business could result in too much programming; so the idea of 'database' was born. There for new purposes could add fields, links, etc. to the database without need to revise old software -- a huge point.

Approaches in the 1960s included hierarchical and network.

Step 3.

In the 1970s the mature conclusion from the experience of the 1960s was that a 'database' should be 'relational' with tables and relations. Each table had one column for each quantity and one row for each instance of those quantities. E.g., maybe in one table there was one row for each customer and one column for each quantity about a customer -- customer number, phone number, billing address, etc. A table usually had a key, and the table was in 'third normal form' so that each row was a function of the key, the whole key, and nothing but the key. Tables with relatively few columns could be combined, as needed for ad hoc purposes, into new, possibly larger, tables with 'join' operations based on 'relations'.

Leaders in this movement included E. Wong at Berkeley and M. Blasgen at IBM's Yorktown Heights lab. The Wong work resulted in INGRES, and the Blasgen work resulted in R* and later DB/2.

As database theory, the story was in good shape as of 1980. See, e.g.,

Jeffrey D. Ullman, 'Principles of Database Systems, Second Edition', ISBN 0-914894-36-6, Computer Science Press, Rockville, MD, 1982.

A relational database is usually programmed in 'structured query language' (SQL), and it is standard. SQL is easy to learn and fun to use.

Relational database systems take data integrity and security, system reliability, and data backup and recovery very seriously. A key to the functionality is the 'log file', and one result is the ability to backup a database while it is executing reads, writes (inserts, updates, deletes). If there is a hardware failure, say, power outage, in the middle of a large operation, then when the power comes back on the database will be put back in a 'consistent' state. There are extensions for parallelism, redundancy, and distributed implementation. The algorithms are advanced, and the software is mature and very thoroughly tested. E.g., a complicated operation is carefully 'complied' into a 'plan', and that with smart use of caching data in main memory commonly results in shockingly good performance. If a complicated operation is needed, then it will be difficult to beat the performance of just stating what is desired in SQL and letting the database software do the rest. There are mature tests of performance; see, the Transaction Processing Performance Council work at

http://www.tpc.org/

The performance achieved on the tests, from simple to very complicated, is astoundingly high.

For a business, relational database brings high 'flexibility': With well designed tables, relational puts the business in the best position to meet the data manipulation needs a few years in the future where the needs are not understood now. This one point is likely the most important reason for a business to take relational database seriously.

Well known relational database systems now include SQL Server, Oracle, DB/2, MySQL, and some more.

Curiously, conceptually the files in the punched card days were much like relational database now. So, one deck of cards corresponded to one database table. All the decks together corresponded to the whole database. In one deck, each card corresponded to a database row, and each field on the card corresponded to a datab...