Arc Live Demos: See Sub-Second Queries on Real Industrial IoT Data

Imagen de portada para Arc Live Demos: See Sub-Second Queries on Real Industrial IoT Data

Talk is cheap. Show me the code. Better yet, show me the database running at scale.

That's what we did. We built four live demos running on Arc, ingesting real Industrial IoT data right now, as you read this. No synthetic benchmarks. No toy datasets. Real vessels, real flights, real weather, real container metrics—all queryable in sub-second time.

Check out the live demos here

Why We Built This

When we launched Arc, we published ClickBench results showing we're 12x faster than TimescaleDB. People loved the numbers. But some asked: "Yeah, but what about real workloads?"

Fair question.

So we built four production-grade demos that run 24/7 on Arc:

  1. 🚢 Vessel Tracking - ~1000 ships in Singapore's Strait of Malacca, one of the world's busiest shipping lanes
  2. ✈️ Flight Tracking - ~200 aircraft over New York City, real-time ADS-B data
  3. 🌦️ Weather Tracking - Buenos Aires, London, Tokyo - temperature, humidity, pressure trends
  4. 📊 System Monitoring - The Arc container itself - CPU, memory, network, disk I/O

All running on a single Arc instance. All queryable. All showing query execution times.

What You'll See

Each demo shows you Arc's actual query execution time. Not round-trip network time. Not API overhead. The actual time Arc took to execute the SQL query on DuckDB.

Spoiler: Most queries complete in 8-15ms.

That's right. Milliseconds. On datasets with thousands of rows refreshing every 10-30 seconds.

Vessel Tracking Demo

This one's my favorite. Live AIS (Automatic Identification System) data from vessels moving through the Strait of Malacca. We're talking container ships, tankers, bulk carriers—massive vessels carrying the world's trade.

The demo:

  • Ingests position updates from ~1000 vessels
  • Stores latitude, longitude, speed, heading, navigation status
  • Updates every 30 seconds
  • Queries use QUALIFY ROW_NUMBER() OVER (PARTITION BY ship_id ORDER BY time DESC) = 1 to show latest position per vessel

Query time: ~12ms for 1000 vessels.

Click any vessel on the map to see speed, heading, and status. Watch them move in real-time.

Try the vessel tracking demo →

Flight Tracking Demo

Real ADS-B data from aircraft over New York City. If you've ever used FlightRadar24, you know how much data this generates.

The demo:

  • Tracks ~200 aircraft in real-time
  • Captures altitude, speed, heading, vertical rate, callsign
  • Deduplicates by ICAO24 transponder code
  • Updates every 30 seconds

Query time: ~10ms for 200 flights.

You can see commercial flights descending into JFK, private jets circling, helicopters hovering. All in Arc.

Try the flight tracking demo →

Weather Tracking Demo

Multi-city weather monitoring across three continents. Temperature, humidity, pressure—the kind of sensor data IoT platforms deal with daily.

The demo:

  • Polls OpenWeatherMap API every 5 minutes
  • Three cities: Buenos Aires 🇦🇷, London 🇬🇧, Tokyo 🇯🇵
  • Stores temperature, humidity, pressure, conditions
  • Interactive charts with city selector and time range filters

Query time: ~9ms for 36 data points (24 hours).

Select individual cities or compare all three. Switch between temperature, humidity, and pressure. Arc handles it without breaking a sweat.

Try the weather tracking demo →

System Monitoring Demo

We turned the camera on ourselves. This demo monitors the Arc database container running all the other demos.

The demo:

  • Collects metrics every 10 seconds via Docker API
  • CPU usage, memory usage, network throughput, disk I/O
  • Calculates derivatives for network/disk (bytes/sec, not cumulative)
  • Shows real spikes when demos get traffic

Query time: ~8ms for 360 data points (1 hour).

This is Arc monitoring Arc. Meta, but practical. You can literally see the database strain when multiple people hit the demos simultaneously. CPU usage spikes, memory climbs, network throughput increases. It's transparent.

Try the system monitoring demo →

The Stack

All demos run on:

  • Arc 25.11.1 (latest release)
  • Docker containers on a single VPS
  • Python ingestion scripts using MessagePack columnar format
  • Next.js frontend with custom SVG charts
  • Real APIs: AISStream.io, OpenSky Network, OpenWeatherMap, Docker Engine API

No mocks. No fixtures. Live data.

Query Execution Times

Here's what makes this interesting: every demo shows Arc's actual query execution time.

We initially measured full round-trip time (API route → Arc → back). That showed 900ms+. Why? Network latency. Serialization overhead. Next.js processing.

Then we looked at Arc's logs:

Query executed: 36 rows in 0.013s (wait: 0.000s)

13 milliseconds. That's the real number.

So we updated the demos to show execution_time_ms from Arc's response metadata. Now you see the truth: 8-15ms for most queries.

That's DuckDB doing what DuckDB does best—analytical queries at blazing speed.

Why This Matters

These demos prove three things:

1. Arc Handles Real Industrial IoT Workloads

Vessel tracking alone generates thousands of position updates per minute. Arc ingests, stores, and queries this data without choking. No custom indexes. No schema gymnastics. Just SQL.

2. Sub-Second Queries at Scale

Every demo runs sub-10ms queries. On live data. With automatic time-based partitioning. Arc doesn't just claim to be fast—you can see it.

3. Standard SQL Works

No proprietary query language. No learning Flux or PromQL. Just SQL:

SELECT ship_id, latitude, longitude, speed, heading
FROM vessels_tracking.ais_data
WHERE time > NOW() - INTERVAL '5 minutes'
QUALIFY ROW_NUMBER() OVER (PARTITION BY ship_id ORDER BY time DESC) = 1
ORDER BY time DESC
LIMIT 1000

That's it. DuckDB SQL. Window functions. CTEs. Everything you already know.

What We Learned Building This

Docker API disk I/O is tricky. Initially, disk read/write showed 0 bytes. Why? We were checking for capitalized 'Read'/'Write' in the API response, but Docker returns lowercase 'read'/'write'. One .lower() later, fixed.

Derivative calculations matter for cumulative metrics. Network and disk stats are cumulative counters. Showing cumulative bytes is useless—it only goes up. We calculate (current - previous) / time_delta to show bytes/sec. Now you can see actual throughput.

Line chart rendering needs sorted data. When we launched the weather demo, Buenos Aires showed a connected line, but London and Tokyo showed disconnected dots. Why? We weren't sorting by timestamp before generating the SVG path. One .sort() later, fixed.

Browser timezone matters. Originally, we displayed timestamps in UTC. Users in Buenos Aires saw 3 AM when it was midnight local time. We switched to undefined locale parameter, letting the browser handle timezone conversion automatically.

These aren't edge cases. This is real-world software engineering.

Try It Yourself

All demos are live right now:

basekick.net/demos

Click around. Select different cities. Filter by time range. Watch vessels move. See flights land. Monitor Arc's own metrics.

Then ask yourself: could your current time-series database do this?

If you're running InfluxDB, TimescaleDB, QuestDB, or VictoriaMetrics—can you get sub-10ms queries on live data? Can you use standard SQL? Can you store data in Parquet files you own?

That's what Arc does. And these demos prove it.

What's Next

We're adding more demos. Got ideas? Let us know.

Right now, we're working on:

  • Equipment telemetry - Industrial sensor data (temperature, pressure, vibration)
  • Smart city sensors - Traffic, air quality, noise levels
  • Medical device monitoring - Patient vitals, equipment status

Each one will run live on Arc. Each one will show query times. No smoke, no mirrors.

One More Thing

Want to see how we built these demos? The ingestion scripts, data pipelines, and integration examples are coming soon to our awesome-arc repository.

https://github.com/Basekick-Labs/awesome-arc

We'll be releasing examples showing how to:

  • Ingest AIS vessel data with Python and WebSockets
  • Calculate network throughput derivatives from cumulative Docker metrics
  • Build real-time dashboards with Arc's query API
  • Handle high-cardinality IoT data at scale

Stay tuned—we're packaging it all up for you to run yourself.


Try Arc: https://github.com/Basekick-Labs/arc

Try the demos: basekick.net/demos

Questions? Discord | Twitter | LinkedIn

Let's build something.

Ready to handle billion-record sensor workloads?