76 karma · joined April 18, 2021
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.
Here's an article I wrote with a basic introduction to the NoSQL features of PostgreSQL: https://supabase.com/blog/sql-or-nosql-both-with-postgresql
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.
Your comments and questions are welcome!
[0]https://medium.com/wasmer/announcing-the-first-postgres-exte...
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.
Where's all those kernel hackers? Your help, we need. :)
At this point, the proxy is necessary because all the major browsers block direct TCP/IP traffic. They allow websocket connections so that's how we're getting around it.
There have been proposals to open up TCP/IP traffic but they've all been shot down so for the security implications.