Supabase developer here. It shouldn't (and doesn't) take a week to migrate 40GB, I'm sure most of that time was strategizing, analyzing, and testing things. Supabase is pure Postgres running on AWS, so migrations are pretty straightforward. Things mostly depend on where you're migrating to/from, and the network latency between the source and destination. 40GB should take minutes in most cases.
Supabase developer here. We're big fans of Pocketbase here and love the stuff they're doing. I did some work with it early on and it's great, but since I'm not a Go developer, I found the customization options pretty lacking. I wish they'd develop a way to write custom code in Typescript or some other way to write custom database functions. I'm excited to see what's in store for the future of Pocketbase (as I've always been a fan of Sqlite and it's compactness and simplicity.)
Supabase developer here: keep in mind that, while PostgreSQL is unapologetically SQL-based, it's support for JSON and JSONB fields give it a lot of the powers of NoSQL. These days the lines are becoming more blurred.
Note this was written before edge functions were released, so it may make more sense to make these calls from edge functions, depending on what you're trying to do.
SQL or NoSQL? These days it's a religious argument (tabs vs spaces, anyone?) I've been using SQL since the late 80's, and spent several years working with NoSQL offerings. There were some really great things about using a document-based database -- mainly being able to take a block of JSON from my front-end app and throw it into a database. That was great.
But over the years, some of my NoSQL projects made me start to yearn for those things that are super easy to do in SQL, but can be a pain with a document database. Quick aggregate queries to answer business questions: How much did we sell of this product last month in each region? Or I'd want to change the schema of my data, and it would be a pain to do that in a document database. I'd have to write a script to migrate the data, and then I'd have to change my code to use the new schema. Or else my code started filling up with code to manage the schema. if (typeof total_sale !== 'undefined')...
Once I figured out that it's easy to throw JSON data into Postgres, I was able to get the best of both worlds. I'm not saying SQL is always better -- it totally depends on the application and what your needs are. But I've also been bitten before by "oh this is easy to do in NoSQL because the data is just a simple document" followed three months later by "the app is working great -- but now can we do X, Y, and Z?" And I'm thinking "why didn't you ask for those things before we built the app? I should have done this in SQL." Ugh.
It’s a busybox shell that does quite a bit. Plus you have pg_dump which you can use to shuttle data from an external database to the local database or vice-versa.
Yes, we can include postgis. I'm currently investigating how to include other PostgreSQL extensions as well. A fair number of standard extensions are already included, but there are more we need for a full Supabase implementation.
Why Postgres? (There's already a WASM version of SQLite [0], btw, and it's very cool.) We did this with Postgres for a number of reasons:
1. It's a slightly difficult task, and in doing this we hope to spur others to think about using WASM to run things they didn't think were possible before. Before Crunchy did this, nobody really knew this was possible. This project is a framework for you to port something new and exciting to run under WASM in the browser. What's that going to be?
2. We love Postgres. It's our favorite database and this tool gives us a quick and simple sandbox to try out new things that might mess up our production (or even dev) database. Got a crazy idea that might not work? Try it in the browser and if it doesn't work, refresh the page and start over.
3. My goal is to eventually have an entire version of Supabase running in the browser as a basic dev / experiment tool. This would make a great quick and easy way to try out Supabase, or even to do full scale development, after which you can migrate your data up to your staging or production databases.
So I've been using this for a couple weeks now on my mobile phone. There's really no reason to do this, other than I'm sitting in a car waiting for my wife to come out of the grocery store and I just feel like writing some some SQL code -- because I can. If you noticed, there's a little keyboard icon at the top of the demo that toggles on a mini keyboard with ^c, ^d and cursor keys. That's because the iPhone doesn't have those keys, and I'd start pinging a server and realize I can't break out of it and now I need to reset the whole emulator. Anyhow, that's why that little toggle is in there. :)
Yes, you probably could do that. It's something I've considered. Early on before I got the networking working through the proxy I found a way to use arp to connect multiple browser tab versions of this in a pseudo-private-network configuration. It only works locally and only works inside chrome, and only a single instance of chrome at that. But it was cool idea and the only use case I could think of was setting up a local cluster of Postgres instances within the browser. And my kids think playing video games is fun! Meh.
A LOT! Probably most.
But Supabase is committed to the free tier and it's not going anywhere. It's crucial to helping demonstrate all the features and the DX to developers.