5 ms·

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

• antidoh 14y ago
  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.
• patio11 14y ago
  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 14y ago
    How do you know which ones the founding team will be most productive on? Especially if none on your team are database pros?
    • rmc 14y ago
      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.
    • petervandijck 14y ago
      Ask whoever will be doing the programming.
• rmc 14y ago
  "older ones"? PostgreSQL is not an "older database". It is still being actively developed and used.
  • diminium 14y ago
    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 14y ago
      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.
• kellros 14y ago
  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.
• dagw 14y ago
  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 14y ago
    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.
  • deleted 14y ago
    [deleted]
• factorialboy 14y ago
  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 14y ago
  Redis + PostgreSQL - best of both worlds.
• baptisteHM 14y ago
  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.
• bazookaBen 14y ago
  Appengine + BigTable, bam. And I can move on to building the business (or finding one)
• antonioevans 14y ago
  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).
• edgardcastro 14y ago
  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.
• HilbertSpace 14y ago
  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/ 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 database column. It was common to sort a deck on a column. Given two decks sorted on a common column, it was common to 'collate' the two decks and create a third, and that operation is essentially a relational database 'join'. Broadly, the basic operations needed to do well manipulating database data have been known for nearly 100 years. Step 4. As the Internet and Web servers grew in importance, there have been needs for special purpose database systems with, compared with relational database, more performance but less functionality and generality. So, we have NoSQL, key/value stores, etc. Most experienced programmers know some SQL, and even if they do not it should be easy for them to learn and start having fun with SQL quickly. A program in SQL is just simple text and is easy to type, comment, and read. For the fun, J. Bezos at Amazon had fun early on when he saw how easy it was to get some really nice information about Amazon's business from a simple query typed in as SQL. For using relational database in a startup, the main management issue will be the need for the expertise of a 'database administrator' (DBA). For a startup, first, hopefully it's reasonable just to f'get about a DBA, keep everything simple, and do the work in-house. For background, read the chapter on database in, say, Jim Buyens, 'Web Database Development, Step by Step: .NET Edition', ISBN 0-7356-1637-X, Microsoft Press, Redmond, Washington, 2002. and then read the first chapter of Ullman above. Second, as the work gets more challenging, get a good phone number, call, and ask questions of some person who does DBA work full-time. Paying a high hourly rate to such a person will still be much cheaper than having a good DBA in-house. E.g., for working through some tricky issue in security or performance monitoring will be much easier if call someone who considers such things full-time. If get to be a big company, then, sure, have lots of in-house database expertise. So, net, for the BUSINESS, use relational database. For some special purposes in, say, high performance Web site architecture, maybe start by just using relational database but when more performance gets to be crucial move to special purpose tools. Really, the special purpose tools are not directly competitive with relational database. E.g., at my Web site, I'm keeping all the important data in relational database. But in one case, for one special purpose, some data in the relational database is read into some simple files and used read-only with very high performance, maybe off SSD or just in virtual memory. In another case, I'm implementing a simple key/value store, a baby Redis, so simple it is easier for me to program what I want than even to read the Redis documentation. What I am programming can knock the socks off relational database in several respects and do well for my company until it is so big I can let others worry about what else to do. But, for my BUSINESS, including all the important data in my Web server farm, that's in relational database. Period.
• NY_Entrepreneur 14y ago
  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/ 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 database column. It was common to sort a deck on a column. Given two decks sorted on a common column, it was common to 'collate' the two decks and create a third, and that operation is essentially a relational database 'join'. Broadly, the basic operations needed to do well manipulating database data have been known for nearly 100 years. Step 4. As the Internet and Web servers grew in importance, there have been needs for special purpose database systems with, compared with relational database, more performance but less functionality and generality. So, we have NoSQL, key/value stores, etc. Most experienced programmers know some SQL, and even if they do not it should be easy for them to learn and start having fun with SQL quickly. A program in SQL is just simple text and is easy to type, comment, and read. For the fun, J. Bezos at Amazon had fun early on when he saw how easy it was to get some really nice information about Amazon's business from a simple query typed in as SQL. For using relational database in a startup, the main management issue will be the need for the expertise of a 'database administrator' (DBA). For a startup, first, hopefully it's reasonable just to f'get about a DBA, keep everything simple, and do the work in-house. For background, read the chapter on database in, say, Jim Buyens, 'Web Database Development, Step by Step: .NET Edition', ISBN 0-7356-1637-X, Microsoft Press, Redmond, Washington, 2002. and then read the first chapter of Ullman above. Second, as the work gets more challenging, get a good phone number, call, and ask questions of some person who does DBA work full-time. Paying a high hourly rate to such a person will still be much cheaper than having a good DBA in-house. E.g., for working through some tricky issue in security or performance monitoring will be much easier if call someone who considers such things full-time. If get to be a big company, then, sure, have lots of in-house database expertise. So, net, for the BUSINESS, use relational database. For some special purposes in, say, high performance Web site architecture, maybe start by just using relational database but when more performance gets to be crucial move to special purpose tools. Really, the special purpose tools are not directly competitive with relational database. E.g., at my Web site, I'm keeping all the important data in relational database. But in one case, for one special purpose, some data in the relational database is read into some simple files and used read-only with very high performance, maybe off SSD or just in virtual memory. In another case, I'm implementing a simple key/value store, a baby Redis, so simple it is easier for me to program what I want than even to read the Redis documentation. What I am programming can knock the socks off relational database in several respects and do well for my company until it is so big I can let others worry about what else to do. But, for my BUSINESS, including all the important data in my Web server farm, that's in relational database. Period.