Amazon Redshift is based on PostgreSQL and as its documentation states you can use PostgreSQL JDBC drivers to connect to database. This way you can use our reverse engineering tool that can connect to your database and extract schema information to Vertabelo XML file. Then you should create empty database model in Vertabelo (choose PostgreSQL engine) and import XML file. Here you find detailed instruction how to use our reverse engineering tool:
https://www.vertabelo.com/blog/documentation/reverse-engineering

The second option you can try is dumping your database schema to sql file and import it directly into Vertabelo (we have import from SQL DDL feature). But I'm not sure if pg_dump works well with Amazon Redshift.

We don't test Vertabelo with Amazon Redshift but it should work.

The biggest format that we suppport now is B2 (500x707mm). In your case choosing that format give you about 10 pages and I hope reduce your pain. Unfortunately we can't support bigger format at this moment due to some performance problems.

Review of PDF print implementation is scheduled for January 2015. Stay tuned.

You can use public link functionality instead of sharing model in such case. You can set it on model details screen.

In Vertabelo we would like to concentrate on ER modeling. Diemensional modeling is not planned.

We don't plan such possibility. It is an element of our current business model. 

Vertabelo supports only crow's foot notation at the moment. Maybe we add others notation in the future, but it is not on our road map now. I leave the question opened, to allow other users vote for it.

There is no n:m relationships because of Vertabelo operates at the physical level, in which such type of relationship doesn't exists. At the physical level n:m relationship is decomposed into two relationships (n:1, 1:m) and a join table. We are planning some microfeatures that can simplify creating such decomposition. 

It is fixed and on the production.

We analyzed this a few months ago and decided not to do. The main problem is related to foreign key naming convention. Every database architect may have own naming convention, so it hard to follow it. 

Thanks for your suggestions. We rethink how to do it better.