HN user
Curious to see how many of those million databases are from free users.
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.
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.
Just as a note, Supabase received SOC2 Type 2 compliance last week (we've had Type 1 for a long time already) and now we're working on HIPAA.
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.
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
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.
Here's an older repo[0] I put together to show how to do some custom auth stuff. Take a look and see if you can use some ideas from here.
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.
Your comments and questions are welcome!
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.
This exists, but with limitations: [0][1]
[0]https://medium.com/wasmer/announcing-the-first-postgres-exte...
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.
Oh, so it's not related to PostgreSQL. I'm super interested in new and different uses for WASM. This could open some new doors.
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. :)
Wow, this is awesome! So as I understand it, this uses Postgres and JSON fields to emulate the features of MongoDB, sort of as an abstraction?
I'm curious -- what's the intended use case for this? This is something we could try to add if gives some cool new functionality.
I love how you guys are already pushing us to think about performance issues on this project. Hacker news really pushes technology to the next level!
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.
You can email me at mark @ supabase dot io. (Yeah, I know there are probably robots that can parse that as valid email address, but I'm old-school :))
I'm not familiar with WASI but I'll take a look. We're using Buildroot now and it's nice and small, but we could make it smaller by optimizing the kernel. Now, if I only know how to optimize the kernel without breaking things :)
Where's all those kernel hackers? Your help, we need. :)
Would love to chat! Love to get your ideas on this.
This is cool! It's running debian and posgres 11. It's quite a bit larger (that's why we went with Buildroot, and frankly, we could do a lot better at trimming things down even more). But it's definitely a great implementation!
You're absolutely right, you can use a local pg. This just makes it easier for me, as it's sort of a "sandbox" environment and I can easily take snapshots to do A/B testing or roll things back. I can also send a snapshot to a coworker so they can get my entire environment with all my data in a few seconds.
Supabase developer here. Yes we'd love to collaborate on a native WASM version. I tried this first before starting on this project and I didn't get very far. I'll have to go back to my tests on that, but it seemed like WASM wasn't yet capable of compiling Postgres due do some libraries not being supported. Hopefully we can find workarounds or push WASM into a new era of compatibility :)
Supabase developer here. I've tried compiling directly to WASM, but it did not go well. As I recall, there were features used by PostgreSQL that WASM didn't support yet. This is definitely something we'll revisit though, especially as WASM matures!
Interestingly we can do this, sorta, but in Chrome only. Using arp you can open a network between multiple tabs of the same Chrome instance, putting each browser vm on a different private ip. I only see this useful, though, for testing clustering systems. There won't be any outside internet connectivity in a setup like this though.
Supabase developer here.
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.
Also, in case you're curious, PostgreSQL logical replication to the browser wasm instance DOES work. I've done it. :)
Supabase developer here.
I've used this to move data from a live Supabase database down to the browser for testing and playing around with things in a "sandbox" environment. Then I save snapshots along the way in case I mess things up.
To move a table over from my Supabase-hosted postgres instance to the browser, I just exit out of psql and run something like this:
pg_dump --clean --if-exists --quote-all-identifiers -t my_table -h db.xxxxx.supabase.co -U postgres | psql -U postgres
Keep in mind if you try something like this, our proxy is rate limited for now to prevent abuse, so it might not be super fast. It's easy to remove rate limiting at the proxy, though.