You should always use get_post_meta. Your attempt to micro-optimise using a raw SQL query will reduce not improve performance.
When you fetch a post, WordPress bulk fetches its meta for performance reasons, so if you used get_post_meta it would already have the answer in memory. If your site has an object cache then it would remember it from previous requests too.
Whereas if you used raw SQL, not counting that WordPress itself uses SQL too, you would have lots of small database queries that you have to wait for, even if WordPress already knows the value of that meta.
You’ll also be introducing plugin compatibility issues as none of the filters get_post_meta runs will be available, and some plugins short circuit these values or manipulate them to implement features.
If you’re wanting to build your own table, know that you’ll be giving up all the optimisations WordPress has, and there is no guarantee it will be faster. Having a custom table doesn’t make thing faster, not unless it’s designed correctly with appropriate indexes to be fast for particular kinds of queries. You’re likely to find the table is actually slower.
Generally though, the pivotal piece of information most WP developers are unaware of that impacts significantly on performance, is that the post meta table is optimised for finding values when you already know the post ID/key. It is very poor at searches and filtering, aka find all posts that have a key with this value, or does not have that value. This is why taxonomies exist, and why tags/categories are not stored as post meta. Taxonomy tables are optimised for finding/filtering/searching for posts.
If you find yourself needing meta_query in your WP_Query arguments then consider changing those values to custom taxonomies and terms as meta_query can be extremely slow, and its performance degrades quickly as the post meta table grows in size.