staticassertion

Of course. But why would that matter if Python can't get there to begin with? You're not going to hit NIC bottlenecks with Python, not without a ton of work and tradeoffs at least.

I have never suggested that there's something wrong with RLS nor that RLS and an application should be mutually exclusive, as I've pointed out multiple times now.

I think the conversation is suffering from trying to solve a problem that's underspecified, which is going to just lead to a lot of "what if" questions. I've explained my concern with relying on a single boundary, which should not be contentious and I have given multiple examples of potential additional controls.

I think a missing piece here is that you think that Rust won't download a file faster than Python but it absolutely can. This seems to just be a misconception people have about IO, like "download a file" is a thing that exists wholly outside of your process.

> Correct, but you have yet to mention any other solution where there is more than one boundary at the data access layer. Because there really isn't any.

I have. I gave the example of using RLS where users still provide the token to gain RLS privileges but an app brokers and constraints the connections. I have also given the example of encryption, to which your response is that encryption is hard, which I don't think is true but doesn't really change anything. Encryption is absolutely a data access layer control.

Why would I need to invalidate claims made with no support that seem obviously incorrect? Certainly I won't accept them.

> IO is executed by kernel, file system or network drivers. IO performance is not dependent at all on which language makes the syscalls.

I think your posts on this topic can not possibly be worth responding to if you're coming to the conversation with this level of not understanding things.

Your post is a combination of not understanding computers and then hand waving about fake numbers and user expectations. IO is not magic, it is not some distinct process that you have no control over from userland, it is exactly the sort of thing that Python does very poorly at, in fact.

I'll just reference techempower again, or you can look up those system calls you referenced like how epoll works and then look into what is involved for Python to use epoll effectively.

It sounds like DDOS is the tool they had available. I'm currently ambivalent on using user traffic to perform a DDOS.

I'm not sure where this "it's always one layer" thing is coming from, that's just not true. Nor do I see where I've said you should toss out RLS for a bespoke system - I see myself saying the opposite a few times.

> For you maybe, because you were taught it's scary or it just seems different?

Over a decade in computer security and software engineering. Nothing I'm saying is contentious. For some reason when I say "Having one boundary is bad" you say "There's only ever one boundary", which... is not true.

> Either your app has all the data access and you put your access control there, or you do the access control in the database. There really aren't other options here.

That's odd, I just clearly delineated an option in which this is not the case. The DB enforces RLS, users provide the RLS token, and an app gates access to the db.

> Your SSO system is a lot of pressure on one control too. Nobody seems to have problems with Azure or Okta or whatever SSO system you use having every key to the kingdom.

Some do, which is why they want MFA on the target side as well as on their SSO. But yes, SSO is very scary and there's a ton of security pressure on it. I don't think that's a very good argument for why we should think that every system should only require one layer of defense.

I'm going to sort of skip over any comparison to SSO since I'm not going to defend the position of "SSO is fine as a single barrier", especially as SSO is rarely implemented with one policy - there's device attestation, 2FA, etc.

> RLS has been around a long time and is very stable and doesn't change much.

RLS is great, I'm a fan.

> I don't remember the last CVE or outage we had with PG that broke stuff.

It doesn't really matter. The fact is that you're one CVE away from every employee having access to arbitrary data, including financial data. I feel a bit like a broken record saying this.

> I don't think you thought this through?

Well I'm not designing some arbitrary system. Don't expect a full spec.

> The problem with the app being constrained to RLS is you have User A and User B accessing your API, how do you get them access to the different data they need?

You can still have users provide the access to the service (ie: the password to get to the role), or otherwise map between User A and the role, etc. The service just brokers and constrains access.

> Sure maybe you can give it a role where it has limited DDL rights(i.e not create table access or whatever).

Yes, of course. Just as you would with users.

> I mean, not really, in practice?

I don't think it's contentious to say that if RLS is your only security boundary then your pressure is entirely on that one boundary. How could it be any other way? If you want to say "It's an extremely good boundary", okay. There have been relevant vulnerabilities though and I really don't know that we should say that we should expect 0 vulnerabilities in RLS in the future such that every employee having access to a db containing financial data is fine. The point of layering is to avoid having to put all pressure on this one thing.

I don't even understand how this is contentious or confusing. If you have one boundary, you have one boundary. I'm suggesting that I'm uncomfortable with systems having one boundary.

> What would be your method?

I don't know because I don't know your use case. At minimum, direct db access means that every postgres CVE something I'd have to consider deeply. Even just gating access behind an API where the API is the one that gets the role or accepts some sort of token etc would make me feel more comfortable.

> Now your app is the single boundary,

No, the app would still use RLS.

I'm not saying what you're doing is bad, but as described I'd be pretty uncomfortable with that deployment model.

Well, I think we basically agree? My suggestion is merely that a database holding financial data should have more than a single layer of security. Granting direct access to a database is a pretty scary thing. A simple example would be that any vulnerability in the database is directly accessible, even just by placing a broker in between users and the database I'd likely start to feel a lot better, and now I'd have a primitive for layering on additional security measures.

Encryption is an extremely powerful measure for this use case. If the data does not need to be indexed, you could literally take over the database process entirely and still not have access, it definitely doesn't rely on the permission model of the db because the keys would be brokered elsewhere.

Just to be clear, I am extremely pro-RLS.

I don't have strong feelings about that one way or the other, honestly.

I don't know their use case enough to understand what would or would not be an appropriate mitigation. For example, with regards to financial data, you could have client side encryption on values where those keys are brokered separately. I can't exactly design their system for them, but they're describing a system in which every employee has direct database access and the database holds financial information.

I don't think you have any idea what you're talking about, certainly you don't know what I'm talking about.

Right, RLS is great. What they are saying is this:

> every employee can access our main financial/back office SQL database

This means that there is no access gate other than RLS, which includes financial data. That is a lot of pressure on one control.

> At the end of the day with all data that is colocated you're trusting that some permission feature somewhere is preventing you from accessing data you're not supposed to.

Right but ideally more than one.

> But it's all just mostly logical separation.

Yes, ideally multiple layers of this. You don't all share one RDS instance and then get row level security.

Of course it's designed for security... that has nothing to do with my statement. No single boundary is "absolutely reliable", that's my entire point.

I'd be so uncomfortable with this. It sounds like you're placing the full burden of access on a single boundary. I mean, maybe there's more to it that you haven't spoken about here, but "everything rests on this one postgres feature" is an unacceptably unsafe state to me.

I think this is a weak framing. Lots of things are moral or immoral under specific circumstances. We should protect people from being murdered. I think murder is usually wrong. But we also likely agree that there are circumstances in which killing someone can be justified. If we can find context for taking a life, I'm quite sure we can find context for a DoS.

They're terrible for not wanting to be dox'd?

> I'm saying that the Rust might execute in 50ms and the Python in 150ms.

Okay, so the Rust code would be 3x as fast. Feels arbitrary, but sure.

> You are the one not making sense, we are talking about application performance, why are you not measuring that in milliseconds.

I explained why your post made no sense already...

> That is assuming Rust is 100x faster than Python btw, 49ms of I/O, 1ms of Rust, 100ms of Python.

That's not how anything works. Different languages will perform differently on IO work, different runtimes will degrade under IO differently, etc. That's why even basic echo HTTP servers perform radically differently in Python vs Rust.

This isn't how computers work and it's not even how math works.

This conversation has become nonsensical. The thing we can agree with is this - no, uv would not be as fast if it were written in Python.

That literally makes no sense. 100ms... out of what? Is it 1ms vs 100ms? 100000ms vs 100100ms?

Anyway, dubious claim since a Python interpreter will take 10s of milliseconds just to print out its version.

Do you have any evidence? I can point at techempower benchmarks showing IO bound tasks are still 10-100x faster in native languages vs Python/JS.

Vague. What's pretty close? I mean, even for IO bound tasks you can pretty quickly validate that the performance between languages is not close at all - 10 to 100x difference.

My experience has been that performance bugs show up in lots of places and I'm very lucky when it's just a bug. The far more painful performance issues are language and runtime limitations.

But, of course, profiling is always step one.

> our constant claims that quality and security matter

I'm 13 years into this industry, this is the first I'm hearing of this.

It doesn't come off as unintuitive by my read. They had a bug that led to a massive performance regression. Rewriting the code didn't have that bug so it led to a performance improvement.

They found that they had fewer bugs in Python so they continued with it.