データベースに関して、２つ質問させてください。
①データベース側でカラム毎にuniqueや、not nullの設定はできないと思っているのですが、認識に間違いないでしょうか？
下記のような、リンクを見ていると、おそらく、登録するときの制限で、事実上のuniqueの設定はできそうですが、データベース側では設定できない認識ですが、間違いないでしょうか？
（UserのEmailはuniqueになっているようですが、それ以外の項目を任意に設定できるか？または、not nullのような設定は可能かという意味で質問しています。）
②Userのパスワードは、CSVでExportできないのですが、設定次第では、CSVに吐き出す事は可能なのでしょうか？
passwordをまた別のカラムに保存するようなことをさせない限り、CSV Exportは不可能でしょうか？
たとえば、bubbleでの運用後にデータベースを外部に切り替えたい場合、既存のデータを全てExportする必要がある為、質問しております。
(1)だけですが。
①データベース側でカラム毎にuniqueや、not nullの設定はできないと思っているのですが、認識に間違いないでしょうか？
はい。データベース側にそのような設定はできません。
ユニークさを保つには、自動で付与されるレコードのunique idを使うか、入力時にチェックするしかないと思います。
（2）については、どのように設定してもExportはできなかったと思います。
また、Bubble内部でパスワードもハッシュ化されていると思われるため、Exportできたとしてもハッシュ化アルゴリズムに何を使っているか、saltはなにか？などがわからないと載せ替えできたとしてもパスワードは不一致になります。
移管前提であれば、他サービスのOAuthなどを利用してBubbleアプリケーションにログインさせることを検討する方が理想的です。
この場合、OAuthでログインする時の情報を保存しておいてそれを載せ替える方法で、（載せ替え後にOAuthの承認は必要ですが）アカウント情報は変化せず使用できます。
@jansnap
ご回答ありがとうございます！
@yukikun
ご回答ありがとうございます。
「他サービスのOAuthなどを利用して」とありますが、何かおすすめのサービスはありますでしょうか？例えば、AWS Cognitoとかでしょうか？
移管前提であれば、他サービスのOAuthなどを利用してBubbleアプリケーションにログインさせることを検討する方が理想的です。
OAuthを利用している各種Webサービスと連携させるのが良いかと思います！
Google、FacebookなどのOAuthを使うのはいかがでしょう？
コメントありがとうございます。
Google、FacebookなどのOAuthを使うのはいかがでしょう？
↓GoogleやFacebookやtwitterと連携すれば、将来的なスクラッチ開発の可能性にも対応できる（つまりは、OAuthでログインする時の情報をbubbleのUserデータで持つことで、同データをexportして、外部のDBに移し替えることができる）と教えて頂きましたが、「通常のemail+passwordでのログイン」と「最初はbubbleで開発しつつ、後からスクラッチ開発に切り替える」ということを両立するのは不可能でしょうか？
（「最初はbubbleで開発しつつ、後からスクラッチ開発に切り替える」前提ならば、認証は、bubbleがサポートするGoogleやFacebookやtwitter等のoauth認証のみとなり、「通常のemail+passwordでのログイン」は諦めなければならないでしょうか？）
もちろん、スクラッチ開発後にパスワードをユーザーに再入力させることはせず、bubble側で使っていた、パスワードをスクラッチ開発後も使い続ける前提です。
ユーザーのパスワードを通常のフィールドとして保存しておけば移管はできます。
ただ、プレーンで保存してしまうとセキュリティリスクが高いので、最低限SHA256などでハッシュ化したものを保存する流れになるかなと。
方法としては、各ユーザーがパスワード設定をする時に、パスワード設定値にSoltを足してハッシュ化。
このハッシュをユーザーと紐付け可能なテーブルに保存（userテーブルでも良いですが切り離しておいた方が無難です）。
移管する時は、ハッシュアルゴリズムとSoltをセットで新環境のパスワードアルゴリズムとし、ログイン情報をそのまま利用できるようにする。
SHA256などのハッシュアルゴリズムなら不可逆なので、万が一ハッシュ値が流出しても元パスワード特定はほぼ不可能なので、比較的安全です。
ありがとうございます！
完全にクリアになりました！