Logtide 0.8.0: Open-Source Observability with Browser SDK and MongoDB Support

Logtide 0.8.0: Browser Observability, MongoDB Support, and Golden Signals

Logtide 0.8.0 introduces a dedicated browser SDK and native MongoDB support to its open-source observability stack. The release features engine-native P50, P95, and P99 latency aggregations across three different storage engines.

Why This Matters

Engineers often face a trade-off between the heavy operational overhead of Elastic clusters and the lack of deep observability in lightweight tools. Logtide 0.8.0 addresses this by providing high-fidelity frontend tracking and multi-engine storage flexibility without requiring complex infrastructure management. By automating Core Web Vitals collection and session tracking, it bridges the gap between backend logs and real-user experience in a GDPR-compliant, self-hostable package.

Key Insights

• Browser observability via @logtide/browser captures LCP, INP, and CLS metrics using the web-vitals library (2026).
• The @logtide/reservoir engine now supports MongoDB 7.0, utilizing native time-series collections for high-volume data storage.
• Golden Signals implementation provides P50, P95, and P99 latency metrics using engine-native functions like percentile_cont and quantile.
• Recursive CTEs in TimescaleDB implement index skip-scans, reducing high-cardinality query times from minutes to milliseconds.
• Smart project selectors utilize a new data-availability API to filter dashboard views based on actual telemetry presence.

Working Examples

Configuration for the MongoDB storage engine in reservoir.config.ts

export default createStorageEngine('mongodb', { uri: 'mongodb://localhost:27017/logtide', authSource: 'admin', })

Practical Applications

• Frontend error tracking: Mapping minified stack frames to source code via CLI artifact uploads. Pitfall: Capturing sensitive data; Logtide strips query params and input values by default.
• High-performance querying: Using Recursive CTEs on TimescaleDB to implement index skip-scans for distinct service lookups. Pitfall: Full table scans on high-cardinality fields; mitigated by Logtide’s query optimization.
• Resource-efficient monitoring: Utilizing pre-aggregated rollups like metrics_hourly_stats for instant dashboard loads. Pitfall: Heavy COUNT operations on high-volume projects; bypassed using countEstimate.

References:

• https://dev.to/polliog/logtide-080-browser-observability-mongodb-support-and-golden-signals-87i
• https://logtide.dev
• https://logtide.dev/docs