11–20 of 40 posts
So... this thing gives full read/write/ddl access to production data ...via Slack? That is a security nightmare. Hard pass.
It's for SQL query optimization, so you probably wouldn't run it on prod.
It may not look like is a hard challenge: but the reality is that most troubleshoot them in production, which means that:
a) you need access to production, when you shouldn't; b) you run queries in production, potentially affecting -sometimes noticeably- production workloads.
Joe provisions a database clone using ZFS snapshot (I believe LVM support was added recently) and gives you a full copy of the database for you, with real data. You can test the queries, explain plans, create indexes to test if you need. And when you are done, it goes away. With a Slack interface, so you don't need to bother with connection, provisioning, credentials and decommissioning.
Give it a try, it is a very good tool!
So... this thing gives full read/write/ddl access to production data ...via Slack? That is a security nightmare. Hard pass.
So... this thing gives full read/write/ddl access to production data ...via Slack? That is a security nightmare. Hard pass.
Hi, Postgres.ai founder here. Production is not affected, the chatbot works with thin clones provided by Database Lab https://gitlab.com/postgres-ai/database-lab/ . In general, you are right. If, in your case, using the "raw" databases is unacceptable, it is better to anonymize data first (of course, the physical layout will change in this case). However, Joe doesn't reveal the data. Engineers see only EXPLAIN (ANALY…
Theoretically you could reveal certain type information by writing specialized attack queries for checking certain information, for example:
WHERE username='joe' AND is_admin IS true
So... this thing gives full read/write/ddl access to production data ...via Slack? That is a security nightmare. Hard pass.
Hi, Postgres.ai founder here. Production is not affected, the chatbot works with thin clones provided by Database Lab https://gitlab.com/postgres-ai/database-lab/ . In general, you are right. If, in your case, using the "raw" databases is unacceptable, it is better to anonymize data first (of course, the physical layout will change in this case). However, Joe doesn't reveal the data. Engineers see only EXPLAIN (ANALY…
People's existing tendency to expose critical data via Slack shouldn't be reinforced, and coming from a product that handles sensitive data by design, it's disheartening to see this line of thinking here. I would hope your product makes it harder for me to compromise data, not easier.
> At the same time, Joe does boost the development speed because it becomes easier to troubleshoot SQL performance and discuss it with colleagues, collecting reliable facts.
Great! Now make that troubleshooting accessible via an authenticated URL and I'm in. Especially because I may want to revisit a particular explain sometime down the line, and simple anchor-tag based list of bookmarkable past queries is easier to navigate than having to use Slack searches.
If I were to use this tool, I would envision the ideal version of it being self-hosted and able to function independent from any other service. If there was then an option to add a Slack hook that notified people, that would be good. But it shouldn't be central to the product, and the information should strictly travel from the self-hosted service to slack via hooks, exposing only the URLs/titles of result pages. No need to expose the queries or DB structure.
I think the current Slack implementation is a cool proof of concept, but this isn't a product I would seriously consider until it is able to perform its tasks in isolation.
As for "improv[ing] the level of collaboration of developers and DBAs", great that you're thinking about that, but that's my problem to solve, not Joe's. And depending on my team's existing solutions, this may even rule out Joe simply due to our current tool set.
Earlier quoted context omitted.
It's for SQL query optimization, so you probably wouldn't run it on prod.
Well you sure need a representative dataset to optimize your queries. Often, that means a replica of the production server, with real PII data in there.
So... this thing gives full read/write/ddl access to production data ...via Slack? That is a security nightmare. Hard pass.
A slack interface is probably a more auditable environment out of the box. Strong auditability is arguably more important than hard security guarantees.
I've used Joe quite a bit, and all I can say is that it's a great idea that solves a noticeable problem: troubleshoot your queries. It may not look like is a hard challenge: but the reality is that most troubleshoot them in production, which means that: a) you need access to production, when you shouldn't; b) you run queries in production, potentially affecting -sometimes noticeably- production workloads. Joe provisi…