How deep should you go into database schema design during an interview?

There seems to be inconsistent expectations across interviewers about how deep to go into database schema design during a system design interview. Some interviewers want to see actual table schemas, including primary keys, foreign keys, and maybe a few key columns for critical entities. Others just want a high-level entity-relationship diagram or a discussion about the types of data stores you'd use. I've found myself in situations where I spend too much time on detailed schemas, only to be told it's not necessary, or conversely, I keep it abstract and then get pushed for more detail. For example, if designing a social media platform, do I need to map out the `users`, `posts`, `comments`, `likes` tables with their specific fields and relationships, or is it enough to say 'we'll use a relational database for user and post metadata and a NoSQL store for analytics?' What's the general consensus or a good heuristic for deciding the appropriate level of detail here? I want to show competence without over-indexing on an area that might not be the interviewer's focus.