I've not used DB's from Perl yet and am not familiar with the modules available, but if I was setting out to write something I think I would (probably) opt for something that used the *nix fork strategy? By which I mean:

When an object is created, it issues a select for the whole table (or possible several smaller chunks and accumulates) so that it has its data available for immediate read access. Then, when a record (or records if that makes sense) is updated, it writes back to the DB. Of course, this assumes that only this object ever has write access to that part of the DB.

If that scenario is true, but the updates are sufficiently large to mean that updates cause an unacceptable delay to the front end, then the updates could be queued to an update 'deamon' process. Something like the 'lazy-writeback' used on disk drives? This is not-trivial to get right, and is vunerable to power failures etc. If the DBM supports transactions, some of that can be mitigated, especially if the transactions to the DB were queued via disk, or probably better, in parrellel to disc and removed from disc once the transaction is confirmed.

Effectively, this is just re-inventing the well-known 3-tier model.