Unfortunately I can't give you a 'yes' or 'no' answer to the question of the separate database because it depends on too many surrounding items including, but not limited to, the capacity of your systems and business requirements.
Two things that I can suggest you need to think about:
a) The connections or network bandwidth use of the separate database could impact on the data being sent from the primary to the secondary instance. I'm not saying it will, it is just a possibility to consider.
b) If the availability group 'fails over' so that the current secondary is the new primary then the users of both databases will be connecting to the one server. Can it cope with that load?
There might be other things, these are just the two I thought of.
I would suggest you make sure that you monitor the health of the availability group including the data replication status.
Also is there any connection between the database in the availability group and the separate database? If there is then how is that going to work if a failover of the availability group occurs.
Another point, and I apologise if I'm stating the obvious, make sure that whatever configuration you use that your backups and restores work in any situation. As an example if you have a failover of your availability group then do the backups still work OK and can you still restore the data. Availability groups increase system availability but they don't protect you from data deletion, viruses e.t.c.
Are you using SQL server Enterprise or Standard?
If you have any further questions then something that might be worth you doing is providing a listing of your setup. I am thinking of something like this:
Server A - SQL Version 2017 Enterprise
Server B - SQL Version 2017 Enterprise
Database A - Basic availabililty group on servers A and B
Database B - Basic availability group on servers A and B
Database C - Only on server A
Listener A - For database A
Listener B- For database B