Hacker News Reader

You say JDBC is slow, but what if you're using PreparedStatements and PreparedStatement caching? Isn't that similar?

JDBC doesn’t have to be slow. VoltDB actually caches ad-hoc SQL plans so even they run pretty fast these days. You can use JDBC and get good performance.

The biggest thing you lose with JDBC over the native VoltDB clients is better cluster awareness. In our native client you can get callbacks when servers fail, when backpressure is triggered, etc…

Now Hibernate over JDBC is another issue.

Edit: As merb points out JDBC is synchronous. This is true; if you have one client and one thread, this will be limiting fast. It's not a server-side issue though. If you have enough clients and/or enough threads, then you can still get very high throughput.

I see, I was reacting to the slide that mentioned ODBC and JDBC are slow.

It makes sense that no matter the context, forcing the DB engine to parse and plan SQL it hasn't seen before could be quite a bit slower than parsing/planning it once and swapping in new parameters for each query.

Actually JDBC is synchronous, this could be a real pain. But there are alternative's to most databases around.

Reply on news.ycombinator.com