>So.. going to write your own reporting solution as well?
I already have. The reporting code doesn't change to accommodate this. The interface to the data model doesn't change. You have heard of data abstraction before haven't you? If you mess with stored procedures, you're still tied to the nipple of a DB vendor's tit. If the business logic code access the DB through your own procedures written in in-application code, then it's easy to adjust to a different storage model.
>Or does management not need any reports?
Well we own the company and so I write exactly the reports that we need. The accountant gets the transaction data in exactly the form they need to automatically reconcile with bank records. Apparently all her clients with the quickbooks tools can't do that.
>Any guidelines from regulators viz. your storage and ability to audit the data?
Nope. Personal data isn't in the PoS (point of sale) system. Financial transaction stuff (credit card info, etc.) is in PCI-DSS compliant kit. That doesn't change. The PoS is about an efficient storefront (checking out purchases) and inventory management.
>Most modern RDBMS do have in-memory tables. SQL Server 2016 has them
That's lovely, but I don't need an RDBMS. The properties of time series data (people buying things) allows a nice post hoc recombination at the back end and allows the front end (at checkouts) to carry on regardless if they lose contact with the back end, so no "The computers have gone down, we can't sell you this". It is all already in tables, then synced to the database on the server. The actual design change is to store transactions locally on disk - it's only a handful of bytes per transaction - in such a way that you can pull the plug and reboot the front end and have it carry on from the point it was switched off including the contents of the current transaction that was being input. This is not a hard problem, it just requires knowledge of designing sound transactions (in the computer sense) and you can formally prove they are right with tools like spin. I can't even start python database connector without a bunch of hacking on the platform.
> It even runs on Linux nowadays
So does the existing PoS software, which I wrote and the staff like because I iterated the design with them in the loop. It exists explicitly because off the shelf solutions were slow and cumbersome.
>All in all I think if the application was critical, I'd take out a license for an off-the-shelf database that does this already.
It is. It's the conduit through which we sell things. But it is based on a well polished bit of software that essentially bug free and keeps running year after year. I wouldn't risk commercially licensed software. What happens when it breaks, or it requires and os upgrade or it just goes out of fashion?
However the substance of my comment was to agree with the comment before which suggests that large data tools are no applicable to most situations and I have a situation that fits that hypothesis, where the transaction rate is 10s of thousands per years. There are no Petas involved. I wasn't requesting a lecture on how to run our business.
Don't apply for the job of DB admin, we aren't hiring.