Edge-Cloud Integrated Solution

Validated vehicle-side benchmarks (test hardware: Qualcomm 8295 automotive-grade SoC):

• Idle: 0–1% of one CPU core
• 350,000 points/s: ~3% of one core (0.75K DMIPS), ~132MB memory
• 700,000 points/s: ~5.7% of one core (1.425K DMIPS), ~135MB memory
• 800,000 points/s: <10% CPU, <300MB memory (with compression enabled)
• Peak CPU: never exceeds 15%

In Li Auto's production deployment, memory is configured at roughly 100MB (case study). Resources can be capped via database config and OS-level limits, and a monitoring API exposes CPU and memory in real time. Heavy analytical queries are time-sliced and auto-aborted when they would push CPU too high, so navigation and cockpit apps stay responsive.

Vehicle bus CAN data compresses 30–40× versus traditional ASC files. Millisecond signal data shrinks an additional 30–50% on top of the customer's existing compression. On-vehicle logs compress to roughly 1/30 of the raw log size — about 50% smaller than traditional compression algorithms. In Li Auto's deployment, cloud storage cost dropped to about 20% of the prior solution and upload bandwidth was cut by over 50%, saving tens of millions in cumulative cloud costs (case study). Compression strategy is per-table — high-frequency telemetry and cold logs can use different codecs.

Three layers of reliability:

• Custom export policies: schedule uploads by network state, table priority, or business rule. Files spool locally when offline and resume from the breakpoint after recovery.
• Per-table WAL: enable WAL on critical signals so writes survive a crash. Underlying log-structured storage keeps data on disk, not memory only.
• Power-loss aware: a system hook flushes data to disk before shutdown. File-level integrity checks plus retry and supplemental upload guarantee eventual consistency.

Two timestamps per row: the wall-clock time supplied by the writer (which can jump if RTC or GPS corrects) and a monotonic uptime timestamp that only increases. The cloud joins them in SQL to reconstruct a consistent timeline. At ingestion, timestamps from different ECUs are normalized against a chosen reference (typically GPS or NTP), so cross-domain traces align on the same axis.

Yes. The vehicle-side database ships a full SQL engine with low-overhead point queries and supports user-defined functions for custom business logic. Common patterns:

• Cloud-issued queries: push an SQL query down to the vehicle, run it on raw local data, return only the result — keeps PII on the vehicle and cuts upload volume.
• Streaming alerts: window functions (sliding/tumbling) detect consecutive anomaly conditions for fault diagnosis. The same stream engine runs at the edge and in the cloud.
• Rule-based anomaly detection: configure detection rules locally; matched events trigger automatic upload with the surrounding data window.

• OS: Android (validated in Li Auto's production fleet across Android versions), Linux, macOS, ARM edge devices. Written in Rust — any POSIX platform Rust supports is reachable.
• Protocols: MySQL, PostgreSQL, JDBC, Prometheus Remote Write.
• Visualization & ops: Grafana data source, native logcat collector for Android.
• Vehicle ↔ cloud: same database core on both ends — vehicle-side files are read directly by the cloud, no secondary write needed.

See the Integrations Overview for the full list.

Edge devices (including vehicles) are licensed by device count. The cloud side is licensed per node.

End-to-end savings come from three places: 30–40× compression cuts storage and bandwidth; vehicle-side aggregation removes the need for separate stream-processing engines like Flink in the cloud; and the vehicle-cloud isomorphic architecture skips the secondary write into cloud storage. Li Auto's deployment (case study) dropped cloud storage cost to about 20% of the prior solution and cut upload bandwidth by over 50%.

For a tailored quote, contact us.

Vehicle-side migration cost is generally low: GreptimeDB supports a wide range of open protocols and offers edge-optimized ingestion paths for high-throughput telemetry. The cloud side uses standard SQL, so existing analytics and BI tools connect directly. Overall migration cost is manageable, and typical PoC timelines run 1 to 3 months — the exact effort depends on the specifics of the customer's existing solution.