7 ms·

> cut database costs by 40% Where does this number come from? It feels completely arbitrary.

venkat971 2mo ago
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 2mo ago
  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 2mo ago
    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.

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 2mo ago
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 2mo ago
  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.