Holistic.dev is a static program analyzer and knowledge mining tool. We mine insights about the data relations structure in your whole project based on the database schema and DML queries. This knowledge allows us to automatically control the consistency of relations and provide tools for automatically discovering issues.
Our product is not an operation metrics analyzer:
- We do not analyze database config (like planner settings, buffer size, etc.).
- We do not analyze execution plans.
- We do not manage replication or connection pools. There are a lot of tools for these purposes, and most of them are really good. After all, we don't even need a direct connection to any part of your infrastructure.
There is a lot of knowledge hidden away inside a combination of database structure and DML queries which is undetectable to human eyes. And we mine it. What kind of knowledge is it? DML statement results:
- field types
- field nullability
- line count category represents one of 5 values: none, one, one or none, many, many or none
Based on that knowledge and a dependency graph, we can mine more complex knowledge like:
- expressions that can use indexes (Of course we can't say exactly what indexes will be used in each execution, because it depends on a lot of runtime details like cache, table statistics, CPU load and more. But we can specify the necessary condition, not the sufficient one. If there is a situation where it is impossible to use the index, we will indicate it.)expressions that can use indexes (Of course we can't say exactly what indexes will be used in each execution, because it depends on a lot of runtime details like cache, table statistics, CPU load and more. But we can specify the necessary condition, not the sufficient one. If there is a situation where it is impossible to use the index, we will indicate it.)
- used relations and fields
- inefficient JOINs clauses
- sublinks that are supposed to be changed to JOIN
- list of possible runtime exceptions
- excess expressions, aggregate function calls or ORDER clauses
- always true or always false clauses
- unsafe architecture patterns
- and much more
And, conversely, we can find expressions that can't ever use indexes, mentioned but unused tables, unused data-modifying common table expressions, and more.
The system can take all the complexity of the database structure and queries, and do a holistic analysis of SQL statements’ execution results without actually executing them. And, the system is capable of processing many databases at the same time.
Based on all that knowledge, our solutions can show developers and DBAs what they should change to make queries faster, remove excess query complexity, and preserve the consistency of the whole project if changes have been made to some parts of it.
We currently support PostgreSQL with most modern syntax changes (v13). You can analyze all PostgreSQL syntax related databases.
We support all extensions from the list. That means we know about all functions and types provided by these extensions. TimescaleDB is also supported.
Zero. It's free. Our purpose right now is to get your feedback and make our service more user-friendly, more effective, and more powerful.
No, never! We don't even need a direct connection to your database. We analyze only the SQL source code of queries that you provide yourself.
Unfortunately, no. Our holistic approach is based on knowledge of database structure. We link knowledge about the database schema and about the query to identify all deep connections and suggest the most effective ways to optimize your SQL code. Sometimes the better way is to make changes to the schema instead of the query.
Sure! You can automatically and continuously upload all queries from pg_stat_statements to the holistic.dev API or integrate your CI tools for checking queries before they ship to production. It works with on-premise and managed databases.
The static SQL query analyzer can significantly reduce time spent on searching for performance problems and problematic architectural patterns. Get detailed recommendations for optimizing queries from the production base. Upload the database schema (DDL), start the automatic upload of Slow Query Logs, and receive notifications about necessary optimizations right in Slack! Over 100 recommendations for improving performance, and over 600 recommendations for changing the architecture.
As projects grow exponentially in complexity, keeping track of all the details gets that much harder for code engineers. Being forced to switch between projects gets time-consuming every day, and routine leaves no place for creative tasks, all of which leads to growing job dissatisfaction and lower performance.
One of the biggest challenges in backend application development is working with databases. It's necessary to keep in mind all the intricacies of working with the database, maintain the relevance of types on the application side, and resolve many other issues.
We create solutions for automating routine tasks that engineers face when creating applications that interact with a database. Up to 50% of engineers' working hours are spent on tasks that can be automated.
- SQL as part of application — seamless integration of query types and application types
- Code generation — automated generation of application code based on queries for your language and framework (JS/TypeScript/Flow/Golang/PHP/Python/Java/C/C++/C#...)
- Boost productivity by cutting down on routine tasks
- No need to keep in mind all the intricacies of the database structure — that's what we call a triumph over cognitive complexity
- Early error detection
- Save testing time during development
- Help with debugging
- Microservice-friendly — automatically generated data contracts in JSON, BSON, MessagePack, Protocol Buffer, Thrift, Avro, Cap'n Proto, and FlatBuffers format
- Well-suited for forks (such as Citus, Greenplum, Timescale)
Benefits for engineers of all levels:
- Junior - Training (working with a mentor)
- Middle - Evolution (adoption of best practices)
- Senior - Support (working with a team member and assistant all in one)
Tools by role
- BACKEND DEVELOPERS - Automated code generation - Look out for performance and architecture issues, prevent runtime errors
- QA Automated test generation - Increase test coverage
- DEVOPS Automated migrations when merging branches
A team leader's work becomes significantly more straightforward when the developers are working on productive tasks instead of fighting a losing battle. Our solutions help you speed up the code review process, obtain previously unavailable code metrics, improve employee satisfaction, and increase productivity. Up to 50% of engineers' working hours are spent on tasks that can be automated.
- The multiplier effect of using solutions for teamwork
- Prevent errors before compiling and testing
- Automated data mining provides more profound and more accurate insights than human analysis
- Code quality metrics — you can't improve what you can't measure
- Reduction of developer onboarding time and context switching time, because you don't have to keep in mind all the details of the database structure
- Well-suited for cloud projects
- Positive feedback about the processes within the team reduces the cost of the engineer hiring process
Build a better engineering culture
- Increase team Velocity
- Reduce cycle time
- Boost expertise of developers of all grades
- DocOps practices
- Accelerate team productivity
Improve code quality and QA
- Detect and rectify errors in the early stages of development — production bugs are too expensive to fix
- Unify code style and architectural patterns
- Increase code maintainability
- Reduce test running time
- Increase tests coverage
- Minimize code review time
The more new functionality can be delivered during a sprint, and the more hypotheses can be tested in parallel, the more efficient the product manager's work is. But this depends on how efficiently the engineering team works. Our solutions speed up the development process, make bug fixing more effective, and allow you to implement more features during the sprint.
Minimize time to market
- Develop new features faster
- Ship product faster
The average budget for an engineer, including taxes, office, and equipment expenses, is about $100,000 per year. It can even be twice as much, depending on the region. However, the revenue coming from such an employee is usually two or three times more than labor costs.
Increasing an engineer's efficiency by at least 10% reduces costs by $10,000 per year, or boosts annual revenue by $20,000-30,000 per engineer. These numbers increase when evaluating the work of teams as a whole. Coding and fixing bugs directly or indirectly related to the database can take up to 50% of engineers' working time.
Moreover, expenses are reduced thanks to early detection and fixing of errors and performance issues. Studies suggest that the cost of eliminating errors in the development phase is up to 500 times lower than at the production stage.
The cost of static analysis solutions usually does not exceed the salary of one junior engineer for every ten employees. Based on target performance improvement, the ROI of a static analyzer can be up to 30x, and speed up Time to Market by an average of a month throughout the course of a year.
Save on infrastructure costs
- Reduce infrastructure testing costs
- Boost database performance — you can serve more customers using existing equipment
- Reduce the risk of data leakage
- Reduce the risk of data loss
- We don’t need an actual database connection — we parse only the source code of DDL/DML queries
- We don’t need your application source code
- We never publish your source code in any publicly available sources
- We never publish reports on your project issues in any publicly available sources
Yes, that’s entirely possible. Well done!
At present, 5% of the rules described above are implemented, and it's quite probable that we will be able to detect something later. Stay tuned, and we will automatically send you a report if the new rules find problems in your requests.
Also, at the moment, we do not diagnose errors that may occur at runtime. If a non-existent table is used in a query, then the system will not be able to deduce the types, but it will not show a warning about the missing table. Runtime error reports will be added soon.