Foglight for Databases Reviews

On a day-to-day basis, my main use case for Foglight for Databases is a centralized database for performance monitoring and troubleshooting. I use it to monitor database health, review CPU and memory usage, identify slow-running queries, and performance bottlenecks. I also investigate issues when an application becomes slow. I use the dashboards, alerts, and historical performance data to identify unusual behavior early.

One example was when Foglight for Databases gave me an alert indicating unusually high CPU usage on one of our databases. I used the product performance information to investigate and found that a query was taking much longer than usual and consuming a lot of significant resources. We were able to identify the query and work with the DBA team to address it before it caused noticeable application slowdown. This helped us avoid waiting for users to report the problem and reduced troubleshooting time.

Foglight for Databases has a positive impact mainly by reducing the time my team spends on routine monitoring and troubleshooting. With the centralized dashboards, we have dashboards and alerts ready. In the morning, I can simply look at them, and if there is anything concerning, I can investigate it. This has reduced the amount of manual effort needed to gather performance information across different databases, allowing the team to spend more time addressing issues rather than collecting data.

We have seen a noticeable reduction in the time spent on monitoring and troubleshooting, estimating that twenty to forty percent of troubleshooting activities have been reduced. Although we have not formally measured this, we have been able to manage more databases without increasing our day-to-day monitoring workload. The main benefit is the faster identification of issues and less effort rather than a specific reduction in the number of incidents.

The features that are most valuable to me in Foglight for Databases are real-time monitoring, performance dashboards, and alerts. I particularly value the ability to identify slow queries and investigate what is contributing to a performance issue. The historical performance data is also useful because it helps me compare the current behavior with previous periods and understand when an issue has started. Having multiple databases visible from a central data dashboard makes day-to-day monitoring more efficient.

Foglight for Databases offers centralized monitoring and performance analysis with visibility across the database environment, which supports more consistent oversight and faster issue detection. I appreciate that the tool has AI capability, and I feel confident about the governance and security features. I trust Foglight for these aspects.

The performance and AI capability, accuracy, and reliability of output from Foglight for Databases is good, giving accurate results that I can rely on. Although I still validate the information myself, it gives me trustworthy data.

Foglight for Databases allows me to monitor multiple database platforms from a centralized view. In our environment, I use it across different database platforms, making it easier to monitor overall health and performance without having to manage each platform separately. I monitor Microsoft SQL Server, Oracle Server, PostgreSQL, MySQL, Azure SQL, MongoDB, IBM DB2, SAP HANA, and Snowflake.

I assess Foglight for Databases as very effective for quickly diagnosing emerging database issues. Its real-time monitoring and alerts help me identify unusual behavior early, particularly when a performance issue arises. Using Foglight for Databases, I can understand when the issue starts and look at the timeline for any recent changes, which helps me identify the root cause without impacting performance. It is a vital tool for developers who may not have the capability to run tests independently, as it enables them to assess what is happening after changes are made.

I use Foglight for Databases' monitoring and alerting capability to identify long-running or resource-intensive queries. This capability helps us catch potential performance problems before they have a broader impact on other applications. When a query starts taking significantly longer than usual and consumes excessive CPU, the alert prompts me to investigate the query and its resource usage, allowing the DBA team to address the issue proactively instead of waiting for users to report slow application performance.

I use the solution's user interface to access database performance information. I find the data fairly easy to locate once I am familiar with the interface, as the centralized dashboards provide access to database health, resource utilization, query performance, alerts, and historical trends. When investigating a slow database, I can start from the dashboard and drill into the relevant performance information rather than collecting data manually from multiple sources. The main challenge is that some troubleshooting views can take time to learn and navigate, so a more intuitive interface would improve the experience.

I find Foglight for Databases useful for getting a centralized view of my database environment, especially when database platforms and cloud resources are involved. The ability to bring monitoring information into one place makes it easier to compare performance and understand any unusual behavior. I can determine whether an issue is isolated to one database or is a broader problem with more than one database. When an application becomes slow, I can check database health and resource allocation, monitor query performance, and see alerts and historical trends, which gives me more context while troubleshooting. This reduces the need to check each platform separately, as I can directly analyze what is performing well and what is not.

I would improve the user interface of Foglight for Databases, as I feel it is somewhat complex, especially when using the specific troubleshooting view, particularly for new users. I would also appreciate more flexibility when customizing the dashboards and alerts, so better prioritization based on impact would be beneficial. Reporting could also be more straightforward with more ready-made reports and easier customization. Clearer recommendations during troubleshooting would help users move from identifying a problem to understanding the likely root cause.

There is still room for improvement in the user interface, reporting, and alert customization, but overall Foglight for Databases has been valuable.

I have been using Foglight for Databases for about one year.

Foglight for Databases is stable.

Regarding scalability, as our databases grow, we can add additional databases to the monitoring setup without changing the overall architecture. Once a database is configured, mapping it to the centralized monitoring setup is fairly straightforward.

The customer support for Foglight for Databases has been very good, supportive, and responsive. We do not encounter issues when they involve complicated requirements. However, more complicated issues can sometimes take longer to resolve when multiple teams are involved. Overall, I am satisfied with the support, but faster resolution times and more practical troubleshooting guidance would improve the experience.

I would rate the customer support six out of ten because the support team has been generally helpful with technical issues, although for complex cases, they took considerable time to resolve.

Before using Foglight for Databases, I mainly relied on native monitoring tools provided with our databases, along with some manual reporting. Those tools were adequate for basic monitoring, but managing different database platforms separately became more difficult as our environment grew. I moved to Foglight for Databases because I wanted centralized monitoring, historical performance data, and reporting in one place. I still use native tools for certain tasks, but Foglight for Databases has made overall database monitoring more convenient.

I have seen a return on investment through time savings and better use of my team's resources rather than reducing headcount. I estimate that monitoring and troubleshooting activities take around twenty to forty percent less time. Although this has not been formally measured, we can manage more databases without increasing our day-to-day monitoring workload. Another benefit is that historical performance data makes monthly performance reviews and reporting much less manual.

In terms of pricing, the setup cost and licensing require planning from both perspectives. The initial configuration takes effort because I have to decide which database to monitor and configure according to my requirements. The licensing cost can become significant as the number of monitored databases grows. However, once the initial setup is completed, ongoing management is straightforward. I would appreciate more flexible pricing options when expanding the monitored environment.

I evaluated SolarWinds Database Performance Analyzer and Redgate SQL Monitor before choosing Foglight for Databases. I was looking for a solution that could provide centralized monitoring across my database environment, along with historical performance analysis and reporting. I considered each product's capability, licensing, cost, and setup requirements before selecting Foglight for Databases.

Foglight for Databases provides strong centralized monitoring across all my needs, and I would rate the tool nine out of ten.

When someone is looking for a tool like Foglight for Databases, I would recommend first identifying the database and performance metrics that are most important to your environment rather than trying to monitor everything at once. Start with critical databases, configure them, then create dashboards and alerts around your requirements, and gradually expand. It is worth spending time learning the reporting and historical analysis features.

My main use case for Foglight for Databases is to monitor database performance and identify issues before they affect our applications. I mainly use it to keep track of database health, check slow running queries, monitor CPU and memory usage, and identify any bottlenecks. One thing I find useful is that I can monitor multiple databases from a single dashboard instead of checking each one separately. Whenever we notice an application running slowly, I can use Foglight for Databases to check what's happening at the database level and find out whether the issue is related to queries, resource usage, or database connection. It also helps us catch performance issues early through alerts, so we don't always have to wait for users to report the problem.

One specific time when Foglight for Databases helped us catch or solve a problem before it affected users was when it alerted us to unusual high CPU usage on one of our databases. When we checked, we found that a query was taking much longer than usual and consuming a lot of resources. We were able to identify the query and work with our DBA team to fix the issue before it started affecting application performance. What I appreciated was that we didn't have to wait for someone to complain about the slow application. We could see the problem early and take action. It saved us quite a bit of troubleshooting time.

The features I value most about Foglight for Databases are its real-time monitoring, alerts, and performance dashboards. The dashboard is useful because I can quickly check how our databases are performing without going through multiple screens. Another feature I really value is the ability to identify slow queries and see what's causing the performance issue. The alerts are helpful, especially when something goes wrong outside regular working hours. I also find the historical performance data useful because I can compare current performance with previous days and figure out when an issue actually started. Overall, these features make my daily monitoring and troubleshooting work much easier.

Foglight for Databases has helped us reduce the time we spend monitoring and troubleshooting database issues. Earlier, we had to spend more time checking different databases to figure out what was causing a problem. Now, we can identify the issues much faster and fix them before they affect our applications. The alerts have also helped us avoid unnecessary downtime, and our team does not have to constantly check everything manually. It has made our daily work easier, saved considerable time, and helped us keep our database running more smoothly.

I think Foglight for Databases could improve its user interface. It can be complex to navigate sometimes, especially when you are trying to troubleshoot a specific issue. It can be overwhelming for someone using it for the first time. I would also appreciate more flexibility in customizing the dashboard and alerts based on our requirements. Sometimes we receive too many alerts, and it takes time to identify which one actually needs attention. Apart from these things, the product works well for our daily database monitoring.

The reporting could be improved. Sometimes when we need to share a performance report with our team or management, it takes extra effort to get the information in the format we want. Having more ready-made reports and easier customization would be helpful. Integration with other monitoring tools could also be simpler. When we are troubleshooting an issue, it would be beneficial to have clearer recommendations on what might be causing the problem instead of having to go through multiple metrics ourselves. These improvements would make our day-to-day work easier.

I have been using Foglight for Databases for one year.

Foglight for Databases has been quite stable for us. We haven't faced any major issues with the tool itself, and it handles our daily monitoring well, even with multiple databases connected. Occasionally, we have noticed some delays in data collection or had to restart an agent after configuration changes. These issues haven't caused any serious problems. Once the initial setup was completed, we haven't had to spend much time maintaining it overall.

Foglight for Databases has been quite scalable for our requirements. As our database environment grows, we are able to bring additional databases into monitoring without having to change our entire setup. Since we are using Azure and managing different database platforms, this flexibility is useful. Adding new databases does require some configuration, and we need to consider licensing and monitoring server capacity as the environment grows. Once everything is configured, managing the additional databases is fairly straightforward. We haven't faced any major scalability issues so far, although I feel the process of adding multiple databases at once could be simpler.

Our experience with Foglight for Databases customer support has been generally good. Whenever we raise a technical issue, the support team has been helpful and willing to investigate it. For more complicated issues, getting a resolution can take longer, especially when multiple teams need to be involved. I feel the documentation could also be improved, as sometimes it's easier to contact the support team than to find the exact solution ourselves. Overall, I'm satisfied with the support, but faster resolution times and more practical troubleshooting guides would make the experience better.

Before Foglight for Databases, we were mainly using the native monitoring tools available with our databases, along with some manual reporting. They worked fine for basic monitoring, but managing different database platforms separately was becoming difficult as our environment grew. We moved to Foglight for Databases because we wanted a more centralized solution with better visibility into our entire database environment. The biggest difference for us has been having historical performance data, automated reporting, and monitoring information in one place. We still use native tools occasionally for specific tasks, but Foglight for Databases has made our overall database management much more convenient.

I feel Foglight for Databases is a bit expensive, especially when you're monitoring multiple databases, as the licensing cost can add up. The initial setup also took some planning because we had to decide which databases to monitor and configure everything according to our requirements. Since we are using Azure, we also had to consider the infrastructure costs. Once everything was set up, managing it became much easier. I think the pricing could be more flexible, especially when adding a new database or expanding our environment.

We have definitely seen some return on investment, mainly in terms of time saved and better use of our team's resources. We haven't reduced our team size, but we can now manage more databases without increasing our daily monitoring workload. One example is our monthly performance review. Earlier, collecting information from different databases and preparing the reports took considerable manual effort. Now, we can pull historical data and performance trends directly from Foglight for Databases, which makes the process much easier. I would estimate around twenty to forty percent of time savings in our monitoring and troubleshooting activities, although we haven't formally measured it. I don't have an exact figure for the money saved, but reducing manual work and avoiding unnecessary troubleshooting has definitely helped us use our resources more efficiently.

Before choosing Foglight for Databases, we also looked at SolarWinds Database Performance Analyzer and Redgate SQL Monitor. We wanted to understand which tool would work better for our database environment, especially since we manage different database platforms. SolarWinds had some useful performance monitoring features, while Redgate was more focused on SQL Server. Foglight for Databases offered centralized monitoring and historical reporting capabilities we were looking for. We also considered the licensing cost and the effort required for the setup before making our decision.

I would suggest understanding your database monitoring requirements before going with Foglight for Databases because the licensing and initial setup need some planning. Don't try to configure everything at once. Start with your critical databases, get familiar with the dashboards and alerts, and then gradually add the rest. Also, spend some time understanding the reporting features because there is quite a lot you can do with them. If you're managing multiple database platforms, having everything in one place is really convenient. Just make sure your team gets proper training during the initial setup so you can get the most out of the tool. I would rate this product a nine out of ten.

I use Foglight for Databases to check the historical performance of any SQL and Oracle database, including memory and CPU utilization, current sessions and older sessions, and to tune queries and receive recommendations on whether index creation is required by analyzing the execution plan. I also monitor TempDB, other databases' growth rates, log rates, and current performance issues.

Recently, we faced a G drive incident, meaning the data drive where our data.mdf file resides. By analyzing the database file growth through a graph from Foglight for Databases, I discovered that the data was growing significantly at 100 GB per day. Based on this current growth, we predicted the needed space and worked with the Wintel team to prevent an outage.

For day-to-day operations, I use Foglight for Databases to obtain the query execution time and historical data about the query, such as how much CPU the query used and its performance, as well as to get the execution plan of a query.

Foglight for Databases positively impacts our organization by enabling us to identify slow-running queries and check the historical performance of any SQL Server instance, which is why we have relied on this tool for nine years without facing significant issues.

Using Foglight for Databases saves us time by providing a clean view with good graphical user interface options, as running dynamic management view queries manually would take considerably longer.

The best feature that Foglight for Databases offers is the SQL PI.

With SQL PI, I can perform a deep dive into any session, getting comprehensive information about that session, such as the username, system from which it is running, and the CPU usage, helping my work significantly.

Foglight for Databases provides 100% accuracy, and I do not see instances of inaccurate data.

Foglight for Databases provides real-time activity data, which I check regularly on a daily basis.

This real-time activity data helps my team monitor if a client reports that a query is running slow. We use the activity monitor to identify the head blocker and determine if it can be killed or tuned.

Foglight for Databases' capability to quickly diagnose and resolve emerging issues is essential because I need to monitor database growth, performance, current queries, and user history, allowing me to capture all relevant data.

I use Foglight for Databases to display intensive database queries, which helps us determine potential issues, as I can access the SQL PI for resource-intensive queries and receive recommendations for query tuning or index creation.

When an issue arises, such as an unavailable database instance, we have configured alerts in Foglight for Databases, which notify us through our ServiceNow queue, allowing us to respond quickly with accurate data.

Foglight for Databases allows me to monitor multiple database platforms, including MS SQL, Oracle, and HANA, enhancing our operational capabilities.

Foglight for Databases can be improved as sometimes, when checking the current query in SQL PI, it does not show the complete large query as the text gets truncated.

Otherwise, I find that Foglight for Databases is a great tool, and these needed improvements aside, it is very nice overall.

It is performing well, and we are happy with the monitoring capabilities of Foglight for Databases.

I have been using Foglight for Databases since 2018, as I started using it at the beginning of my time with HCL, while prior to that, I was using Spotlight.

Foglight for Databases is stable.

Foglight for Databases' scalability can guide and predict future storage and CPU memory requirements.

Customer support is awesome, and we have always received timely support.

On a scale of 1 to 10, I would rate customer support 10 out of 10 as we consistently receive support on time.

I previously used SolarWinds DPA and AppDynamics but switched to Foglight for Databases because it provides a much cleaner view, historical data, multiple options, and accuracy.

Foglight for Databases is deployed on-premises, but it monitors both our on-premises servers as well as Azure IaaS servers.

There is a return on investment from Foglight for Databases, as it saves time with a clean UI allowing me to access all details in a single click.

I rate Foglight for Databases a perfect 10 out of 10 because, after using SolarWinds, AppDynamics, and other monitoring tools, I find Foglight for Databases handles tasks far better than the alternatives.

I chose 10 out of 10 as Foglight for Databases offers greater capability, a cleaner view, more user interface options, and being lightweight means it does not consume much CPU or memory.

I advise others considering Foglight for Databases to choose it for its extensive monitoring capabilities across multiple database platforms, its clean user interface, and the accuracy it offers. I would give Foglight for Databases a rating of 10 out of 10.

My main use case for Foglight for Databases is for troubleshooting. We have solved many troubleshooting and performance issues with Foglight in our Oracle production databases. When an application becomes slow, I use it to examine the database workload, resource utilizations, wait events, expensive SQL statements, and blocking sessions until the affected period. This helps narrow down whether the slowdown or performance impact is related to SQL executions, lockings, CPU pressures, or IOs. After addressing the main cause of the problem, I compare the performance before and after the change to confirm the improvement. Historical monitoring is particularly useful for investigating incidents reported after they have occurred.

I faced a problem at the end of last month, specifically from September month end, when a huge batch load was running. During this time, I faced production issues and used Foglight for Databases for the investigation and identification of the problems.

I am also planning to use Foglight for Databases for AI implementations using either an integration with APEX or an integration with any of the monitoring tools because that is where we are planning to pitch in next quarter. I use this project for routine database health check monitors, monitoring, and investigating slowdowns, which are very common in our case, and also for performance alerts. I review the resource utilizations, wait events, expensive SQL statements, and all. This is a very common investigation approach that we follow, and I am planning to integrate AI with Foglight for Databases so that all these things can be taken care of automatically rather than us pitching into the same issues again.

Foglight for Databases has positively impacted my organization by providing improved monitoring and quicker troubleshooting, especially during mission-critical issues. Foglight for Databases has helped us significantly in investigating and troubleshooting problems quickly, rather than following the traditional manual approach.

The best features that Foglight for Databases offers, which I value most, are the SQL workload analysis and historical performance monitoring. They help me identify the resource-intensive SQL and investigate what was happening during a reported slowdown, while wait events analysis and blocking sessions visibility also help narrow down the cause very quickly. Having this information in one console makes troubleshooting much easier and supports proactive database monitoring. Considering this as my base, I am planning to integrate this with AI either on the cloud or on-premises.

Foglight for Databases does provide real-time activity data, and we have faced scenarios in our environment where this has been beneficial. When Foglight for Databases is deployed in our Azure public cloud environments, we use it to centrally monitor database health, performance, and availability, including our Azure SQL Database for Oracle instances.

I do use Foglight for Databases's UI to proactively alert me of long-running queries, and this affects my database operations positively. It helps identify what action can be taken on those respective queries, especially at month-end when we run into performance issues. Our database runs on AWS RDS, and Foglight for Databases significantly aids in proactive monitoring during this period.

Foglight for Databases enables drill-down from database alerts into relevant performance details such as resource usage, wait events, active sessions, and SQL activity. This helps narrow down the cause and makes troubleshooting more focused. For example, when investigating a slow Oracle application response time, I check if the slowdown coincides with CPU pressure, blocking sessions, or resource-intensive SQL statements. I examine the relevant SQLs and validate their execution plans before deciding on corrective actions. This reduces manual investigations, helps identify the right team to involve, and supports quicker incident resolutions with clear evidence.

Foglight for Databases supports monitoring multiple database platforms through a central console in our environment. We use it for Oracle, Amazon RDS for Oracle, SQL Server, PostgreSQL, MongoDB, and many more. Having a common view of database health, alerts, and performance makes daily monitoring easier and helps prioritize incidents across systems. If an application slows down, we can compare the underlying databases and investigate affected instances, which helps coordinate troubleshooting across teams and reduces the time spent switching between separate monitoring tools.

I consider rapid diagnosis one of Foglight for Databases's most valuable capabilities. Bringing alerts and performance details together helps narrow down whether an emerging issue involves an expensive SQL, blocking sessions, resource pressures, or unusual workload activities, which provides the DBA a clear starting point for corrective actions. This feature is very important for me since a slowdown in business-critical databases can quickly affect users and service commitments. Earlier detections and focused investigations help reduce troubleshooting time and prioritize issues before escalating. Foglight for Databases supports investigation, while the DBA validates the cause, applies an approved fix, and checks that performance has recovered.

I regard Foglight for Databases's broader monitoring capabilities as valuable because database performance is closely connected to the underlying infrastructures where monitoring components are configured. Visibilities into databases, operating systems, and cloud resources help put alerts into context. For example, when an Oracle database slows down, correlating its wait with CPU, memory, and disk activities helps distinguish between SQL problems and infrastructure bottlenecks, making investigations more focused and involving the right support team. The main benefit is better insights into how different layers affect each other.

As everyone is slowly shifting towards AI, the most important feature that we are planning is integrating with the current ongoing processes, along with addressing some repetitive issues. We are also planning to integrate AI with the repeated problems to come up with some solutions, but we have not found any solution for that yet. If we can integrate AI, that is my only suggestion; the rest are all good. So far, it is good. I do not have any additional improvements required beyond the AI, which I have already mentioned.

I have been using Foglight for Databases for the last 10 plus years.

Foglight for Databases is very stable.

Its scalability is good, and we are happy with it. As demand increases, it helps us with auto-scaling features as well.

Customer support for Foglight for Databases is very quick, and we are very satisfied with it. They resolve issues efficiently and also provide proper explanations for problems along with permanent solutions. I would rate customer support as nine out of ten.

Before Foglight for Databases, we used Oracle Enterprise Manager for monitoring in conjunction with SQL scripts and manual database checks. The reason for adopting Foglight for Databases was to achieve more centralized visibility across database platforms and simplify performance investigations. We still use Oracle Enterprise Manager, but we find Foglight for Databases to be much better since Oracle Enterprise Manager is useful only for Oracle-specific administrations while Foglight for Databases provides a common monitoring view for wider environments.

Foglight for Databases has helped us a lot in monitoring and performance, but I have not measured a formal financial return. I cannot provide verified figures for money saved or reduced staffing. The operational value I emphasize is more focused troubleshooting and less manual work collecting performance information from separate sources. To quantify the value, I would track average incident diagnosis times, mean time to resolutions, and hours spent on routine monitoring before and after adoption, describing the staffing benefit as freeing DBA time to other priorities rather than claiming fewer employees are needed.

We purchased Foglight for Databases from the Azure Marketplace. Regarding the pricing, setup cost, and licensing for Foglight for Databases, we implemented a project called Project Latte. My involvement was mainly in database operations rather than purchasing, so I cannot provide exact pricing or licensing figures. From an operational perspective, setting up efforts include configuring monitoring connections, permissions, and agents where required. I assess the overall value against database coverage we need, ongoing administration efforts, and the troubleshooting time saved. Clear license terms and visibilities into the cost of expanding coverage are quite important for us, although I do not deep dive personally as a DBA.

We have not evaluated other options because we are very specific to Foglight for Databases.

On a scale of one to ten, I would rate Foglight for Databases as ten out of ten. I choose ten out of ten because it has helped us save a lot of time in doing manual investigations and initial troubleshooting, which has been efficiently handled by Foglight for Databases. Considering the time, it has really helped a lot, along with the reports and the way it works, which is really appreciable.

Regarding Foglight for Databases's AI capabilities, I am cautiously positive about its governance and security from a DBA perspective. Quest documents show that encrypted communications and authenticated access are not used to train AI models, which are reassuring controls when working with database diagnostics. However, I would verify exactly what SQL text schemas and monitoring data leave our environment. Processing takes place in the US Azure regions, with AWS retention exceptions, optional feedback, and use detections in place. Data residencies and sensitive information are crucial, and I would use these AI insights to support DBA operations, following change approval procedures before production changes. Clear visibilities into data sharing, retentions, and administrative controls strengthen my confidence.

I see Foglight for Databases's AI output as a useful starting point for investigating database issues, although its value depends on whether the explanation matches the monitoring evidence and context of the problem. For Oracle troubleshooting, I validate its conclusions against the wait events, SQL execution plans, session activities, and relevant AWR or ASH data. Complex issues involving RAC, application behavior, or multiple simultaneous bottlenecks still require a DBA's judgment, and my confidence increases when the output clearly shows supporting matrices, explains its reasoning, and acknowledges uncertainty. I review and test any tuning recommendations before applying them in production.

We use Foglight for Databases to monitor the databases hosted on AWS, including Amazon RDS for Oracle. Foglight for Databases itself is deployed across all our different areas; we use it on AWS, Azure, and on-premises servers. It actually depends on the project and environment. We predominantly use Azure and very rarely use AWS.

My advice to others looking into using Foglight for Databases is to start with a proof of concept using representative databases, and I do recommend them to use Foglight for Databases. I have given Foglight for Databases an overall review rating of ten out of ten.

I am currently using Foglight for Databases with real-time monitoring only.

We use this tool for monitoring purposes only. Frequently, we monitor the tool by logging into all servers and fetching the output using queries. We can check the homepage of Foglight for Databases and verify whether all databases are running fine or not. We can differentiate based on different types of databases such as Oracle databases, MS SQL, and MySQL, and we can monitor them separately as well.

Foglight for Databases enables me to monitor multiple database platforms. It is currently monitoring MS SQL databases and Oracle databases for me. We can divide the databases based on types and monitor using those specific database types only.

Using Foglight for Databases will drastically reduce the employee size. Without Foglight for Databases, we have to use multiple employees for monitoring different databases. By using Foglight for Databases, we can significantly reduce those employees, thus saving their salaries.

Foglight for Databases saves costs when performing root cause analysis.

Foglight for Databases is a user-friendly tool. On the homepage, we can see whenever it is connected to all production and disaster recovery databases, and it is easy to monitor on the homepage itself. It displays indications such as CPU utilization, load average, and session details including the number of sessions and active sessions. It shows details such as critical outages with three indications: warning in orange color and critical outage in red color. It also displays error messages regarding what errors have occurred in that particular database, allowing us to fetch and find the error and solve the issue as soon as possible.

By clicking the database by server name, it can be divided to show the report on a node-by-node basis. In that report, we can see multiple data such as the users connected to the database, the SQL running, and how much time it has been taking. We can also see the output in pie charts, making it very easy to analyze.

Foglight for Databases is easy to monitor, and we can fetch the report node-by-node. We can obtain all other database information such as backup information, table space size information, disk group size, ASM storage, and SP file parameter files. We can directly fetch everything in Foglight rather than using commands in the server itself. Report generation is also easier in Foglight, and using this, we can optimize performance and queries.

Foglight for Databases is very useful; however, the negative side we face is that customer care support is not frequent. If any issues related to Foglight arise, we cannot reach customer care support as soon as possible. It takes much longer compared to other third-party tools, and that is a major issue we are facing with Foglight for Databases.

Foglight for Databases is good for monitoring, and we can fetch problematic issues and queries. However, the only main drawback is the customer care support. It is available only during the general shift, so if any issue occurs after 6:00 p.m. or before 9:00 a.m., there is usually no one to handle it. I think there are only two or three people handling customer care for Foglight for Databases.

I have been using Foglight for Databases for nearly two to two and a half years.

I did not have any issues with Foglight for Databases.

Foglight for Databases is very useful; however, the negative side we face is that customer care support is not frequent. If any issues related to Foglight arise, we cannot reach customer care support as soon as possible. It takes much longer compared to other third-party tools, and that is a major issue we are facing with Foglight for Databases.

Foglight for Databases is good for monitoring, and we can fetch problematic issues and queries. However, the only main drawback is customer care support. It is available only during the general shift, so if any issue occurs after 6:00 p.m. or before 9:00 a.m., there is usually no one to handle it. I think there are only two or three people handling customer care for Foglight for Databases.

For customer support regarding Foglight for Databases, I would rate it a three out of ten.

Before going with Foglight for Databases, we were using inbuilt services in Oracle databases only. We could utilize certain queries and services in Oracle to fetch and find problematic solutions, and we worked in that format only.

Foglight for Databases saves costs when performing root cause analysis.

Using Foglight for Databases will drastically reduce the employee size. Without Foglight for Databases, we have to use multiple employees for monitoring different databases. By using Foglight for Databases, we can significantly reduce those employees, thus saving their salaries.

For intensive database queries, Foglight for Databases is useful. If any abnormal activity occurs such as sessions, CPU load average, or any kind of issue on the database side, we can fetch what the problematic query is, who runs that query, and what the issue is. We can then gather that output and optimization query to send to the application team.

Monitoring different aspects such as the operating system, hybrid clouds, hardware, and databases across different platforms is important because at one point, we can monitor different types of operations such as the operating system side and the database side. If we are using Oracle cluster, we can fetch information regarding the cluster, ASM info, and everything else. We can monitor everything in one single point, and it is very useful to us.

Foglight for Databases is the best tool for monitoring all aspects such as database, backup information, storage information, and operating system side. Everything is very easy to analyze, and it throws error and warning messages as soon as it completes the tasks. It is very useful for monitoring. However, the only issue is customer care support.

I rate this review an eight out of ten.

For example, when production CPU is at 95%, I identify which query is consuming excessive CPU by checking Foglight. I then review the execution plan in SQL Server Management Studio and verify the indexes, statistics, and whether the query has recently changed. I coordinate with the development team if query modification is required and monitor CPU after the remediation.

I have also monitored blocking in Foglight. When Foglight shows significant blocking, I identify the head blocker first rather than identifying and killing the session. I check the blocking session ID, blocked session ID, SQL statement, transaction duration, database involved, application, and locks to determine whether the transaction is expected or abnormal. If necessary, after appropriate approval, I terminate the blocking session and investigate the underlying causes.

Foglight for Databases is deployed in a hybrid environment in our organization. We monitor the databases running on-premise infrastructure as well as the databases hosted in AWS. This is useful for our DBA team because we can have centralized monitoring access with different environments instead of using separate monitoring solutions for each platform. We primarily use Foglight for Databases for database health checks, performance monitoring, alerts, troubleshooting, and historical performance analysis across these environments.

Foglight for Databases has positively impacted our database operation mainly by improving monitoring and troubleshooting efficiency. It provides a centralized view of database health checks and performance, which helps us identify issues such as high CPU, memory blocking, and slow running queries more quickly. It has also helped us reduce the time spent on the initial investigation during production incidents because we can quickly identify the affected database based on the relevant performance metrics, with historical data being useful for trend analysis and root cause investigation.

I estimate Foglight for Databases can save around 20 to 30 minutes during the initial investigation for production database issues because it gives me a centralized view of CPU, memory, blocking, waits, sessions, and query activity. During a production incident, Foglight for Databases helped me quickly identify that the issue was related to high resource utilization and blocking sessions. Instead of checking multiple metrics separately, I start with the Foglight for Databases dashboard to identify the affected database and session, then validate the details in SSMS.

Foglight for Databases features like monitoring information and dashboard presentation are prominent in the product. Feature capabilities I usually use include database health check monitoring, real-world performance monitoring, CPU memory, disk space issues monitoring, block and deadlock detection, SQL query performance analysis, alert and notification, historical performance trend analysis, database availability monitoring, capability and storage monitoring, and centralized monitoring for multiple database environments.

The features I use most are real-time database performance monitoring and troubleshooting, which give me a centralized view of important metrics such as CPU, disk space monitoring, blocking sessions, waits, and query performance. It adds the most value during a production incident because I can quickly identify which database is responsible for the SQL activity that caused the issue, validating the findings in SSMS. The historical performance data is also useful for identifying trends and comparing performance before and after changes. Overall, it helps me reduce the time required to identify the root cause of any database performance issue.

I use Foglight for Databases's real-time activity and performance monitoring capability during database operations, particularly for production troubleshooting. For example, if an application suddenly becomes slow, I use Foglight for Databases to check the current database activity, active sessions, CPU utilization, waits, blockings, and resource investigation in SQL.

I use Foglight for Databases Angular UI to monitor database activity and identify long-running or resource-intensive queries. For example, if a query starts running significantly longer than the normal execution plan time, Foglight for Databases can bring it to our attention. I review the query details along with CPU, I/O, waits, and blocking information, then validate the issue in SSMS using the execution plan and DMVs.

Foglight for Databases allows us to drill down from a high-level database server alert into more detailed performance information. For example, if I see something unusual in a high-level alert, I first validate the alert and identify which server or database is affected. I then use Foglight for Databases's drill-down capability to move from the overall health view into the specific performance that's causing the alert.

One useful capability of Foglight for Databases is that it provides centralized monitoring across multiple database platforms.

I assess Foglight for Databases's capability to quickly diagnose emerging database issues as very useful for day-to-day production operations. This ability to start with a high-level alert and drill down into database activity, sessions, queries, blocking, and CPU waits shortens the initial troubleshooting process. It's especially important in production environments where sudden performance issues can quickly affect application users.

My impression is that Foglight for Databases provides useful visibility across different layers of the environment, particularly database and infrastructure metrics that are relevant to DBA operations. Having information about database performance, server resources, CPU, memory, blocking, and query activity in a centralized monitoring platform is invaluable.

Foglight for Databases is useful for database monitoring and troubleshooting, but there are a few areas where it could be improved. I would appreciate more customization in the dashboard and simpler configuration of alerts. It would help to easily customize the dashboard based on the specific requirements for different DBA teams and environments. Another useful improvement would be more intelligent alert correlation and root cause analysis so that related alerts can be grouped and the tool can clearly indicate the issues.

I have used Foglight for Databases over the last 12 months.

Foglight for Databases is stable in my experience.

Foglight for Databases handles growth reasonably well, especially when additional database instances need to be brought under centralized monitoring. As our database environment changes, we can add monitoring instances and continue using the same monitoring and alert approach.

I have not personally interacted with Foglight for Databases customer support team frequently, but my experience with them has been positive. Whenever we need assistance, the support process is handled through the appropriate organizational support channels.

Before Foglight for Databases, we relied more heavily on native database and infrastructure monitoring tools such as SQL Server Management Studio, SQL Server agent alerts, and Windows manual checks. The biggest improvement for DBA operations was the ability to quickly identify and drill down into performance issues and use historical information for troubleshooting and trend analysis.

I have seen a return on investment using Foglight for Databases for our database operations.

I was not involved in the formal evaluation process, so I do not know which competing solutions were evaluated before Foglight for Databases was selected. I understand that the key requirements were centralized database monitoring, performance visibility, proactive alerting, troubleshooting capability, and support for the organization's database environment.

Governance and security are important considerations when using AI capabilities in database monitoring. AI-driven recommendations must follow the same access control and security policy as the underlying monitoring platform. I particularly look for strong role-based access control, secure handling for database and performance information, auditability, and clear visibility into how AI-generated recommendations are produced and what data they use.

I find the output from Foglight for Databases most valuable as a starting point for troubleshooting rather than as a replacement for DBA analysis. For production issues, I always validate the recommendations against SQL Server metrics, execution plans, DMVs, logs, and the actual application behavior before taking corrective action. This is particularly important because database performance issues can have multiple contributing factors. Overall, I consider the output useful for accelerating investigation, but I still rely on data validation before making production changes.

I recommend that organizations evaluate Foglight for Databases by first identifying their main monitoring and troubleshooting requirements and then validating those requirements with a representative setup of their database environment.

I give Foglight for Databases an overall rating of 8 out of 10 because it is very helpful for any database monitoring such as CPU and memory, which is essential for my daily routine work.

Monitoring databases is a major use case for Foglight for Databases. We use Foglight for Databases to display intensive database queries.

Foglight for Databases is not a tool that you use to see before a problem happens. However, after we have an issue such as downtime, service failure, or performance issues on the database, we use it to identify the queries that are causing problems, maybe a stored procedure, identify the user that is running that query, the machine where that query is coming from, and do our job as database administrators to optimize the query.

When using Foglight for Databases for monitoring databases, it enables me to drill down and see what is causing the issue if something does not look right. We often use it to drill down and see how long something has happened for, especially for performance tuning, looking at how long any current issue has run for, identify bottlenecks, and get recommendations, because Foglight for Databases gives recommendations on some levels. We use those recommendations to improve or optimize the system.

The best features of Foglight for Databases should be the real-time dashboard and the overview dashboard.

I find the overview and real-time dashboards the most beneficial in Foglight for Databases. For example, with the overview dashboard, I could know what is happening on the database in real-time. Most especially when it comes to blocking sections, I can see if the blocking sections are increasing and then take actions. With the real-time dashboard, I can see performance on a bigger scale, including CPU usage, memory usage, and general performance.

In terms of scalability with Foglight for Databases, I think the tool is somewhat robust compared to other monitoring tools that I have used. I would say it is somewhat rigid to understand if you are a beginner, and it might take a while to understand how to go about using the tool, which requires that training must be done. I would not say there are significant limitations or scalability issues with it.

Besides scalability and customization aspects, I think with the newer version of Foglight for Databases, there are many bugs that need addressing. We encountered instances where it was not even monitoring databases at all or giving us false alerts, which impacts our usage of the application. So I would say that needs improvement, as it leads to confusion about whether databases are down or if the alerts are accurate.

I have been working with Foglight for Databases for about three years.

I have had stability issues, crashes, downtimes, and performance issues with Foglight for Databases in this recent version I have been using. I have not experienced many issues with it in other organizations. However, with the latest version, we have had many crashes, sometimes it stops working entirely, and it can take days to restart the service. Therefore, I think it is an issue related to the new version that has been upgraded.

In terms of scalability with Foglight for Databases, I think the tool is somewhat robust compared to other monitoring tools that I have used. I would say it is somewhat rigid to understand if you are a beginner, and it might take a while to understand how to go about using the tool, which requires that training must be done. I would not say there are significant limitations or scalability issues with it.

I use the vendor's premier support for Foglight for Databases. On occasions when we have issues, we always call Quest, and they come on the call to help us out.

I would rate tech support on a scale of one to ten as a six. The reason I give it a six is that most of the time we have an issue, the support seems time-framed. Even if the issue is not resolved, they often want to get off the call because their time has elapsed, which leads us to go back and forth on the same issue until we eventually get it solved.

Prior to adopting Foglight for Databases, I previously used other solutions of the same kind, including Dynatrace and Ash viewer.

I decided to switch to Foglight for Databases because, as I mentioned earlier, it is more robust and gives more insights compared to the other tools I have used. However, the application's robustness makes it somewhat hard for beginners to understand how it works, which requires additional training to ensure everyone can adjust and fully utilize it.

I evaluated other solutions before choosing Foglight for Databases. The decision to go with Foglight for Databases stemmed from its robustness and the insights it provides compared to other applications and tools.

My experience with the deployment process of Foglight for Databases was challenging because the installation was done on a Linux environment instead of Windows. With Linux, we faced many configuration and permission issues, particularly ensuring that the agent server and management server could communicate with the database server. There was much back-and-forth in getting the installation fully set up before we started using it.

A consultant was used for the deployment of Foglight for Databases, and I think he was from Egypt, but I cannot remember his country exactly.

I would not say Foglight for Databases saves me cost when performing root cause analysis because, based on what I know, payments are made upfront. Regardless of what I use the tool to do, you have to make payment upfront for the license and support, and then you use it based on whatever issues that arise. So in terms of payment or fees, I do not think it matters.

Prior to adopting Foglight for Databases, I previously used other solutions of the same kind, including Dynatrace and Ash viewer.

I decided to switch to Foglight for Databases because it is more robust and gives more insights compared to the other tools I have used. However, the application's robustness makes it somewhat hard for beginners to understand how it works, which requires additional training to ensure everyone can adjust and fully utilize it.

I evaluated other solutions before choosing Foglight for Databases. The decision to go with Foglight for Databases stemmed from its robustness and the insights it provides compared to other applications and tools.

My impressions of Foglight for Databases' ability to help me monitor a variety of aspects such as the OS, hybrid clouds, hardware, and databases across different platforms have been great so far. I have used it in multiple organizations, and my impression is that it is a tool that every organization should use or buy into because they understand its value.

Based on my experience with Foglight for Databases, I recommend running it on a Windows server, as it is much more flexible compared to Linux. Additionally, trainings should be conducted after installation so that everyone can understand how to use the application and utilize it fully. I would rate this review a seven out of ten.

My use case for Foglight for Databases is basically to track performance.

Foglight for Databases allows us to save up to four months of data, enabling us to track performance data for at least one quarter. It tracks everything including Apache and IAS databases. We do not track Cosmos because Microsoft itself provides a good alert system for that with a one-month overview.

Real-time activity data from Foglight for Databases provides alerts. While we have it set up, we don't use it much for live activities because we already have alerts set up inside our other monitoring tools, such as LogicMonitor.

Foglight for Databases enables us to monitor multiple database platforms. We track various databases including Postgres, MySQL, SQL, PaaS, and MI. We are aware of new support for Scylla, but we haven't implemented it yet. We don't track Cosmos because Microsoft provides a better solution.

We use Foglight for Databases to display intensive database queries. We receive alerts and train our LLMs, but everything is still in testing and not live yet because we don't want to expose our data.

Foglight for Databases does help us drill down to see what causes issues, but it can sometimes misattribute slow running procedures to database performance when it could be a network issue.

There has undoubtedly been an increase in speed for diagnosing and resolving issues with Foglight for Databases. I give it a rating of ten out of ten because it effectively saves us memory and resources.

The room for improvement for Foglight for Databases is primarily related to its cost. We pay a hefty amount and only use it for our production servers, not for non-production environments.

Currently, we don't use the Angular UI in Foglight for Databases to proactively alert us for long-running queries. We have a different set of systems, although we are working on some in-house LLM models.

I don't find Foglight for Databases to be very scalable. There are other tools in the market that do the same for less money.

I have been using Foglight for Databases for almost one year.

Stability-wise, I rate Foglight for Databases around a nine out of ten. Although we had one significant issue, they were generally reliable.

I don't find Foglight for Databases to be very scalable. There are other tools in the market that do the same for less money.

From one to ten, I would rate scalability for Foglight for Databases at a three or four from my perspective regarding its price point.

From one to ten, I would rate the technical support of Foglight for Databases a ten because they respond effectively, regardless of the time or day.

We haven't used any other solutions to compare Foglight for Databases with. Before this, we developed our in-house alerts, which are live, but SQL Server only allows us to keep logs for maybe two or three weeks.

We use Foglight for Databases to display intensive database queries. We receive alerts and train our LLMs, but everything is still in testing and not live yet because we don't want to expose our data.

Overall, I would rate Foglight for Databases at eight point five to nine, factoring in that the pricing weighs it down compared to less expensive alternatives I've explored.

I would definitely recommend Foglight for Databases if budget is not an issue. Although it's necessary to be cautious about dependency on tools within Azure, it stays as a top option if resources allow.

Foglight for Databases is primarily used to monitor SQL Server databases. Another valuable aspect of my main use is obtaining a global view of the health and performance of servers and instances, as it shows real-time metrics and historical data for change before a statement.

Foglight for Databases has helped me with monitoring because it centralizes monitoring, detects bottlenecks, and guides me to diagnose and resolve performance issues faster. It also helps me with alerts, historical analysis, blocking, high availability and disaster recovery, reports, and allows me to spend less time looking for the problem and more time fixing it.

I would highlight the functionality of Foglight for Databases that includes query analysis, waits, blocking and deadlocks to find the root cause. It offers advisories and built-in workflows to speed up resolution, and it allows reports and dashboards to share findings with development, operations, or management.

Foglight for Databases provides the advantage of integrating monitoring, diagnostics, and reporting together in a single console, instead of reviewing multiple tools and tables manually, which reduces the time needed to identify whether the problem is in CPU, memory, input, output, queries, blocking, or configuration.

Foglight for Databases has had a positive impact on my organization and on the projects where I have implemented it because I manage SQL Server Always On and mixed workloads, and it shows high availability and disaster recovery information while allowing me to see the operational status of the platform from a single panel. The main value lies in speeding up root cause analysis and prioritizing what to address first.

Foglight for Databases has helped me prioritize issues and speed up root cause analysis by being connected to ServiceNow, as it automatically creates the ticket for us. Since everything regarding thresholds and alerts is already configured, we avoid several false positives that would only waste our time instead of letting us focus on what really needs attention.

Foglight for Databases could improve in the operational accuracy of alerts or have thresholds adjusted per environment, reducing noise and aligning each alarm with a clear action. While it already provides lightweight monitoring, diagnostics, and alerts, its value grows when you customize rules and context for high availability.

I think it would be beneficial for Foglight for Databases to correlate related events, for example, a failover plus a replica going down plus latency in a single actionable alarm. Separating warning alerts, degradation, critical incident with different escalation, including context in the message such as instance, availability group, affected replica, average value, and severity, should be considered. Additionally, reviewing and adjusting templates with historical metrics can help them reflect the real baseline or defining alerts by real criticality to avoid false positives in normal load peaks.

Foglight for Databases could benefit from fewer generic alerts and more rules based on impact, priority, and action path, which would make it more useful for daily operations, on-call shifts, and incident follow-up.

I have been using Foglight for Databases since 2005 in some projects.

Foglight for Databases is stable, and I have not had any stability or availability issues with it.

I have not faced challenges with the scalability of Foglight for Databases, as I have not had more than 5,000 database servers, so I suppose the load on the internal database has not affected me.

I generally have not had to contact the technical support team of Foglight for Databases, as they have given us good support without problems. I would rate the technical support of Foglight for Databases a 10, since I have not had problems with them.

I have not used any other solution before Foglight for Databases, as I generally arrive where the monitoring tool is already installed in the companies since 2005 when I started using Foglight at General Electric. We used native tools, but we decided to use Foglight for Databases because it offered some time savings.

Using Foglight for Databases has been beneficial because it is a third-party tool that already has all of Dell's or Quest's experience, adding value in terms of ROI mainly through three avenues: less diagnostic time, fewer prolonged incidents, and less operational inefficiency. Quest highlights that Foglight for Databases helps monitor, predict, diagnose, and resolve issues faster and that it can reduce MTTR by focusing on high-impact query analysis.

Before choosing Foglight for Databases, I did not evaluate other options extensively; I only helped evaluate them by giving my comparison between two or three, for example, Foglight for Databases with SolarWinds and with SentryOne. Then, depending on each company or the budget, they decide which one to implement, and I adapt to whichever they use in the end.

My advice to other professionals considering implementing Foglight for Databases is that they should evaluate the thresholds and the advantages and disadvantages of each option they could implement and based on that decide on one or another, because Foglight for Databases, for example, gives you more value when it is used to detect, diagnose, and resolve quickly and not just to look at screens.

I think it is important that they can implement Foglight for Databases in phases with clear use cases, useful metrics, and actionable alerts so they obtain value quickly and avoid the tool becoming another source of noise, often caused by monitoring tools that generate too many alerts or noise. Configuring it as best as possible is essential to avoid being woken up in the middle of the night or on weekends or during on-call shifts to deal with things that do not make sense if they are not configured well.

I emphasize that they can implement Foglight for Databases in phases with clear use cases, useful metrics, and actionable alerts so they obtain value quickly and avoid the tool becoming another source of noise, which is often the case with monitoring tools generating too many alerts. I would rate this review a 9 overall.

My main use case is database performance monitoring and troubleshooting. As a developer, I use Foglight for Databases to understand whether database performance is contributing to an application issue and to identify slow-running SQL statements or resource bottlenecks. For example, if we notice that a particular API or batch process is taking longer than expected, I'll use Foglight for Databases to review database health, check for long-running SQL queries, look at wait events or blocking sessions, and then work with the DBA team if any database tuning is needed. Having that visibility helps us narrow down the root cause much faster instead of relying only on application logs.

I use it on an as-needed basis, rather than monitoring it constantly throughout the day. Whenever we are investigating a performance issue, a slow API, or a batch process that is taking longer than expected, Foglight for Databases is one of the first tools I check. During periods such as releases or when we are troubleshooting production issues, I may use it several times a day. Otherwise, I rely on it whenever database performance needs to be validated or when we need to quickly determine whether the database is contributing to an application issue. It has become an important tool for root cause analysis.

The standout feature for me is real-time database performance monitoring. It gives a clear view of the overall health of the database and helps identify issues before they become major problems. Another feature I find very valuable is SQL performance analysis. It makes it much easier to identify slow-running queries and understand where performance bottlenecks are occurring. I also like the alerting and historical performance analysis. Being able to look at trends over time instead of just current metrics is very helpful when investigating intermittent issues. Finally, the lock and session monitoring capabilities make it much easier to identify blocking sessions and work with the DBA team to resolve performance problems quickly.

We have seen a positive impact. The biggest benefit has been faster issue identification and resolution. When database-related performance issues occur, Foglight for Databases helps us quickly determine whether the database is the root cause instead of spending time investigating multiple layers of the application. It has also helped reduce downtime by providing proactive alerts, allowing the operations and DBA teams to address potential issues before they affect end users. From a developer perspective, having visibility into SQL performance and database health has improved collaboration with the DBA team and has also reduced the time needed to troubleshoot production issues. While I do not have the exact organization-wide metrics, I would say it has noticeably improved our operational efficiency and has helped us resolve performance-related incidents very quickly.

If I had to choose one feature, it would be SQL performance analysis. As a developer, that is the feature I rely on the most because it helps me quickly identify whether a slow application response is being caused by a database query. Instead of spending a lot of time manually investigating, I can see which SQL statements are consuming the most resources and focus my troubleshooting efforts there. I would also add that all of the features work well together. Real-time monitoring tells me if there is an issue. SQL analysis helps identify the cause, and the historical trends and alerting provide the context needed to understand whether it is a one-time event or part of a recurring pattern. That combination makes troubleshooting much faster and more effective.

Based on my experience, I would estimate we are able to resolve database-related performance issues about thirty to forty percent faster than before. The biggest improvement comes from being able to quickly identify whether the problem is database-related or not. Instead of manually collecting information from different sources, Foglight for Databases gives us visibility into SQL performance, sessions, and resource usage in one place. That allows developers and DBAs to focus on the root cause much sooner, which shortens the overall troubleshooting process.

Overall, I am happy with the product, but there are a few areas where it could be improved. First, I think the user interface could be more modern and intuitive, especially for new users. Some dashboards and navigations take time to get familiar with. I would also like to see more customizable reports and dashboards, so different teams such as developers, DBAs, and operations can tailor the information to their specific needs. Finally, while the product provides a lot of performance data, there can be a learning curve when interpreting some of the advanced metrics. Additional built-in guidance or recommendations would make it easier for less experienced users to get value from the tool more quickly.

The improvements I would like are mostly around usability and ease of adoption, rather than core functionality. The monitoring, diagnostics, and performance analysis capabilities are already quite strong. I would see these as enhancements that would make the product even better, rather than issues that prevent me from recommending it.

I have been using Foglight for Databases for about a year.

My advice would be to clearly identify what you want from a database monitoring solution before evaluating it. If your organization relies on business-critical databases and needs proactive monitoring, performance diagnostics, and faster troubleshooting, I think Foglight for Databases is a strong choice. I would also recommend investing some time in learning its dashboards, alerts, and performance analysis capabilities. Once the team becomes familiar with those features, it is much easier to identify performance bottlenecks and resolve issues quickly. I would recommend it to organizations that want better visibility into their database environment and a more proactive approach to performance monitoring rather than reacting to problems after they have already affected users.

I have had a positive experience with Foglight for Databases. It has been a reliable tool for monitoring database performance, identifying bottlenecks, and helping us troubleshoot issues more efficiently. It has improved collaboration between developers and DBAs by providing a common view of database health and performance. While I would like to see continued improvements to the user interface and dashboard customization, those are relatively minor compared to the value the product provides. I would be comfortable recommending it to organizations that manage business-critical databases and want a proactive approach to monitoring and performance management. My overall review rating for this product is nine out of ten.