u/Master-Bass-1905

I assume everyone has been following the AI build out. Memory prices have risen sharply. GPUs, CPUs, memory shortage is hitting the consumer market. Apple announced price increases in hardware, which is quite rare for Apple.

We run on Hetzner and we reserved several Hetzner instances a few months back. The renewal prices have risen since we reserved them. We also run on AWS, but in much smaller numbers. We haven't seen any major changes in our AWS bills thus far.

But for folks who are operating much larger accounts, I'm trying to figure out is when these will hit AWS/GCP/Azure list prices. I personally think its a matter of "when", as opposed to "if". If you renewed a savings plan, RI or CUD recently, was the effective rate worse than the term it replaced. Has an account team given anyone a heads-up?

I work at Readyset which is a caching solution for databases, so we have an obvious interest where instance costs go. I'm trying to work out whether this is a real 2026 budget line or mostly bare metal hosts that have less pricing cushion than the hyperscalers.

Diagnose Slow Queries

A detailed diagnosis of your query

Health Check your Database or multiple database targets

Ask questions about your data

RDST (Readyset Diagnostic & SQL Toolkit) is a free desktop app that connects to your Postgres or MySQL database, ranks the most expensive queries, and explains what to do about each one.

The reason I built it is that reading a plan is a skill, and diagnosing one slow query is the same repetitive loop every time:

• pull pg_stat_statements or performance_schema and sort by total time
• run EXPLAIN ANALYZE on the worst offender
• 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

RDST collapses this process into one simple pass, so instead of starting at step one you click a few buttons and immediately have your answer.

There’s also a lot of data that is not immediately obvious when simply reading a slow query log. The five millisecond query called two hundred thousand times never shows up in a slow query log, and it is regularly the biggest consumer of database time on the box.  RDST looks at all the queries against your database, both historically and during your workloads, and gives combined analyses. 

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.

Beyond diagnostics, it gives you full rewrite suggestions, lets you benchmark a query and track its performance over time, and lets you ask questions about your database in plain english.

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.

Would love feedback from people who write SQL for a living, particularly:

• Does it surface the queries you'd investigate first?
• Are its explanations 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?

Source:

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

Easily connect to your Supabase instance

Diagnose slow queries

Get a comprehensive view of performance of your queries

Answer questions about your data with a semantic layer

The semantic layer

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

The reason I built it is that a lot of us are now shipping apps where most of the SQL was generated rather than written by hand. The answer to "why is my app slow" is almost always one specific query, and finding out which one and how to fix it means learning a good deal about Postgres.  But with how fast most of us move these days, we simply ship more and more code and nobody has a clear picture of what is actually hitting the database. 

Eventually, we all end end up having to answer the same questions:

• which queries are actually running against my database
• which of them are costing the most time
• is anything missing an index
• is anything worth caching
• how would I even tell
• what should i do to actually fix it

In many many cases, it's as easy as adding an index, but since LLMs are pretty good at adding them these days, this is not always the case. 

One scenario I had from a real project: the slowest query was a message lookup taking 2.7ms. Nothing wrong with it, the index was there and working. But it was being called 412,000 times, once per thread in a loop. No index would have fixed that. Fetching them in one query instead of forty did. RDST helped me realize this immediately.

One other great feature about RDST is that you can also just ask questions about your database in plain english. (Text2SQL - but it uses a semantic layer to single-shot queries with a high degree of accuracy.)

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. 

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

Would love feedback from people running real Supabase projects, particularly:

• Does the ranking match what you'd have guessed for your own project?
• Are the recommendations useful, or merely confident-sounding database fan fiction?
• Would you be comfortable connecting it to your production project? If not, what would stop you?
• What's missing?

Source:

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