Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

Do you know if the size of the database (number of tables used) is a factor when choosing between Hibernate and JDBC?

Why or why not?

In my particular case, I am evaluating Hibernate and JDBC for interacting with Oracle database for a small web app.

share|improve this question
The number of tables generally does not (directly) matter. – Jeremy Heiler Aug 16 '11 at 13:42
When you say JDBC is better when Performance is critical, that is , result sets is large - what is the definition of large here ? – user114890 Jan 15 '14 at 18:40
up vote 8 down vote accepted

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.

share|improve this answer

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.