For a customer database table, do I have other options, beside creating a custom module? I'm upgrading my site to Drupal 8.  

Currently, I have a custom module with a custom database table and I query that to provide historical data that is in the table. The data is really purely tabular and has thousands upon thousands of records.  

If there were fewer pieces of data, I would just create a custom content type.  However, I'm not sure that creating thousands upon thousands of nodes would make sense.

The database table includes the following fields.


Person
Product Sold 
Revenue Generated 
Month Sold 


Let's say I generate a few records per month.  

How should I handle this? Should I make another custom module to output the data?
Since you already have a module, I would rather not convert all the data in nodes.
I would not use nodes to store arbitrary data, since that is not the purpose of nodes, especially when I don't need to show all the data I store, or when I show a table with a pager only to the users with a specific permission. Nodes are by default readable by every registered user; making them visible only to users with a specific permission is not hard, but requires extra modules, and changing configuration.

With Drupal 8, there are few alternatives, but a custom database table is the easier solution, especially if you don't want to write migration code. 


If the data is linked to user accounts (which means, that person field is a username or the user ID), you could use the user.data service.
That service, though, loads all the data for the specified user ID, module, and key. You cannot tell to the service to load just the first, or the last, N records, for the fact the service doesn't have a concept of record. You could assign the data to different keys (for example, a key for June, one for July, etc), but that means making the code more complex.
If the data is only pertinent to a site, and you don't want to export it to other sites, you could use the state service, but this still load all the data associated to a key (not module, user ID, and key) at once. The workaround is the same for the user.data module, with the same cons.
If the data needs to be exportable to different sites, you could use the configuration API, but with much data, it's probable you would get some performance issues. (Yet, creating different, but related, records is not that immediate.)
You could create a configuration entity for your data. In Drupal 8, configurations entities are used for user roles, content types, image styles, and much more. 


The first three methods I described would not allow you to easily search for data as a SQL query would. The last one would allows you to get data using an API similar to the one used to query data from a database table.

If I wanted to quickly convert the code to Drupal 8, I would rather use the database approach I was using for Drupal 7. In that way, the data stored in the custom database table won't need any conversion when updating the site to Drupal 8, and you could easily control the users who access the data using a custom permission (in the same way you would do in Drupal 7).

If I wanted to make the code more "Drupal 8 code," I would use configuration entities. It requires to write code to migrate the data, but it's worth the effort.