Data confidentiality and sovereignty matter a lot to enterprises. You may want to redact access to the most sensitive data from both humans and agents, and it gets tricky to enforce such dynamic policies at the database level. DeepSQL solves this by managing all DB users (humans and agents) at the DeepSQL layer.
DB availability is out of scope for DeepSQL at the moment.
Oracle has something like this, and I worked on this project when I was there. Although I was fascinated by the use cases, the adoption was pretty low in the relational world.
The library has no stack, it's just a set of plugins you can either use directly (Ruby, Elixir, Go) or with a framework (Rails, Sinatra, Phoenix, Ash, etc). They write into a database you already run. Setup is adding the plugin and pointing it at your DB. Redis, Postgres, MongoDB, MySQL or SQLite. As for when you would feel some load from it, it really depends on your volume. I would say somewhere around 100k+ events a day is where the load starts being noticeable. Until then I wouldn't worry much about extra load.
If you want to self-host the App, it's pretty lightweight. While it's an Elixir app and you could compile and run it yourself, it comes packaged as a Docker image and it has a Kubernetes/Helm deployment documented. You can either point it to your own Postgres or it will launch its own so it can hold some of its own data like users, dashboards, monitors, etc. For 2-3 users one instance is plenty and you can easily run that on 1 CPU and 2GB RAM. Double that if you want redundancy.
optimizing the queries and schema monitoring just one aspect of Deepsql. It has built in BI server - security and policies enforcing module (on who can read what data) - All these can be wired in to the regular business and data lookup workflows.
Interesting topic, We built and use DeepSQL (https://deepsql.ai/) at Stayflexi(YC) to address some of these issues. It's an DBA agent to prevent schema bloat, over indexing and does continuous monitoring of query workloads and proposes fixes.
Schema blot issues are real when you are vibe coding. Our engineers vibe coded and bloated our schema from 230 tables to 600+ tables. Many of them have repetitions of columns across the tables and often too much indexing. If your Postgres is on Aurora, the bloat easily multiplies your bills.
Claude would not do the frequent schema drift changes, data relationships, block the query execution due to PII leak, cardinality calculations of key columns… 20 other parameters that effectively works like a well trained DBA. It’s all about harnessing the agent. And our harness can work with Claude or other coding agents to perform efficient DBA tasks.
Eg: our security harness blocks sensitive data from being queried, and this can be enforced at the user level. It takes effort to build and maintain such harnesses around claude at the org level.
DB availability is out of scope for DeepSQL at the moment.