You could use sqlite. It can store a lot of rows and work on many operating systems (Windows, Linux, Android, MacOSX).
You could consider installing and using some Linux system on that single PC and develop your system on that (perhaps as a web application using some database), and use some free software RDBMS like PostGreSQL or MariaDb (or MySQL, very close to MariaDb). They are capable of dealing with a lot of rows (see this for PostGreSQL, and this and other things for MySQL). In practice, the limits are constrained by the hardware capabilities.
I have decided to develop an MS Access file-based desktop application.
That might have been not the best decision. You should consider free software alternatives (like those mentioned above), and you might think of some web application (usable from several browsers, perhaps on cheap tablets).
Notice that RDBMS of hundred of millions rows are routinely deployed on Linux systems running PostGreSQL or MariaDb (or MySQL, a near equivalent).
Whatever technical solution you think of, don't forget to backup the data very periodically and to define some backup procedure (and to check once in a while that you are able to restore from the backups).
Most of the cost is probably related to your development time and efforts and to your skills. That is probably more costly than the hardware or any software license you'll need.
If I can anticipate correctly, this design is destined to fail.
This is false if you use a real RDBMS on a Linux system (those freely available on most Linux distros), or if you use sqlite. Your design is valid (and you could use free software for it; all the products mentioned here are free software). Your choice of database and of operating system is questionable. BTW, developing from scratch your own POS software might be more expensive than using existing solutions (and you might even find, adapt and improve some free software ones).
For instance, after only one week, DailySales table will become so huge that the database
10000 more rows each day is tiny. Most RDBMS (and sqlite) can handle that. In 3 years, that means 10 million rows, not a big deal. Of course you need to dimension the disk correctly (but assuming 4Kbytes of disk space per row, 40Gbytes is not much; probably in your case each row consumes only several dozens of bytes). But your database is small or tiny w.r.t. to today's practice. Don't be worried by the number of rows (but do define correctly relevant database indexes, they are related to the queries you'll make). Most databases can very easily handle many dozens of millions of rows (if your database schema is good enough), this is not an issue today. So you don't have a "huge number of rows" but a rather small one.
If (for a reason you did not explain) you need to develop a desktop software (not something running in a browser) you could develop some desktop application with a GUI on Linux using some RDBMS (e.g. using Qt). However, a web application could be used from several cheap tablets. And you can find HTTP server libraries (e.g. Wt or libonion, for C or C++ on Linux) to develop it (see also this).