Probably the whole picture of how you want to use the data in your database needs to be considered to judge this properly. There are "escape hatches" like having a separate entity, which is called something like "ProductAttribute", with a foreign key being the actual "Product". The Product would still have attributes, which every product has, lets say a name, a product id, a creation date, etc., while ProductAttribute could contain any other attribute, not relevant for all products.

Why is this an "escape hatch"? Well, if you want to process that data later, it would most likely be very convenient, if you had all product attributes as columns, instead of having them as rows in another table. One would then have to translate back to the usual form of having them as columns. It is possible, but annoying. However, if you never need to analyze the data like that, then storing in this kind of extra table might solve all your use cases. It is ultimately a trade-off between safety or type strictness and flexibility (being able to add arbitrary attributes without having to change the schema).

Another, but in my opinion quite bad, solution is, to have loads of empty columns for future attributes. But it is really a terrible solution, running contrary to any good database design.