Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Supabase Vault

supabase.com

Post reply on HN
Print view View original

41–50 of 77 posts

Re: Supabase Vault

#41

Post by danenania »

byteshock wrote: post #32
nicoburns wrote: post #4

Hmm... I feel like secrets are the one thing I don't want to be in Postgres... because I want to store my Postgres credentials in the secrets vault! And I certainly don't want to have to update the configuration for every service which accesses my secrets vault every time I upgrade my Postgres database (and the access URL changes). IMO nobody's doing secret management for small companies / products particularly well,…

I’m confused on why secret management considered secure. Maybe I’m missing something. Why is letting a third party managed your secrets is secure? So if that third party gets compromised, they now have access to all your secrets. Amazon or other company employees can also view your secrets. If your server gets compromised, the secrets that are accessible via that server are also compromised. Isn’t that the same impac…

Speaking for EnvKey (mentioned above—I’m the founder), we use client-side end-to-end encryption to address this concern. Secrets cannot be accessed on an EnvKey server.

I’m biased, but I share your skepticism of secrets management services that don’t use end-to-end encryption. It’s not a wise choice for either the service provider or its users.

Re: Supabase Vault

#42

Post by no_wizard »

justsomeuser wrote: post #33
brap wrote: post #17

I’m really impressed with everything Supabase does, but… They market themselves as the “open source alternative to Firebase”. Which is great, mainly because you don’t have to worry about vendor lock-in (to an extent). Yet one of the main selling points of Firebase (at least in my humble opinion) is that you don’t have to concern yourself at all with implementation details and stuff like that. The learning curve is sm…

With Firebase you have a team managing the service uptime. When I last checked, Supabase is a group of processes that you manage yourself. This means that: - A. If something goes wrong or you need to customise something, it would be quite complex to fix as you have all these different processes and code bases to understand. The sum of depended-on lines of code for all the open source code bases in Supabase would be m…

At some point you’re married to something right? At least you can Supabase to be self hosted even if that has warts.

You just can’t do that with Firebase

Though I’d argue that people overthink the value in being able to self host “just in case”. If it’s ever truly a concern you have you should use more vendor agnostic solutions

Re: Supabase Vault

#43

Post by OJFord »

lghh wrote: post #36
jononomo wrote: post #29

Earlier quoted context omitted.

In my humble opinion, if you're a software engineer in the modern world, then learning Postgres is about as fundamental to your job as learning to dribble would be to a job as an NBA basketball player. It is the just the foundation of almost everything else.

You can go your entire career and never use Postgres. It’s pretty easy to, actually.

I agree 'software engineer' is too broad, but it'd definitely take non-trivial effort (and perhaps some otherwise pointless resigning) to avoid it in domains/companies/roles that could use it, or similar alternatives.

Re: Supabase Vault

#44

Post by burggraf »

no_wizard wrote: post #42
justsomeuser wrote: post #33

Earlier quoted context omitted.

With Firebase you have a team managing the service uptime. When I last checked, Supabase is a group of processes that you manage yourself. This means that: - A. If something goes wrong or you need to customise something, it would be quite complex to fix as you have all these different processes and code bases to understand. The sum of depended-on lines of code for all the open source code bases in Supabase would be m…

At some point you’re married to something right? At least you can Supabase to be self hosted even if that has warts. You just can’t do that with Firebase Though I’d argue that people overthink the value in being able to self host “just in case”. If it’s ever truly a concern you have you should use more vendor agnostic solutions

> people overthink the value in being able to self host “just in case”.

This. I'm guilty as charged here over the years. As I've grown older I've realized a few things. Nothing is, or ever will be perfect. Nothing lasts forever, so trying to build for what might happen in the future usually hampers what you do in the present. (IOW, don't worry about what might happen. Just build with what you have now and do the best you can. If what you build lasts until the next wave comes and makes it all obsolete, call that a win.)

Re: Supabase Vault

#45

Post by [deleted] »

brap wrote: post #17

I’m really impressed with everything Supabase does, but… They market themselves as the “open source alternative to Firebase”. Which is great, mainly because you don’t have to worry about vendor lock-in (to an extent). Yet one of the main selling points of Firebase (at least in my humble opinion) is that you don’t have to concern yourself at all with implementation details and stuff like that. The learning curve is sm…

[deleted]

Re: Supabase Vault

#46

Post by [deleted] »

jackconsidine wrote: post #40

I'm so excited for Supabase. As soon as they move Realtime Subscriptions out of alpha / beta, I will replace Firebase on all new projects. The Firebase / Firestore analog - Snapshot Listeners - give your application a real-time backend for free and simplifies state management drastically since your subscriptions are your store. Supabase being built on SQL is interesting to me- I love PSQL and the row-level security r…

[deleted]

Re: Supabase Vault

#47

Post by [deleted] »

jononomo wrote: post #29
brap wrote: post #17

I’m really impressed with everything Supabase does, but… They market themselves as the “open source alternative to Firebase”. Which is great, mainly because you don’t have to worry about vendor lock-in (to an extent). Yet one of the main selling points of Firebase (at least in my humble opinion) is that you don’t have to concern yourself at all with implementation details and stuff like that. The learning curve is sm…

In my humble opinion, if you're a software engineer in the modern world, then learning Postgres is about as fundamental to your job as learning to dribble would be to a job as an NBA basketball player. It is the just the foundation of almost everything else.

[deleted]

Re: Supabase Vault

#48

Post by jahewson »

cpursley wrote: post #27
brap wrote: post #17

I’m really impressed with everything Supabase does, but… They market themselves as the “open source alternative to Firebase”. Which is great, mainly because you don’t have to worry about vendor lock-in (to an extent). Yet one of the main selling points of Firebase (at least in my humble opinion) is that you don’t have to concern yourself at all with implementation details and stuff like that. The learning curve is sm…

You just learn Postgres/SQL as you go. And I've gotten much better at it (schema design, functions, querying) after adopting Hasura (similar idea as Supabase). It's an investment that will pay off for any developer and will outlast whatever cool framework of the month. But yeah, there's room for more higher level abstractions on top SQL databases. Metabase actually has a nice UI for building queries. Maybe something…

Different use cases. Metabase is OLAP, Supabase is OLTP.

Re: Supabase Vault

#49

Post by cpursley »

jahewson wrote: post #48
cpursley wrote: post #27

Earlier quoted context omitted.

You just learn Postgres/SQL as you go. And I've gotten much better at it (schema design, functions, querying) after adopting Hasura (similar idea as Supabase). It's an investment that will pay off for any developer and will outlast whatever cool framework of the month. But yeah, there's room for more higher level abstractions on top SQL databases. Metabase actually has a nice UI for building queries. Maybe something…

Different use cases. Metabase is OLAP, Supabase is OLTP.

Yes. What I'm saying is the Metabase query builder is cool. Could be really useful for making a database view this way (generating the schema change in the background).

Re: Supabase Vault

#50

Post by cpursley »

justsomeuser wrote: post #33
brap wrote: post #17

I’m really impressed with everything Supabase does, but… They market themselves as the “open source alternative to Firebase”. Which is great, mainly because you don’t have to worry about vendor lock-in (to an extent). Yet one of the main selling points of Firebase (at least in my humble opinion) is that you don’t have to concern yourself at all with implementation details and stuff like that. The learning curve is sm…

With Firebase you have a team managing the service uptime. When I last checked, Supabase is a group of processes that you manage yourself. This means that: - A. If something goes wrong or you need to customise something, it would be quite complex to fix as you have all these different processes and code bases to understand. The sum of depended-on lines of code for all the open source code bases in Supabase would be m…

If Supabase goes away at least your schema and data are still in Postgres.

What happens if Firebase goes away? Or you outgrow the NoSQL model (which you will).

What happens when you get acquired by big Java corp? They're going to toss aside your web layer and rewrite it in some old version of Java. But they will keep your data model and that's easier to do with SQL.

Post reply on HN