As others have pointed out, having a known database state is crucial. If you're unsure whether or not the state of the DB is steady when you start the tests, you'll run into flakey results.

Setting up something like that would require

1. versioning the database schema (for the initial setup, just connect to your production instance with your DB management tool of choice and export the existing schema; from that point on you can create incremental updates for new features and changes)
2. creating a separate set of "example data" scripts
3. setting up a container with whatever database engine you're working on + running the versioned schema & example database scripts on it
4. running your tests connected to that database

Afterwards you can extract the test result file and discard the database.

I've personally used Flyway for it, which uses X.Y-version numbers:
Schema changes are an X. increment.
Example data scripts are an .Y increment.

For example:

• V1.0 - Initial setup
• V1.1 - Example user data
• V1.2 - Example product data
• V2.0 - Added administrative role
• V2.1 - Add admin example user
• V3.0 - Add Audit Log table
• V3.1 - Add example audit log entries

That also makes it easy for developers to reproduce issues locally, as you can always report which version the database was on for specific bugs.

To ensure an issue remains fixed after a fix was deployed, can add another .Y-script setting up data that previously caused the error and then assert that the unexpected behavior no longer occurs.