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

51–60 of 77 posts

Re: Supabase Vault

#51

Post by babbledabbler »

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…

This is true but for me the transparent abstraction over Postgres is actually a big plus though I can see that people who don't know postgres or SQL would be a little intimidated. I will say that postgres is the best SQL DB I've worked with and has become my goto.

In my experience there's no free lunch when it comes to high level abstraction over complicated systems. Also, having the option to draw upon the mountain of docs and info on the net about Postgres is nice to have in your back pocket. Of course the tradeoff is that you need to know SQL but I think that's a fair tradeoff.

I would like to see some more improvements over supabase js client api, but I hope they don't hide the fact that there's a relational DB under the hood and allow advanced access to the underlying postgres API.

I could see them making a nosql supabase over something like a mongo type DB like AWS does with document DB or even postgres jsonb fields. That would be nice feature. You could probably get a lot of mileage out of postgres JSONB fields.

I haven't used firebase much except for toying around with it but I think it's certainly a good option for simple nosql db for simplicity and speed of ramping up. Only thing with Firebase is that the cost is prohibitive at larger scale and you're going to be coupled to then when you get to that point so it could come as a rude awakening when your app starts to get a lot of users.

Re: Supabase Vault

#52

Post by fullstackchris »

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.

It's bullshit like this why I hate boomers and / or stuck up / and / or snobby / and / or ignorant software engineers, who, in the end, maybe aren't actually snobby, but just ignorant.

YoU cAn Go YoUr EnTiRe CaReEr AnD nOt UsE iT!!!

sure, this is true if:

- you don't work for / build / care about apps that have a persistence layer and serve more than about... let's say 20K daily users

- you don't care about perfomance

- you are confused

Postgres over:

- mongo: Postgres has ACID principles, where with Mongo you aren't sure you've saved ANYTHING at scale, there are multiple blog posts and humorous videos about them, i leave hunting them down to your discretion

- mySQL: don't even get me started, doesn't have any sort of plugin possibilities, is slower performance wise in literally ANY benchmark

- LiteDB: I know its the hacknews hipster rage, but seriously, you're going to rely on your entire backend via IO with a single file? ok, enjoy that one

sorry for the rant, i know it's not conducive to the hackernews mentality, but i've heard this rage and poking fun at postgres so many times, and nearly all have absolute NOTHING to with postgres' technical performance and much more to do with ego or some bullshit affiliation to some company and i'm sick of all of it and finally laying down the law:

Postgres is one of the BEST (if not THE BEST, bar none) databases currently available.

Re: Supabase Vault

#53

Post by michelpp »

zaroth wrote: post #26
michelpp wrote: post #18

Earlier quoted context omitted.

> Namely what will happen when you first restore some data into a new Postgres instance which booted with its own randomly generated root key (the wrong key) and then how you are supposed to patch in the correct key and be able to start reading secrets again? We restore you're original key into new projects. There is also WIP on accessing the key through the API and CLI. > Also, how does the decrypted view look if yo…

Thank you for the quick reply! I’m not a Supabase customer so apologies if the questions don’t make sense in your context. But I think it would help to understand if Supabase is fully managing key backup and recovery internally, how exactly is that working? Ultimately the whole value of TDE at the database layer comes down to two things IMO which are flip sides of the same coin; 1) Being able to store your database b…

> But I think it would help to understand if Supabase is fully managing key backup and recovery internally, how exactly is that working?

Supabase persists and protects your key and we will provide API and CLI access to retrieve it securely. This is a pre-release so we haven't worked out all the use cases yet but those are the basics for MVP.

> 1) Being able to store your database backups in less trusted locations,

Yes. Using Transparent Column Encryption you control on a column by column basis how your data is stored encrypted so you have more fine grained control over your data.

> 2) actually keeping the secret data secret, which amounts to keeping that encryption key secured at a much higher level than the database backup itself.

Yep, we don't have all the answers there, keeping the root key out of SQL is a big one. Maybe requiring MFA to access the key even with the API, there are a lot of possibilities. Thanks for your feedback these are all going into my notes for an upcoming release.

Re: Supabase Vault

#54

Post by fullstackchris »

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…

...and you managing your own secrets is way better than a third party?

wake up people, its all the same types of servers managing the same type of passwords with the same types of security layers, not one is better than the other! nobody has a 'secret sauce' to storing your passwords.

Re: Supabase Vault

#55

Post by zinclozenge »

aidos wrote: post #22
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…

It’s funny reading that comment from the other side of the fence. I’ve not looked closely at Supabase so I have no real opinion on it, but hearing someone say that you need to know Postgres to work with it is reassuring to me. Edit: don’t take that as a criticism, just more of an observation that there’s a target audience for which is probably hits a sweet spot.

Honestly, only to the extent that you need to set up your schema. But if your queries aren't too complicated, you can just use the client which is fairly straightforward.

Re: Supabase Vault

#56

Post by sofixa »

fullstackchris wrote: post #52
lghh wrote: post #36

Earlier quoted context omitted.

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

It's bullshit like this why I hate boomers and / or stuck up / and / or snobby / and / or ignorant software engineers, who, in the end, maybe aren't actually snobby, but just ignorant. YoU cAn Go YoUr EnTiRe CaReEr AnD nOt UsE iT!!! sure, this is true if: - you don't work for / build / care about apps that have a persistence layer and serve more than about... let's say 20K daily users - you don't care about perfomanc…

> Postgres is one of the BEST (if not THE BEST, bar none) databases currently available.

I would certainly expect the best database out there to be relatively straightforward to scale out. Posgres isn't. As a former SRE, redundancy > performance (for the differences we're talking about).

Re: Supabase Vault

#57

Post by armatav »

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.

You can't go your entire career without interacting with SQL, though - Postgres just happens to be the best way to do that.

Re: Supabase Vault

#58

Post by eddieroger »

mahmoudimus wrote: post #9
throwgawag1 wrote: post #3

> Vault is a thin usability-layer on top of pgsodium. Cloudflare and Duck Duck Go also add a bunch of names to routine things that already exist. It's better to just not name it.

Sorry, can you help clarify your comment? Do you mean that it's better to not call this "Supabase Vault" and just say "Secrets Management available in Supabase" ?

I figured there would be a comment like the one to which you responded, but didn't expect it to be the bottom one, downvoted to obscurity. Vault is an already heavily used word, with Hashicorp being the big player with it, and Ansible a second. There are a lot of words that could be used, and it is kind of a shame that one already associated to a big player in the secrets management game was the one used here.

Re: Supabase Vault

#59

Post by kiwicopple »

eddieroger wrote: post #58
mahmoudimus wrote: post #9

Earlier quoted context omitted.

Sorry, can you help clarify your comment? Do you mean that it's better to not call this "Supabase Vault" and just say "Secrets Management available in Supabase" ?

I figured there would be a comment like the one to which you responded, but didn't expect it to be the bottom one, downvoted to obscurity. Vault is an already heavily used word, with Hashicorp being the big player with it, and Ansible a second. There are a lot of words that could be used, and it is kind of a shame that one already associated to a big player in the secrets management game was the one used here.

That’s actually _why_ we used it - the name is well-used enough that people understand what it means and what it does without further description.

That said, this is good feedback - we’ll reconsider the name.

(If anyone else has an opinion for/against, let us know - the reason for this pre-release is specifically to get feedback)

Re: Supabase Vault

#60

Post by jackosio »

bastawhiz wrote: post #30
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…

My experience is that Firebase requires you to understand the ins and outs of Firebase, which has no real equivalent. Firebase is notorious for pathological cases and performance cliffs and other "gotcha"s; it isn't magic. Knowing what's going to perform poorly or become unmaintainable or otherwise cause problem requires you to have either prior knowledge or done something wrong and learned the hard way. At least wit…

Exactly, you do have to gain some understanding of Postgres yes, but it's SQL at the core which IMO is what you want 90%+ of the time, and you're not locked into their platform. When your company gets larger and you're ready to start wasting VC money on db admin and other problems that have already been solved, you can rip out Supabase and all the SQL will still work.
Post reply on HN