- 31comments
- 18comments
- 515comments
- 126comments
- 1comments
- 211comments
- 73comments
- 162comments
- 31comments
- 66comments
- 136comments
- 227comments
- 7comments
- 86comments
- 21comments
- 53comments
- 49comments
- —discuss
- 23comments
- 37comments
- 35comments
- 9comments
- 6comments
- 363comments
- 46comments
- —discuss
- 104comments
- 34comments
- 39comments
- 39comments
Feature set of Postgres on AWS in the article omits Babelfish feature. It is definitely worth mentioning, at least for some unfortunate people who are stuck with SQL Server, but would like to use Postgres as all others do. When you can use BCP or OPENQUERY to move your data to Postgres, instead of COPY - this can make a big difference for some of us.
Nice comparison, but I would have found it more interesting and closer to reality if they enable HA.
Do what it’s worth supabase definitely feels slow to me. Neon, in contrast, feels lightning fast for my workloads.
for what it's worth i use supabase because it's the fastest way to get from 0-1 for app development. most backend stuff for getting off the ground is not very interesting so getting the graphql api, oauth integration, db migrations, some user authorization story for free is what i'm looking for from supabase.
I’m using Supabase for similar reasons but there’s one specific situation I’m trying to sort out.
Say you have a user “profile” which includes their privileges - like say a column named “privileges” which is some JSON object denoting what they can/can’t do.
Even with RLS, how do you ensure that a user can’t simply make a curl call with their own JWT to elevate their own privileges?
Basically, how to enforce column level security?
The best thing I can think of is to place “privileges” in a child table and only let the service account update that table.
You could create a trigger that always keeps the value the same unless user has privileges to change it. Or alternatively the RLS rule could check if the column is being updated and abort the call if it is. I’m using a different table that is read-only to regular users to accomplish this.
i think i would have permissions in a different table
Supabase is alpha testing column level security as a Feature Preview that you have to enable in your project. I’m using it now. Works well.
Have you checked out this repo: https://github.com/supabase-community/supabase-custom-claims?
The "raw_app_meta_data" stored for a user is not writeable by the user, so you can store roles and/or privileges in there.
Thanks for sharing. Wasn’t aware of this. Will check it out today.
For now, I figured I’d have an BEFORE UPDATE trigger which compares the md5(NEW.privileges::text) with md5(OLD.privileges::text) and raises an error if they don’t match.
Not sure how to bypass the trigger for service accounts.
I would like to also to see a comparison based on price, and not focused on matching the specs. Given $500 per month, which gives the best performance? At that price level, the different cpu architectures could make a significant difference.
They could test multiple datasets to see who handles large data sets best, high read/write ratio etc.
I don't think this is a fair comparison. You cannot put your db in cloud provider A and run your application in cloud provider B.
Why not? Latency?
When I use supabase, I'm really interested in an authenticated, isomorphic, strongly-typed JS client, that's also configured to listen to realtime updates to my database.
I would have liked to see how GCP AlloyDB fares in a comparison like this. I don't know whether AWS and Azure have similar offerings, if yes, these would have been interesting as well.
I believe AlloyDB is GCP’s flavor of AWS Aurora.
The best of all though: Planetscale /s