(Not) Trusting your database
You should be able to somewhat trust the data in your database, but as defense in depth it is definitely better to not trust it.
There may for example be a limited SQL injection, which allows inserting data into the database, but nothing else (maybe because your database rights are managed correctly).
But now, an attacker gained object injection, and who knows what that may lead to.
You could use an HMAC to verify the integrity of your data. That way, you can be sure that what went into the database is the same thing that comes out of it (as long as an attacker doesn't have access to the key, which for example may be stored in the sourcecode).
PHP7 allows for an additional options parameter, in which you can specify what classes unserialize is allowed to create.
This already limits the power of object injection. An attacker can still overwrite fields in the object itself - which they can do anyways if we assume database write access - , which may not be harmful, but they cannot create arbitrary objects.
You could also perform some validation on the data before sending it to unserialize, such as collecting all
O:X strings and checking if X is an allowed object.
But I would definitely recommend the save unserialize solution from above.
Mitigation: Not having exploitable classes and functions
It is a good idea to check data and authentication on a per-function level. For example, you shouldn't just assume that field x can be trusted because it isn't (currently) user-controlled, and thus eg safe to pass to passthru.
Not storing objects
If you do not have a good reason for doing so, you shouldn't store objects in the database.