u/Frone0910

Over the years, I've worked with many different database engines, but every single time I had to diagnose the origin of slow queries, I ended up doing the same repetitive process over and over again:

• pull query stats and sort by total time rather than mean time
• run EXPLAIN ANALYZE on whatever comes out on top
• go find the table definitions for everything it touches
• check whether the column statistics are current
• work out whether the index you have in mind already exists under another name
• decide whether it is worth adding
• do it again for the next query

Eventually I grew tired of needing to manually assemble the picture myself every single time, so I built RDST, which is a desktop database analyzer tool that currently works with both Postgres and MYSQL.

RDST collapses the entire workflow shown above into one pass, so instead of starting at step one I get to the answer immediately when a slow query is detected.

RDST is AI powered, but it is not random slop analysis applied to random database statistics. The reasoning layer runs inside a fixed workflow in a semi-deterministic way, so pointing it at the same database twice gives you the same answer, which matters when you are deciding whether to add an index in production. 

Full disclosure - I work for Readyset (which is a caching layer for Postgres / Mysql), and this tool spawned from a recurring issue we had to solve for our customers - which queries should we actually cache? And these same queries are the ones that, even without a caching solution, could heavily benefit from performance diagnostics. 

Beyond diagnostics, RDST provides full rewrite suggestions and lets you benchmark slow queries and track their performance over time.

One other neat feature is that it also lets you ask questions about your database in plain english using NL --> SQL in a safe and secure manner with limited permissions.

It also integrates directly with Supabase, Neon, AWS RDS and DigitalOcean, making database discovery seamless.

The tool is completely free to use, and we provide free trial tokens for all of the AI powered features. The app is in beta and we plan to release it under an MIT license. It runs locally, stores locally and everything it does is read-only. Full privacy related details: https://readyset.io/docs/readyset-ai/rdst/desktop/privacy

I would greatly appreciate any feedback from this community, particularly:

• Does it surface the queries you'd investigate first?
• Are its explanations and recommendations useful, or merely confident-sounding database fan fiction?
• Is the fixed workflow the right call, or would you rather have a chat interface?
• What's missing?

Source:

• https://readyset.io/docs/readyset-ai/rdst/desktop
• https://github.com/readysettech/rdst

RDST (Readyset Diagnostic & SQL Toolkit) is a free desktop app that connects to your Postgres database, ranks the queries actually costing you time, and explains what to do about each one.

The reason I built it is that the tooling Postgres already gives you is genuinely good, but addressing database performance issues is still a highly repetitive process:  

• pull pg_stat_statements and sort by total time
• take the top query and run EXPLAIN ANALYZE on it
• go find the table definitions for whatever it touches
• check whether the statistics on those columns are current
• work out whether the index you have in mind already exists under another name
• decide whether it is worth adding
• do it again for the next query

RDST collapses all of that into one pass, so instead of starting at step one you start at the answer.

Full disclosure - I work for Readyset (which is a caching layer for postgres / mysql), and this tool spawned from a recurring question our caching customers kept asking - which queries should we actually cache? And these same queries are the ones that, even without a caching solution, could heavily benefit from all the relevant performance diagnostics.  

RDST not only helps you discover slow queries and give you the appropriate action plan to improve them, but also provides full re-write suggestions, the ability to benchmark slow queries and track their  performance over time, and even allows you to ask any question about your database/queries in plain english and get helpful responses.

The tool is completely free to use, and we provide free trial tokens for all of the AI powered features. The app is in beta and we plan to release it under an MIT license. It runs locally, stores locally, and everything it does is read-only.  Full privacy related details can be found here: https://readyset.io/docs/readyset-ai/rdst/desktop/privacy

We would love feedback from people who actually spend time wrestling with queries every single day! Particularly:

• Does it surface the queries you'd investigate first?
• Are its explanations and recommendations useful, or merely confident-sounding database fan fiction?
• Would you be comfortable connecting it to a real environment? If not, what would stop you?
• What's missing from the workflow?

Source:
https://readyset.io/docs/readyset-ai/rdst/desktop
https://github.com/readysettech/rdst

RDST (Readyset Diagnostic & SQL Toolkit) is a free desktop app that connects to your RDS or Aurora instances and tells you which queries are driving the load you are paying for.

The reason I built it is that Performance Insights is decent at telling you there is load, but going from "there is load" to "here is the query, here is why it is slow, and here is whether fixing it lets me drop an instance class" is still a repetitive manual process:

• open Performance Insights and find the top SQL by load
• copy the digest out and go run EXPLAIN ANALYZE against the instance yourself
• go find the table definitions and check whether the statistics are current
• work out whether the index you have in mind already exists
• check max_connections, to see if this is what’s actually biting during the spike
• go back to the pricing page and work out whether any of this justifies the instance class you are on
• do it again for the next instance

That last step is where the money is. Fix one query dominating CPU and you can often downsize, which on a large instance is hundreds/thousands per month.

Full disclosure - I work for Readyset (which is a caching layer for postgres / mysql), and this tool spawned from a recurring question our caching customers kept asking - which queries should we actually cache? And these same queries are the ones that, even without a caching solution, could heavily benefit from performance diagnostics.

It runs locally using credentials you already have, SSO or a named profile. Nothing gets installed on the instance and there is no cross-account role to create. It discovers your Aurora clusters and RDS instances, audits all of them, saves query snapshots so you can track regressions over time, and even allows you to ask plain english questions about any / all of your nodes and their queries. The health check feature gives you a sizing verdict with your current monthly cost and a suggested instance class, so making the decision to downsize/upsize should become very clear.

The reason this is worth doing: the instance in that report is an Aurora db.r6g.4xlarge running about $1,180 a month on demand. Three unindexed access paths account for roughly 66% of its total database time, and those are what the CPU peaks are made of. With those three indexes in place the audit puts the same workload on a db.r6g.xlarge at about $295. That is $885 a month, a little over $10,600 a year, for what amounts to an afternoon of work.

The tool is completely free to use, and we provide free trial tokens for all of the AI powered features. The app is in beta and we plan to release it under an MIT license. It runs locally, stores locally and everything it does is read-only. Full privacy related details: https://readyset.io/docs/readyset-ai/rdst/desktop/privacy

Would love feedback from people running Postgres or MySQL on RDS, particularly:

• Does the sizing verdict line up with what you'd have concluded from Performance Insights?
• Does it surface the queries you'd investigate first?
• Would you be comfortable pointing it at a production instance? If not, what would stop you?
• What's missing?

Source:

• https://readyset.io/docs/readyset-ai/rdst/desktop
• https://github.com/readysettech/rdst