For what’s it worth, Digital Ocean published a guide to host Supabase on your own GitHub - digitalocean/supabase-on-do · GitHub
Thanks for all the insights in this discussion on how each and everyone of you decides on what to use and not for your apps and stuff. It is a good reminder to me!
Because somewhere buried deep in my memories, every now and then one of the first BaaS solutions flashes up, which then suddenly changed strategy, and caused a lot of mobile app developers sleepless nights 
I would suggest to use managed version of these kind of tools until cost of this service is bigger than cost of self-hosted solution (actual cost of 2 servers, time of installing it, secure it, maintain it).
Also great is when people select technology which can be used as managed service or self-hosted version. It gives them huge power. On the beginning you don’t have to care about huge infrastructure, maintenance and use managed solution. In case cost of managed solution increased you can still go to self-hosted, or even when provider will change pricing or close support for it or close stack itself (for example Google did it couple of times).
Anyone who took this path, how did you manage DB migrations as in versioning database schema changes? thank you 
Supabase has built in tools to handle migrations
Or, if you were using supabase as the pg db for say a phoenix app, you could lean on the migrations in your app if all the tables created are managed by ecto migrations.
I had been exploring adding supabase to a django app as an api, and background task processing, etc, and I am also going to explore the same with phoenix