is row-level security on the roadmap of Greptime? this will enable fine-grained access control to data. or there is some kinda of proxy in front of GreptimeDB, which will allow us to incorporate our existing authorization infra. but that proxy will need to parse the query so it understands "who access to what"

Hello Kevin, our enterprise edition has table level access control. I wonder if it's possible to update your data model to fit that. We will consider row-level but due to its complexity we may not have a plan for that.

update your data model to fit that

could you advise on this? how do you envision the date model should be created?

For example, use table as minimal access control unit.

Maybe you can use views instead? If you create a view including a row filter, you can grant access to that view instead of the original table, and then the user will only see rows they are supposed to have access to.

use table as minimal access control unit.

i think this is anti-pattern, design the data model around such constraints. also creating data model isolation based on tables is big design decision. and you cant have granular access control, e.g. per-user access is impossible there are definitely needs for RLS and CLS, BigQuery and Snowflake have these

I understand it might be logistically difficult to create a bunch of views, but why would it have a performance overhead?