Case Study: Network Performance Dashboards and Reporting over Sybase Data
A production data-access layer for dashboards and operator-specific reporting
The client's network performance data remained in Sybase. Grafana had no suitable native Sybase data source, and the same data was needed for reports delivered to several mobile network operators. We built a PostgreSQL bridge and generated KPI functions that gave both workflows a defined query path. The bridge reduced repeated work against the source database and kept operator-specific data handling outside the vendor-supplied tooling.
Network data needed to support tools beyond the existing platform
The client operates shared indoor 4G and 5G infrastructure for multiple mobile network operators. Its Sybase ASE data warehouse held performance counters for connection success, capacity, and quality. Sybase remained the source system. The client needed to use its data in Grafana and in its own reporting workflows rather than remain limited to the access paths provided by the network-management platform.
Grafana had no suitable native Sybase data source. Its established PostgreSQL integration provided a practical interface, but simply passing every panel request through to Sybase would have repeated the same raw-data queries across dashboards containing many panels. The data layer therefore needed to bridge the database protocols and coordinate access to shared results.
The data layer had to preserve the differences within the network
- PostgreSQL needed to expose the query surface used by Grafana while retrieving source data from Sybase over TDS.
- Panels using the same raw data needed to share cached results rather than repeatedly issue equivalent source queries.
- 4G and 5G used different managed-object structures, including separate distributed-unit and central-unit cells for 5G aggregation.
- Operator-specific KPI names and quality-of-service mappings had to be normalised into consistent dashboard results.
- The same controlled data-access layer needed to support scheduled reporting without coupling report generation to dashboard definitions.
A PostgreSQL bridge with generated and cached KPI functions
We configured PostgreSQL with a foreign data wrapper that mapped the required Sybase tables into PostgreSQL and translated queries over the TDS connection. Grafana could use its PostgreSQL data source, while the bridge contained the Sybase connection and schema details.
During development and deployment, a PHP generator inspected the source schemas and produced approximately 40 PostgreSQL functions. The generated SQL was then loaded into PostgreSQL. The functions covered 4G and 5G cells, cell and site aggregation, quality-of-service breakdowns, and operator normalisation. Generation avoided maintaining the same SQL structure manually across every KPI.
Each relevant function acquired a PostgreSQL advisory lock for the requested cell or site and checked a cache with a configurable validity period. It queried Sybase only after the cached result had expired. This coordinated concurrent panel requests using the same underlying data and reduced repeated work at the source. The generated functions and Grafana query definitions together supported grouping by baseband unit, site, and mobile network operator.
A shared production data path for dashboards and reporting
The bridge runs in production and routinely supplies operational network-performance dashboards. It supports views across all operators represented in the Sybase database, with filtering and grouping by operator, site, or baseband unit and with separate handling for 4G and 5G data.
The reporting pipeline uses the same PostgreSQL foreign-table layer as its shared query path. Separate TypeScript modules then transform the retrieved data into the formats required by each operator. This keeps access to Sybase in one controlled layer while allowing dashboards and scheduled reports to apply different presentation and delivery logic.
Data freshness remains governed by the source data and the configured cache-validity period. This is a deliberate trade-off: dashboard requests reuse data within that period instead of repeatedly querying Sybase for an equivalent result.
Extending data access without replacing the source system
Sybase remained the right source system for this requirement; replacing or migrating it was unnecessary. The PostgreSQL bridge made its data available for dashboards and reporting while reducing reliance on the network-management vendor's own tooling for access, visualisation, and downstream use.
Keeping KPI calculation, cache policy, and operator normalisation in generated database functions prevented those rules from being reproduced across many Grafana panels. Reporting remained a separate application concern, built on the same access layer rather than embedded in the dashboards.
Related case studies:
- Automated Multi-Operator Report Delivery covers report generation, recipient-specific SFTP delivery, operational failure handling, and fortnightly health reporting in detail.
- Operational 4G/5G Cell Management covers the production interface used to find, inspect, lock, and unlock cells through the network-management platform.
Client names and identifying details have been withheld to protect confidentiality.
Need to use data held in an existing platform?
Tell us where the data is held and which dashboards, reports, or operational tools need to use it.
