4 ms·

A word of opinionated advice to anyone deciding on a database to use for their new project: Just go with something popular (MySQL, Postgres, Mongo, etc.), or go

A word of opinionated advice to anyone deciding on a database to use for their new project: Just go with something popular (MySQL, Postgres, Mongo, etc.), or go with an Amazon hosted cloud database if you really don't want to set anything up (RDS, SimpleDB, DynamoDB). There's no good reason to start a project with other databases. If you're worried about the scalability of something like MySQL when you haven't even got your first 1000 users, your priorities are messed up. Finish your product and get your users first. And I hope to god if you DO get your users and I ever have to maintain it, it's not running on some bullshit like Tokyo.

imsofuture 12y ago
I don't think this is terribly good advice. Many databases have specific domains in which they excel. I agree you shouldn't be worried about scaling before you have users, but you should absolutely evaluate different tools before picking one.
- emn13 12y ago
  What you're saying is true, but worrying about scaling before it's necessary is unfortunately common, and I've felt the pain caused by this (modern) premature optimization.
  - calinet6 12y ago
    Balance is the answer. This tends to be true of all things.
- tiquorsj 12y ago
  This is good advice. I've scaled multiple sites to +3 million registered users and more than 1 million unique visitors with heavy DB usage. This is excellent advice for starting out. Along the way we found areas that could be improved and we were able to move quickly to them because our underlying DB was standard stuff. We knew what areas were breaking down and then fixed them with targeted moves to other DBs and things like memcache. Yes, each DB has a specialty but a good general DB gets you a lot of mileage because those specialty DBs do very little a general DB can't but that is often not true the other way. You would never start a journey with cloudy destination and of a million miles by asking for a moon rover as your vehicle. As your journey develops you would start looking at other options or options for certain segments. Apps follow similar patterns.
MasterScrat 12y ago
What exactly is wrong with Tokyo Cabinet?
- raquo 12y ago
  I would guess, very few people have any experience with it, let alone know its quirks and good reasons to use it. I wouldn't build my MVP on obscure technologies just because they're hip or promise something useful when you have 1M users...
christiansmith 12y ago
This might be good advice if you're building cookie cutter systems for clients that have high turnover of contractors, but for startups I think it's horrible. I'd take one person that really groks devops and database internals well enough to make informed choices over a million one-size-fits-all SQL/Mongo+MVC devs. Any day of the week.
- pbiggar 12y ago
  What do you do when that guy quits?
- bdcravens 12y ago
  but for startups I think it's horrible. Why? Wouldn't it make more sense for startups to color within the lines, in terms of getting features to market faster? I'd take one person that really groks devops and database internals well enough to make informed choices Funded or not, a startup has the responsibility to turn every dollar into a feature that creates revenue, not architecture.
  - christiansmith 12y ago
    First, I never said "don't use SQL, even where it makes sense." The original commenter wrote, "advice to anyone deciding on a database". I strongly disagree with the notion that any practicing or aspiring creator should refuse to learn about and consider the full range of tools at their disposal, simply because there's a popular default choice. Specialized tools provide a form of leverage to those who understand and employ them wisely. Every problem I have ever come across that is sufficiently difficult and interesting to warrant forming a startup requires deeper insight on a technical level than "just ignore everything else and use X". Can you imagine if the founders of Google took this kind of advice?
    - deleted 12y ago
      [deleted]
    - bdcravens 12y ago
      Can you imagine if the founders of Google took this kind of advice? As a couple of examples, Google started on clusters of relatively commodity hardware. For years, AdWords ran on MySQL. Google's advantage wasn't in the innovative architecture, but rather, in the PageRank logic, which led to leadership in other areas. The architecture supports the innovation, which is the competitive advantage; the architecture isn't the competitive advantage.
calinet6 12y ago
Better advice: just use Postgres. Three reasons: 1) your data is probably relational, even if you think it's not, 2) if you have non-relational records, Postgres has JSON and hash storage types that perform better than most NoSQL databases, and 3) The architecture, standards compliance, and sheer capabilities of Postgres are all best in class. Seriously, if you want to read some good C, peruse the PostgreSQL source. Go Bears. Unless you're trying to do some analytics (in which case, find a column store), or want to use it and forget it (Amazon's database services; and RDS is Postgres), Postgres is the way to go.
- ahjones 12y ago
  RDS can be Postgres, but isn't always. You can choose from MySQL, SQL Server, Oracle and Postgres, but Postgres support is currently in beta [1]. [1]: https://aws.amazon.com/rds/postgresql/ https://aws.amazon.com/rds/postgresql/

imsofuture 12y ago

I don't think this is terribly good advice. Many databases have specific domains in which they excel. I agree you shouldn't be worried about scaling before you have users, but you should absolutely evaluate different tools before picking one.

emn13 12y ago
What you're saying is true, but worrying about scaling before it's necessary is unfortunately common, and I've felt the pain caused by this (modern) premature optimization.
- calinet6 12y ago
  Balance is the answer. This tends to be true of all things.
tiquorsj 12y ago
This is good advice. I've scaled multiple sites to +3 million registered users and more than 1 million unique visitors with heavy DB usage. This is excellent advice for starting out. Along the way we found areas that could be improved and we were able to move quickly to them because our underlying DB was standard stuff. We knew what areas were breaking down and then fixed them with targeted moves to other DBs and things like memcache. Yes, each DB has a specialty but a good general DB gets you a lot of mileage because those specialty DBs do very little a general DB can't but that is often not true the other way. You would never start a journey with cloudy destination and of a million miles by asking for a moon rover as your vehicle. As your journey develops you would start looking at other options or options for certain segments. Apps follow similar patterns.

MasterScrat 12y ago

What exactly is wrong with Tokyo Cabinet?

raquo 12y ago
I would guess, very few people have any experience with it, let alone know its quirks and good reasons to use it. I wouldn't build my MVP on obscure technologies just because they're hip or promise something useful when you have 1M users...

christiansmith 12y ago

This might be good advice if you're building cookie cutter systems for clients that have high turnover of contractors, but for startups I think it's horrible. I'd take one person that really groks devops and database internals well enough to make informed choices over a million one-size-fits-all SQL/Mongo+MVC devs. Any day of the week.

pbiggar 12y ago
What do you do when that guy quits?
bdcravens 12y ago
but for startups I think it's horrible. Why? Wouldn't it make more sense for startups to color within the lines, in terms of getting features to market faster? I'd take one person that really groks devops and database internals well enough to make informed choices Funded or not, a startup has the responsibility to turn every dollar into a feature that creates revenue, not architecture.
- christiansmith 12y ago
  First, I never said "don't use SQL, even where it makes sense." The original commenter wrote, "advice to anyone deciding on a database". I strongly disagree with the notion that any practicing or aspiring creator should refuse to learn about and consider the full range of tools at their disposal, simply because there's a popular default choice. Specialized tools provide a form of leverage to those who understand and employ them wisely. Every problem I have ever come across that is sufficiently difficult and interesting to warrant forming a startup requires deeper insight on a technical level than "just ignore everything else and use X". Can you imagine if the founders of Google took this kind of advice?
  - deleted 12y ago
    [deleted]
  - bdcravens 12y ago
    Can you imagine if the founders of Google took this kind of advice? As a couple of examples, Google started on clusters of relatively commodity hardware. For years, AdWords ran on MySQL. Google's advantage wasn't in the innovative architecture, but rather, in the PageRank logic, which led to leadership in other areas. The architecture supports the innovation, which is the competitive advantage; the architecture isn't the competitive advantage.

calinet6 12y ago

Better advice: just use Postgres. Three reasons: 1) your data is probably relational, even if you think it's not, 2) if you have non-relational records, Postgres has JSON and hash storage types that perform better than most NoSQL databases, and 3) The architecture, standards compliance, and sheer capabilities of Postgres are all best in class. Seriously, if you want to read some good C, peruse the PostgreSQL source. Go Bears. Unless you're trying to do some analytics (in which case, find a column store), or want to use it and forget it (Amazon's database services; and RDS is Postgres), Postgres is the way to go.

ahjones 12y ago
RDS can be Postgres, but isn't always. You can choose from MySQL, SQL Server, Oracle and Postgres, but Postgres support is currently in beta [1]. [1]: https://aws.amazon.com/rds/postgresql/ https://aws.amazon.com/rds/postgresql/