When to use BaseFieldDefinition instead of hook_schema While creating a new information for Drupal 8, I came across 2 approaches to create a new column on the entity table on database:
* use hook_schema() (as I was used on Drupal 7) (https://gist.github.com/pedrorocha-net/3ed63f33b513d9c9ff86)
* extends ContentEntityBase and use BaseFieldDefinition (https://gist.github.com/pedrorocha-net/70d6a84c3ddba1c5939d)

Both alternatives creates the table for me, with the data, but I think the latter already provides me more integration with other Drupal components e.g. Views module. By the other hand, being an "Entity" I believe brings some "weight" to the data, as it works with some wrappers(on Drupal 7 at least).

What i'm doing is port the Voting API module, so this question about extra weight can really impact on sites with more content.

Any thoughts?
The question that you are really asking is if you should be using the entity system or not. You only have one option depend on the answer to that.

Yes, there is considerable overhead especially when using content entities. But things like nodes and comments are entities too, and you can have hundreds of thousands of those. It doesn't really depend on how many are stored but how many are accessed and processed on typical requests. If it's common to load a large amount of them (not just calculate aggregates like how many votes but actuall load the whole thing), then entities might not be such a good match.

Drupal Core only has two primary types of entities, content and config entities. You could also define your own lightweight entity type that is completely custom, but then you again need your own storage class, table creation and so on.

But as you said yourself, being a (content) entity gives you a lot functionality, like CRUD, views integration, REST and many more that you possibly don't need for your use case.