The big issue here is the idea of moving logic to the data, rather than data to the logic. One of these things is much bigger than the other. If you have a multi-statement transaction with intersitial logic, client-side logic is going to get absolutely smoked by a stored procedure.

There are downsides; suddenly logic in your app is split between client side and server side, which is annoying.

At VoltDB, we do our best to make the situation better than it is in more traditional systems.

- Stored procedures are Java, and can be unit-tested and debugged live.

- Stored procedures can be transactionally added, removed and upgraded in a cluster-wide operation that happens at a single-logical point in time.

- Stored procedure code (and schema) is archived with all snapshots, allowing for portability.

- You can run stored procedures on your laptop development machine, then push the same bits to a pre-production cluster, then push the same bits to production.

- Stored proceudres can share code and even use inheritance, reducing putting the same logic in many places.

One way to look at it is the set of prepared statements and procedures on your VoltDB cluster is sort of a state/processing-API. It works really well when you’re processing streams of events and you have one procedure per event type.