Going for a star schema design involves more considerations than just what database will be storing the data.
One immediate reason to elect a star schema design is its simplicity and expressiveness: as a rule of thumb, business transactions are modeled using fact tables and business entities (or business "context") are modeled as dimension tables. One practical consequence of this design is that your data will be easier to understand and use by business users, regardless of whether you are using SQL or a BI/visualization tool like Tableau or PowerBI.
Virtually any RDBMS will fully support a star schema and, in some cases like Oracle, it can use special (bitmap) indexes to optimize the typical query patterns over a star schema. This has been the case for (at least) the past 15 years, where data warehouses of all sizes have been implemented in virtually any major RBDMS.
You can do the same in Redshift: define your data model (the star schema), build the data structures (the tables), load data into it accordingly and query it as usual. The star schema will simply be more expressive (thus, easier to use) than having unrelated or complex table structures; in this case, it will actually be mostly a sort of metadata layer that abstracts the data's complexity. Here's a post detailing a benchmark that measures Redshift's performance and support for star schema queries, using the industry standard TPC-DS benchmark: https://blog.fivetran.com/warehouse-benchmark-dce9f4c529c1
You don't even need a "proper" database to enable a star schema design, e.g. you could actually dump files on HDFS and still design a star schema over these using Hive, simply for the sake of making it easier to use, because Hive will give you a SQL interface over HDFS and the star schema will make the SQL simpler and easier to understand.