I think you are conflating table with base. But in case you really want a new base for every day, that is a really bad idea. It’s not as bad as a table for each day, which is simply a lesser bad idea.
Your question cannot truly be answered in a helpful way until we know more about how the data needs to be used. You mentioned a query of all posts between two dates. If the posts are segregated by table or base, you will never get to see the results of such a query. Queries are designed to act on tables and views and the only way to blend or merge queries across multiple tables or bases is to build a query app that can proxy your data stores into a unified view.
I recommend you share with us how the data needs to be consumed before asking us how the data model should be designed. Failing to develop data use requirements and envision how information must be employed is how many solutions wind up painted into a corner.
UPDATE: From the looks of your data, it seems that these are log entries being generated from an app of some sort. Log data is typically voluminous (as you indicate) and Airtable is not the best storage model for logs. However, as Scott mentioned, imagine a day’s log entries in a single record.
This is an approach that allows you to store roughly 100k of log data in a single record as a JSON object. Given the data I see, the records are likely to represent a max of 300 bytes of data per entry. With that, you could store roughly 300 log entries in a single record and perhaps 500 log entries per record if compressed.
This approach (discussed with some detail here) does create other issues and responsibilities such as transforming the JSON objects into discrete entries when querying the data. But this can be overcome with scripting, etc.
This strategy will be of no use if your daily log events are greater than 300 events per day.
Suggestion - don’t use Airtable. Use a system designed for logging and analytics like ElasticSearch (free and open-source). Logs typically have no benefit being stored in systems that offer traditional database features such as relational modeling, form-handling, etc.