While doing TDD and adding features incrementally, do I design database ahead or add tables and columns while coding?

For me, this is a question with a "theoretical" answer and a "real world" answer.

In theory, you add a column as and when you need it, and you refactor your database as you go, because that's agile.

In the real world, your DBAs will kill you if they have to rebuild your test data every five minutes because you've changed the schema again. And in a smaller project, you'll get personally sick of having to spend half your time maintaining an unstable database.

As skaffman alluded to in a comment: database maintenance is generally more expensive than code maintenance. This is doubly true for rollout: you can roll an entire new application without a hitch, but try planning a live database upgrade without breaking your data.

It's a difficult discussion, because agile purists will insist that everything should be done "just in time." But, as in most things agile, the reality is that someone needs to be looking ahead of the next release. Priorities do change, but if there's not at least a vague idea of what the product will look like in 6 months then you've got bigger problems than development methodology...

The role of an architect (or tech lead, or chief DBA, or whatever flavour you have) is to be looking ahead those few months and planning for what you are 90% sure is coming, and part of that will be defining the data you're going to need and where it's likely to live.

So, perhaps instead of adding a column at a time, add a table at a time. Find the balance that suits your project and your development process, without doubling your workload.

If your tables are in Boyce-Codd Normal Form or better, then they should be quite easily used by any application without modification, assuming they actually store the data needed. The whole point of relational databases and relational modeling is to develop a data model independent of any application's search paths or commonly used queries.

And it is quite easy to design a properly normalized database "up front," at least if you know what the data being managed up front is.

The only reason you would need to "refactor" an RDBMS schema is if the original design was prima facie unacceptable to any competent eye. Now, some tablespaces or indexing might need to be tweaked, but that has nothing to do with the design.