The size in tables is by no means a concern when having to choose between the technologies. How could that possibly affect your choice? When you can map and generate your entities automatically, it doesn't even require you to write more boilerplate code when choosing an ORM.
It's rather a question about the tradeoff between programming close to the database and having an abstraction, although both can be mixed.
In general, sometimes it's better to program close to the database, for example when there're performance-critical tasks to fulfill. This can be done with Hibernate mostly, too. Sometimes it's just too memory-intensive to fetch whole entities or generated queries run too slow and you need custom SQL. Then you could use JDBC for it, although Hibernate can query the database using native SQL, too.
There're only a few cases in which I'd choose JDBC over Hibernate, as the abstraction of an ORM greatly benefits a clean programming model. For example if I was dealing with a legacy database that heavily relies on stored procedures which can't really be mapped to entities. Then it's probably better to not have the abstraction layer at all and just use a result-set oriented technology, like plain JDBC. Another point for choosing JDBC over Hibernate is when you are programming close to the relational paradigm. Objects/Entities could just be in the way of such applications. Anything that is very result-set oriented could probably be easier implemented by just using JDBC.
JDBC is better when:
- Performance is critical (result sets are large, which is a killer for many ORMs, queries need to be fine tuned for the specific RDBMS)
- You're dealing with legacy databases/applications, which were coded in a heavily result-set oriented way.
However, nearly all other cases are better covered with an ORM like Hibernate, as in modern object oriented languages the benefit of code clarity outweighs other constraints.