For partial caching the caching is global and not specific to a user / session. In this case it's probably not even worth caching the navigation as the most expensive part of that operation will be determining the linking mode - which in turn needs to be uncached. You could write your own cache key which takes the url of the page + url of the user + last edited information to form a string but unless all your visitors are hitting one page you'll more likely have cache misses then hits.

Using partial caching doesn't avoid all database hits. Aggregate functions still do database lookups to ensure the pages / dataobjects haven't been updated but the benefit of this is it uses a very simple query and avoids expensive queries like joins, sorts and building large datasets. SilverStripe will still also have checks for permission.

Partial caching is designed to augment a fully working site and caching specific expensive operations, not replace all operations. By the sounds of it you would be better suited to static caching which will not require *any* database queries. The pages will be recached when you publish them and that's it. The rest of the time with static caching is pure html serving which is as fast as you'll get. When deciding which method to use (or you can use a combination of both) you've got to weigh up the pros and cons of each and decide on what you really need.