| # TL;DR
We built VeilStream, a drop-in, read-only PostgreSQL proxy that strips, masks, or anonymizes sensitive values as queries stream through. In less than two minutes, you can put a proxy in front of a PostgreSQL database, whether hosted on your laptop, Neon, Supabase, or a cloud provider, and the user is able to start configuring filter rules. The use cases we're trying to solve are: - Production-like data in development environments - Improve incident handling by masking all data that is not relevant - Share a subset of your data - Protecting data being shipped into a data lake - Safe data to expose in internal tooling, metrics, or BI dashboards - Empower non-technical staff to vibe-code against sanitized data # How it fits in your stack - Role based policies: define masking rules in our web dashboard - The proxy picks up the configuration and starts applying rules automatically. ## You host it - it's a docker container, two environment variables: an api key, and the database URI connection ## We host it - Drop-in proxy: no code changes. Point your connection string at a new endpoint, that's it. # How it works (and how fast it is) Restructuring the query AST based on the config. AST rewrites depend on the text/structure of the query, not on how many rows the database eventually returns, so they are effectively O(1) with respect to result size. # Status & feedback wanted VeilStream is GA, but billing isn’t switched on yet so it's currently free at all tiers. We’d love your thoughts on: - throughput / latency in real workloads - Filter rules & DevX - weird edge-case queries (pg_dump, logical replication, etc.) I’ll be around all day to answer questions and dig into issues. # tagline Ship features with data you can trust and privacy you don't have to worry about. |
How do you handle connection pooling? Does this interfere with pgbouncer or similar tools?
Also, does this work with all PostgreSQL extensions (PostGIS, timescaledb, etc.)?