I think most of my fellow commentors got the point, there is no good and bad as such at least in software development, it depends almost entirely on the context you want to use the database. For the "persistent storage" relevant context of your application you can formulate your requirements to a "database management system". My fellow commentors have outlined many possible requirements to "persistency": efficiency, cost, standardization, host-language integration, portability, current access, volumnes, data integrety upon failure, atomicity of transactions with the database, what you actually want to do with the storage, why are storing it anyway, what are your query requirements etc.

Even you say for example Oracle, you will have formulate your requirements, since many database management systems cover a wide range of application profiles and therefore need/can to be customized to your specific requirements. This often not even the easiest thing to do.

One requirement is also how and with which language(s) you want to access the "persistent storage". Since your have written to Perl Monks, i assume you want to access the "persistent storage" with Perl. Here you have also a wide range of options, all very valid applied in the "right" context.

You have "perl managed persistency options" for "streaming" perl data, like FreezeThaw, Data::Dumper and Storable. All great for what they do.

You have "database interfaces" for perl for various different database technologies, relational and others:

You can write your own "persistency option" with good old files:

All most probably great options depending on the context, i would not want evaluate, without knowing your requirements .....i am aware that these are not so much "database" options, but options accessing "persistent" storage, but maybe that input will also help to find the "right" database