Please see my recent answer on SQL vs NoSQL databases for further information, but the most relevant part from it is:
When to choose a NoSQL database system over a RDBMS depends on a number of factors, none of which I would say primarily involve performance. But one of the main factors that is useful for determining when to choose which type of database system is based on the fact of if you have a well defined schema.
One of the primary benefits of a NoSQL database is the lack of strict schema enforcement. This allows the developer to not have to manage the schema as much in the data layer and defers when they do need to concretely define it until the data is consumed in the application layer.
The reason this is a benefit is because if you have a schema that changes very frequently, isn't well defined, or is outside of your control (such as ingesting data from external sources), then NoSQL gives you the ability to not have to manage it at the time the data is being stored in your database. Rather you can handle how you want to utilize a loose structure at the time the data is consumed, which is usually further down the stack (e.g. in the application layer).
If you have a concrete schema, or one that will change at a rate that's tolerable for you to manage in the data layer, then a SQL (RDBMS) such as PostgreSQL would be just fine.
The fact that you're able to articulate concrete objects (
posts) and properties of those objects (
content and some meta data like
author or date time stamp) is a sign you have a somewhat concrete schema. Also in the comments you mentioned "It will always be the same, header, content, metadata wise." which is another good sign your have a concrete schema and could utilize a RDBMS.
The problem is the length of each and the types of data we might potentially get
This is generally a non-issue as most modern database systems (both SQL and NoSQL) have the capabilities to store wide column data. For example, PostgreSQL has
TEXT column data types, which I believe
VARCHAR(N) can roughly hold up to 1 GB (approximately 1 billion string characters) of data in a single row, and
TEXT having no limit in the amount of data it can store. Some people do store raw image data in their relational databases though it's debated if that's generally good practice or not regardless of the type (NoSQL vs SQL) of database you choose - my opinion is to store the file path in the database to a file stored in a file system elsewhere.
So it's up to you to decide how well defined your schema is, how often it's likely to change, and if you want to manage those changes in the database. But there is no "best database" in this scenario, they'll all perform relatively equal.
You may find more useful information further reading another answer I wrote that goes more in depth on the details of concrete vs loose schema definition in the context of NoSQL vs SQL database choices.