Hacker News Reader

Comment by Thaxll | Hacker News Reader

Basically re-inventing MySQL / PG but worse. Next step, we don't have auth over the network, let's bake in RBAC into SQLite.

View on HN

From what else they're doing, it appears the point is to be able to use sqlite in serverless setups where MySQL/Postgres would be way too heavy to deploy on a per-customer or per-function basis.

Honestly I don't get the point of edge. Do people really care whether their website loads in 50ms vs 300ms?

Of course they care. It directly impacts on conversion rates. I'm still stunned with simple fact that most people think 100ms doesn't make a difference (for their business).

https://www.globaldots.com/resources/blog/how-website-speed-...

While it matters, +-100ms doesn't matter in the vast majority of web use cases. There is even such a thing as too fast. If a user doesn't notice the page updated due to speed, that is also a poor experience. 300ms would actually feel incredibly fast to most web users for most websites. Less than 1 second is a good guideline for page load though as shown by your link.

> There is even such a thing as too fast. If a user doesn't notice the page updated due to speed, that is also a poor experience.

If you're relying on your app's execution time to demonstrate this to a user, then you have poor UX. Instant changes and updates have been the norm in mobile apps forever and optimistic UI is becoming pretty standard on the web too, see Linear for example.

Can't they just cache let's say these 1000 marketing, sales and customer support pages into cdn then?

It applies to applications as well. My general beliefs on the topic: most improvements that people come up with don't move the needle for the business. Doing the same thing but a little better will sometimes have an impact, generally not. The exception to this is speed. Speed improvements deliver more consistently than anything else, and they keep delivering as you improve. Improving speed is the surest bet you can make.

One request being 50ms or 300ms probably doesn't really matter.

But 10,000 requests _per second_ being 50 or 300ms matters a lot

Sure it's on a bit of a hype wave at the moment, but yes, most internet users are mobile users that don't live in major metropolitan areas with robust internet infrastructure? I think at least having the option to serve some things at the edge can dramatically improve the browsing experience for those users (and many others!).

To take a different tack then the other two (at time of writing) replies to this: It's not just at the edge. Being able to add databases with wild abandon and just provide a key to an S3 compatible bucket to replicate it to, and not have to worry about any server setup or replication is appealing whether or not your setup is otherwise centralised. For some setups you do want to share data across user accounts, but for others, isolation along customer or individual user boundaries is not just fine but an advantage (no accidentally writing a query that returns too much data). And then, it's a plus if having a million databases and selectively spread them out over your servers is trivial.

I never thought people take restricting access from within database seriously. Like row security policies [1] in postgres. But now as I look at it, it must be taken seriously, just because those features exist.

Is anybody here using it in production with success?

[1] https://www.postgresql.org/docs/current/ddl-rowsecurity.html

Jep, my company uses Postgres RLS for a pretty big project for a client in the finance sector. It's the foundation of our multi-tenant setup there. We connect with a single DB user, but set a session variable at the start of each transaction. This session variable is then used by the RLS policies to filter the data.

Works like a charm, you basically get to build your app like it was dealing with a single tenant DB. Just make sure it's as hard as humanly possible for application developers to forget setting that tenant ID when they query... In our case we have a custom JPA base repository which takes care of that, and some PMD rules to catch rogue repos/queries.

If I understand correctly, it seems to be a cornerstone of Supabase’s Authorization features. https://supabase.com/docs/guides/auth/row-level-security

Yes I've used it a bunch in production it's great. It is highly valued in some PII-conscious fields for compliance reasons that I don't fully understand, but becoming competent with postgres RLS has been a huge benefit for my career.

The main practical downside is that it is more precise and rigorous than your app- or business-level auth logic is likely to be, and has no real escape hatches. If you're trying to drop it on an existing system you're going to spend a lot of time going back and forth with whoever to shake out edge case ambiguities in your rbac policy that weren't obvious or relevant before.

> But now as I look at it, it must be taken seriously, just because those features exist.

You can do pretty much everything within Postgres, from ETL to Authz to serving HTML templates and GIS apps. However, that doesn't mean you should, or that anyone is seriously using it in production on a large scale (after evaluating alternatives).

Yep, I use it for all my projects now. It's nice to know that there's basically no way for me to accidently mess up access control other than messing up the roles. Got a loose SQL command running? Or even maybe SQL injection? No problem at all.

Reply on news.ycombinator.com