TE
科技回声
首页24小时热榜最新最佳问答展示工作
GitHubTwitter
首页

科技回声

基于 Next.js 构建的科技新闻平台,提供全球科技新闻和讨论内容。

GitHubTwitter

首页

首页最新最佳问答展示工作

资源链接

HackerNews API原版 HackerNewsNext.js

© 2025 科技回声. 版权所有。

Supabase Vault

198 点作者 traviskuhl将近 3 年前

8 条评论

zaroth将近 3 年前
One thing I think missing from this write-up is to walk through how the Restore process will work with encrypted data under pgsodium.<p>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?<p>Also, how does the decrypted view look if you try to read it with the wrong key loaded?<p>Do you have to worry about a race condition where you boot an instance with some encrypted data but forget to put the key file in place, and then end up with a new random key, saving some new data, and now you have a mix of rows encrypted with two different keys? Or will the whole subsystem block if there’s data stored that can’t be decrypted with the resident key?
评论 #32534060 未加载
评论 #32533868 未加载
brap将近 3 年前
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).<p>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 small, you get a database without having to think about databases.<p>Yet everything I read about Supabase is heavily centered around Postgres, it seems like you really need to know the ins and outs of the database. I wouldn’t really feel comfortable adopting Supabase without taking a class in Postgres first.<p>I’m wondering if Supabase plans to stay “low level” or give a higher level of abstraction to those who want it.<p>Edit: just want to clarify, I’m not saying “sql bad”, I’m saying there’s a not-so-small market (mostly beginners) who would see this as a big adoption barrier, which I think is understandable. I don’t know if Supabase wants to (or even should) cater to both markets.
评论 #32534367 未加载
评论 #32534086 未加载
评论 #32534931 未加载
评论 #32534151 未加载
评论 #32534473 未加载
评论 #32534074 未加载
评论 #32534589 未加载
评论 #32534330 未加载
评论 #32534842 未加载
jackconsidine将近 3 年前
I&#x27;m so excited for Supabase. As soon as they move Realtime Subscriptions out of alpha &#x2F; beta, I will replace Firebase on all new projects. The Firebase &#x2F; Firestore analog - Snapshot Listeners - give your application a real-time backend for free and simplifies state management drastically since your subscriptions are your store.<p>Supabase being built on SQL is interesting to me- I love PSQL and the row-level security rules are incredible. But the historical SQL v NoSQL debate involves the trade-offs of Consistency, Availability, and Partition Tolerance [0]. With Firebase (and typically NoSQL) you lose Consistency and you get a bit of redundance by virtue of using onWrite listeners as opposed to Joins. That model scales really well since it&#x27;s amenable to sharding seamlessly. What will scaling a Supabase backend look like?<p>[0] <a href="https:&#x2F;&#x2F;www.bmc.com&#x2F;blogs&#x2F;cap-theorem&#x2F;" rel="nofollow">https:&#x2F;&#x2F;www.bmc.com&#x2F;blogs&#x2F;cap-theorem&#x2F;</a>
评论 #32534844 未加载
nicoburns将近 3 年前
Hmm... I feel like secrets are the one thing I don&#x27;t want to be in Postgres... because I want to store my Postgres credentials in the secrets vault! And I certainly don&#x27;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).<p>IMO nobody&#x27;s doing secret management for small companies &#x2F; products particularly well, so there&#x27;s definitely a niche to be filled here. But I&#x27;m not quite convinced this is it...
评论 #32533615 未加载
评论 #32534212 未加载
评论 #32533685 未加载
评论 #32533490 未加载
评论 #32534449 未加载
评论 #32533562 未加载
评论 #32533437 未加载
tmd83将近 3 年前
What I don&#x27;t understand (perhaps I haven&#x27;t found the right docs to read) is how to safeguard the secret if a client machine of the secret is compromised. Say I have a web server that&#x27;s connecting to the database and the database credential are stored in some separate value. If someone get&#x27;s access to the web server machine can they not access the value from there?
评论 #32535939 未加载
评论 #32534096 未加载
vbezhenar将近 3 年前
Is there any solutions for postgres database encryption at rest (other than using OS-level encryption)?
评论 #32534108 未加载
wizwit999将近 3 年前
Why put everything in your database?
评论 #32537944 未加载
throwgawag1将近 3 年前
&gt; Vault is a thin usability-layer on top of pgsodium.<p>Cloudflare and Duck Duck Go also add a bunch of names to routine things that already exist. It&#x27;s better to just not name it.
评论 #32533576 未加载