Incident Management
Platform
AI
Dedicated compute
Dedicated compute keeps concurrent queries stable and complex analysis fast.
Learn moreDedicated compute
Dedicated compute keeps concurrent queries stable and complex analysis fast.
Learn moreObservability is evolving, but the underlying systems are stuck in the past
As business evolves, the data accessed by the observability platform is no longer limited to basic monitoring metrics, but also includes application logs, links, user experience, and business data. As data scale, query concurrency, and retention cycles continue to grow, traditional architectures tightly coupled with computing and storage tend to encounter bottlenecks in scaling efficiency and resource utilization.
Dashboards, monitors, and day-to-day troubleshooting generate large volumes of repeated queries. GuanceDB 3.1 uses purpose-built engines and streaming aggregation to identify query patterns that can be accelerated, reduce repeated scans of raw data, and schedule query resources according to actual load.
Traditional MPP architecture vs. GuanceDB 3.1
This comparison shows how GuanceDB 3.1 separates storage from compute, allowing query resources to scale independently with workload and providing greater flexibility across performance, cost, and resource isolation.
Traditional MPP architecture
Computing and storage are tightly coupled, with limited scalability. Computing resources are difficult to adjust dynamically, overall utilization is low, and expansion costs are high.
A fully separated storage engine for the AI era
It adopts integrated data lakehouse design and separation of storage-compute, allowing data storage and query computation to expand independently. The system leverages the elasticity of cloud infrastructure to adjust query resources according to business load and optimize resource costs according to different computing power types. For example, computing resources are expanded during weekday peak queries, and idle computing power is reduced during nights and weekends. Actual capacity, query concurrency, and elasticity range are subject to deployment specifications and service quotas.
Tailored to the needs of different enterprises
With dual engines, intelligent scheduling, multi-tenant optimization, and elastic compute, GuanceDB 3.1 advances observability data processing across performance, cost, and flexibility, helping enterprises build a more efficient data foundation.
The system has built multi-level resource scheduling strategies based on different enterprise usage scenarios:
01. High cost-performance users
Priority is given to the use of shared computing pools, and idle computing power in the system can be flexibly called during peak periods to maximize resource reuse
02. Performance-sensitive users
Configure independent query computing clusters to ensure stable and fast response capabilities in any scenario
03. Small and medium-sized teams
Unified access to the shared pool, the system uses concurrency control mechanisms to ensure the query experience while keeping costs controllable
04. Users who prioritize storage
By adopting independent processing paths, computing resources are stripped, further reducing system load and cost
Dual-engine routing sends each data type down the right path
Metric Engine is built for high-cardinality time series, while Event Engine handles logs, traces, RUM, security events, and AI Agent Events. GuanceDB 3.1 routes data by model during ingestion, then exposes a unified query interface through DQL and Query Router.
Purpose-built metrics engine
Optimized storage and query paths for time windows, long-term trends, and high-cardinality metrics
Purpose-built event engine
One engine for Logs, Traces, RUM, Events, and AI Agent Events
Unified query interface
DQL and Query Router schedule compute by workload while preserving a consistent user experience
A purpose-built inverted index turns full scans into direct lookup
Event Engine maps terms to records as logs are ingested. Full-text queries locate matching records through the index before reading the relevant data, avoiding repeated scans of raw text and reducing compute and storage amplification.
Build the index on ingest
Map terms to record locations during ingestion instead of scanning when a query arrives
Locate before reading
Use the index to identify matching ranges first, then read only the required data
Native to Event Engine
Shares a unified data and compute path with filters, field search, and DQL queries
Streaming aggregation acceleration engine
As data is ingested, the system uses historical query patterns to identify workloads that benefit from acceleration and pre-aggregates data into small time windows. When a matching aggregate exists for the requested range, queries read it directly instead of scanning raw data.
Transparent acceleration
Existing dashboards and monitors require no changes; eligible metric and log queries automatically reuse aggregate results
Event-time aware
Aggregates by the timestamp carried in the data and handles late arrivals through ingestion and update mechanisms
Lower resource usage
Serves eligible high-frequency queries from streaming aggregates to reduce repeated raw-data scans and database pressure
Why GuanceDB 3.1
Supports a wide range of business scenarios
Different read clusters can be provided for different business scenarios, using different configuration schemes (high concurrency, offline tasks, etc.) and isolating each separately
Real-time queries
Batch reports
Business analysis
Data Mining
GuanceDB 2.0 The privatized version will continue to be served
FAQ
GuanceDB is the Guance data engine for observability workloads. This page covers Metric Engine, Event Engine, inverted indexing, streaming aggregation, and shared query access. Confirm component availability against the current deployment version and service specification.
Metric Engine is designed for time-series and PromQL-oriented queries. Event Engine is designed for field filtering and full-text retrieval across detailed logs, traces, RUM, and event records. Supported data types and component combinations depend on the deployed version.
No. Only eligible queries with a matching maintained aggregate use that path. Other queries still execute against raw data. Teams should validate eligibility with their actual dashboards and monitors.
Capacity, retention, concurrency, and elasticity depend on deployment topology, version, service specification, and quota. Use the current deployment documentation and a formal workload review instead of inferring a fixed result from the architecture diagram.
