Does TDD include integration tests?

Golden rule of TDD says: Never write new functionality without failing test.

If you are not following this rule, then you are doing TDD partially (like writing unit tests only for several classes in your application). That's better than nothing (at least you know these classes do what required, but you cannot be sure that other parts of application are working and these classes can be integrated with them), but that does not guarantee your application works as expected. So, you need to start each feature with writing failing acceptance test, which guides your application design and defines application behavior (outer loop). While this test fails, the feature is not implemented by your application. Then you should write unit tests for separate units which will be involved in this feature (inner loop). The outer loop verifies that all classes involved in this the feature are working together as expected. The inner loop verifies that each class works as expected on its own.

Following picture from great book Growing Object-Oriented Software, Guided by Tests demonstrates these two feedback loops in TDD:

And the answer to your question is Yes - TDD includes integration tests. That's the only way not to break the golden rule of TDD.

AFAIK, TDD originally didn't distinguish between unit tests and integration tests. It remains that an integration test is generally much more costly in terms of resources you need to set up, which is why mocks were identified as a good practice even in early TDD literature.

From Test-Driven Development By Example ("Mock object" pattern) :

The solution is not to use a real database most of the time

Still, it shouldn't prevent you from writing a few other tests that verify if your production code plays well with the real database or expensive resource in question, if needed :

What if the mock object doesn't behave like the real object ? You can reduce this strategy by having a set of tests for the Mock Object that can also be applied to the real object when it becomes available.

All in all, I guess the whole integration vs unit test thing is orthogonal to TDD. In other words : having a small red/green/refactor feedback loop as your atomic building block doesn't determine which flavor of overall application development workflow you should pick or which other feedback loops should surround it - it could be acceptance driven as @lazyberezovsky explained, outside-in or inside-out, integration-centered or isolation-centered, etc, as long as you remain truthful to the test-first approach.

I would say in the 'normal' tdd cycles, red - green - refactor, the db access should be mocked. As for this unit tests are used and the tested part should be as small as possible. BUT, having integration tests is for every project a must.