I would start by agreeing that this is an excellent use case for a database under most conceivable operating conditions -- and SQLite will very likely serve you well here.

That said, if you really want to keep the script-in-memory-hash thing going for some reason, and really do want to simply feed the data from your in-memory hash to all comers, you have your work cut out for you:

• You need to establish a communication method, such as a socket listener or some other kind of web service;
• You need to establish and deploy a data transmission packetization system, such as XML, SOAP, REST, JSON, etc.;
• You have to iterate across your hash to put the information out on the service, with a sister routine to decode that back into a hash on the other end for the client.

Now -- that would be a fun project, and you'd learn a ton of potentially useful stuff. But it will take time, and time is money.

You may have to invest time to learn DBIand  SQLite, but you don't have to build much enginery to make it work, so I would hazard a guess that it will take 1-4% of the effort needed to build all the machinery for the service-communication approach.

Not to mention that if you build your own framework, you will also then need to maintain it.

Unless you have a fairly strong reason to the contrary, I think the combination of SQLiteand DBIis going to be your friend on this one.