Let's see how you might solve this problem, as that imaginary DBA. Sure, this scenario isn't real, but it could be - that last part about Postgres definitely is. Postgres's open source pedigree, robust suite of features, stable internals, and awesome mascot Slonik make it a strong choice, and it's what you're already running. There's been a complexity freeze at the company, so you're not allowed to bring in any new technology, but you don't mind that because for v1 you would have picked Postgres anyway. Well, it's time to figure out how you're going to do it. You start to explain why it will be non-trivial, but the meeting ends before you can finish. "It sounds pretty simple" a colleague at the meeting remarks - "just an increment here and an increment there and we'll know which posts are seen the most on our platform". Why VARCHAR(256)? No particular reason, but you don't have time to get hung up on that or ask why - you just found out that the priority this quarter is tracking content views across all posts in the app. Your startup is seeing eye-boggling growth because everyone loves fitting their hot-takes in posts restricted to VARCHAR(256). You're head DBA at the hot new social site, SupaBook.
For a quick & dirty prototype, use hstore, which also performs the best with integer IDs. Tl dr: Use HyperLogLog, it's a reasonable approach with great trade-offs and no large architectural liabilities.