Doctrine or own database layer

Good Evening fellows,

Last night I commit some changes to github (see at last post). To test that code works properly, I checked out it. (Or checkouted? Sorry for that.) And I realized, I had to modify an accessibility modifier in Doctrine's code. (One variable from private to public.) I had to take this change, because Doctrine has it's own autoloader support. But at the beginning of my development, I decided to use as well. And as we know, two autoloader don't work at the same code. So I built in Doctrine's autoloader in my one, but to work fine, I had to access to $_loadedModelFiles. That's the story. However, I'm wondering, which way I should continue my development. What do you think? The options:

1 - I keep Doctrine, because it is awesome, and create a subclass of Doctrine to populate it with an accessor
2 - Drop this idea and write a thin database layer/connector with a medium level of security features

To make a good decision, I list some pros and cons:

Why I should keep Doctrine?
- it's fully tested
- secure
- OO based
- use the hydrated technology
- use cache
- you can describe relationships between tables, and Doctrine will find out when you try to use something like this: $user->boss->company->ceo->hometown->postcode
- its done
- universal (mysql, postrgesql, oracle, sqlite...)

Why not?
- its huge, probably you don't need it in small sites (and with large sites you chose another framework:)
- its not mine
- you have to download separately
- mess up my autoloader
- not the best for optimizing database queries (I think so, but it could be a very stupid thought)
- its huge (again)

I guess, Doctrine should have to go. But I will break my head on it this week.
Anyway, If you could suggest me anything... please, I would be glad about it.

Cheers!