HN user

venkat971

20 karma

Graduated from Carnegie Mellon University – School of Computer Science. Appeared on CMU today magazine for contributions to gift card fraud detection using ML. Later worked for Oracle in the core Database R&D team, and filed a couple of Patents in critical areas of database engine. Currently perceiving entrepreneurial dreams with Stayflexi. Deep Knowledge in Hospitality Technologies due to family business and travel interests. Built commercial booking systems in this space between 2010 – 2012. Co-Invented Flexible Slot based inventory model in 2019 along with co-founders of Stayflexi (patent pending).

I love coffee. I learned how to make a perfect cup from scratch, right from grinding beans to proper latte (sometimes latte art), and doing things this way.

Posts1
Comments13
View on HN

We have cross checked with industry standard tools like pganalyze. Most them analyze the workloads in isolation. There are no continuous evaluations and context carry forward across the runs.

DeepSQL does continuous evaluation of queries, we maintain performance life cycle of a query by customer.

A dashboard query for customer A might run for 2s, but for customer B it would take 50s. Here data clustering is the problem, skewness of distinct join keys … various factors. If query fix has to happen by looking at that query alone, one would make wrong decision (probably creating index). But a holistic decision would be partitioning here.

Sorry for the confusion. It's not opensource. For first few installs, we are offering free 3 months and free consulting service to setup the tool end to end at your org. Post that pricing will be based on AI tokens consumption with some standard monthly pricing (we are also exploring the pricing sweet spot)

I am happy to get connected over email venkat@deepsql.ai and share more details on pricing and deployment help.

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%.

Deepsql doesn't require any predefined rules + stats, nor you need a DBA to operate it. It's an autonomous agent, that learns your business context, schema, join relationships and creates a mental map of everything (just like a DBA who joined your team). This we call it deepsql brain init stage. Once the init is done, it will then look at all slow queries workload, comes up with comprehensive suggestions of indexes, MVs etc. Other DBA tools might look at one query at a time, if we try to optimize one query at a time, we might over index.

Also, deepsql is intelligent in understanding the deployment type. Postgres standalone deployment is very different than Aurora postgres. Cost factors are quite different. Other DBA tools might ignore these factors - Hence they need well trained DBA to use them.

Hints are great way to experiment, but should not live in live production queries. From my Oracle database days, we saw many customer workloads where old hints overrode the latest database optimizations. Believe in the optimizer's own decisions on plan execution trees, you will have peace of mind.

Associating drop table to scalabe delete is not a good framing. These are two different things, and very sensitive on production workloads if there are FK and MVs involved. Databases has 'Trucate table' for a reason. The post header should have used 'Truncate table' instead of 'Drop table' framing.