[venkat971]

We did cut our overall DB spend by more than 3x. Our $9K spend drops to $3k - indexes not kicking in, rapid growth of log tables and schema bloat were the culprits. Also, we removed the retool and appsmith licenses, another $2k savings.

We worked with 6 YC companies who are running on Aurora postgres and worked through the inefficiencies of workloads - too many indexes (in some cases almost every column is indexed), over indexing significantly increases I/O ops (writes), this hidden costs are enormous for fully managed services like Aurora. In all these cases, we could safely come up with a plan to cut down their DB spend by more than 40%.

[evanelias]

My point is that the number will entirely vary for each user, depending on how many poor DB-related infra decisions they've made. Some users may save 99%, others may save almost nothing, right? So why say 40% here? Where did this number come from?

Personally, I will instantly distrust a new product claiming an exact number of 40% savings -- not even "up to 40%" or "over 40%", which would still be misleading, but less weird than claiming exactly 40%. Especially in the second line of the homepage, without any supporting link or information.

> we removed the retool and appsmith licenses, another $2k savings.

These aren't DB-specific tools though? Why would this count towards the savings?

> 6 YC companies [...] in some cases almost every column is indexed

If your savings math is based on very early-stage startups who made horrendously bad indexing mistakes, honestly that would reduce my trust even further. That said, I'm definitely not the audience for your product.

[venkat971]

removed that metric.

Our goal was to tell a convincing story with case studies. However, you are right on many dimensions that this number means nothing for many optimized scenarios.