Last Tech Tuesday I offered some very rough guidelines for making technology choices in a startup. I was going to write today about how to evolve that over time, but one of the comments suggested that it would be great to pick something that won’t immediately require a massive rewrite if you hit user growth. So a bit more today on this initial choice. I agree with the suggestion but with an important caveat: make a choice where you don’t sacrifice agility. At the earliest stages the single most important technology feature you need is the ability to make rapid progress and make changes quickly.

Until very recently you were faced with a big tradeoff here: if you wanted agile you were likely making a big scalability tradeoff. Why is that? Because all the frameworks that were developed to support agile ran on top of relational databases with a “magic” ORM layer in between (object-relational mapper). The magic of an ORM works well at small loads but tends to have poor scaling characteristics. Now just to be clear here because I anticipate a fair bit of protest – your mileage may vary greatly. Modern hardware is crazily fast and you can get a long way with a beefy machine and with SSDs. But the further you go with that kind of setup the harder the eventual changeover is likely to be. In fact, so many of the companies in our portfolio and beyond had that experience that about 5 years ago I wrote a post titled “I Want a New Platform.”

Thankfully there is now an alternative. New databases and data stores have been developed (and continue to be developed) to allow for both agility at the start and very significant scaling. Collectively this group of databases has become known as NoSQL which is an unfortunate moniker that stuck. I am of course partial to MongoDB in this group as we are investors in 10gen, the company behind MongoDB. But depending on your specific application you might also want to look into Cassandra, HBase, Neo4J or DynamoDB. What all of these have in common is that they are schema free which eliminates the need for an ORM. In fact in many scripting languages you can persist or retrieve objects in a couple of lines of code.

The combination of scripting languages and NoSQL stores is a very powerful one. It gives you both agility and a much wider range of scaling. That’s not to say you might not eventually need to rewrite code to make it scale, but you will be able to get much much further and for many startups you might never need to resort to the highly custom code of a Twitter, Facebook or Google scale company.