joram87

We've not tried it with dblab engine. that would be an excellent combo (from my quick reading up on it). I'll add to my todo list to experiment with the pairing. It does look like some overlap in functionality, but mostly they are symbiotic.

re: streamlining the custom filters

we were considering allowing the user to inject stored procedures themselves, and then use those, but currently, we're opting to implemented them ourselves, so we have better control over the user experience. In the future, for very custom stored procedures, I think we may allow the custom path.

Oh yes! We made that possible through conditionals. We default to unconditional modification, but if you toggle the conditional option, you can provide a list of conditions which, if they all pass, trigger the modifications.

A future improvement to that: currently the conditions are all ANDed together, I'd like to support more types of boolean logic in the future. :)

- jsonb : kinda, we do static json replacement, with more complex rules on the horizon, where you could replace some regex-like path with a random func.

- uuids: no, but I should. adding to my list :)

- ip addresses: yes ip4 and ip6, but I want to go further and let you configure the replacement ips to be within specified cidr blocks

- arrays: again, not yet. Do you mind if I ask the use case? Arrays are commonly done as single rows and foreign keys/look ups, which we can do.

We've internally got the path for adding new filter types (dashboard configuration, api layer storage, and proxy rule implementation) pretty optimized. it takes us a day or two to add simple requested filters. longer for more complex ones.

Good questions.

We do not do connection pooling yet. currently it's a fresh connection per query (which adds a bit of latency). We're intending to add basic connection pooling shortly after launch. That said, if you put it in-front of pgbouncer, that would work well.

PostGIS and other extensions are on the radar, but currently are not supported. The proxy works with the extensions, but can't mask the data yet. If we get requests for specific extensions to be fully supported, we'll implement (same with extra masking data types). I look forward to the GIS data implementation, as I've met one of the postGIS contributors and have discussed several of those masking complexities.

I probably should mention the name of the tool I'm working on... oops, it's VeilStream :)

I've been working on something similar, starting a company around the idea! We realized that a lot of people had concerns or challenges with installing an extension on their production database and also that they wanted non-technical folks in compliance or HR to be able to configure and maintain the rules for individual employees. pgAnonymizer is a database extension but we structured ours to be a proxy server that hides/anonymizes/filters the data. We made a web dashboard that simplifies the configuration process, and allows you to configure what to do if columns get added to the database (default mask or hide new columns). We're about to go GA and if anyone has any feedback or wants to a free beta testing trial, I'd love to chat