Design Efficient GPS Trajectory Storage and Queries with MongoDB Time Series

Background

MongoDB 5.0+ provides native Time Series Collections, optimized for high‑volume timestamped data such as GPS trajectories. They retain schema‑free flexibility while adding storage and query optimizations specific to time‑series workloads.

Solution 1 – Time Series Collection (recommended)

Step 1 – Create the collection

db.createCollection("gps_timeseries", {
  timeseries: {
    timeField: "timestamp",          // required
    metaField: "metadata",           // optional, stores device‑level attributes
    granularity: "seconds"           // seconds | minutes | hours
  },
  expireAfterSeconds: 7776000        // 90 days TTL
});

Tip: Place common attributes (deviceId, driverId, licensePlate) in metadata to simplify aggregation. Choose granularity based on write frequency and query latency requirements.

Step 2 – Insert documents

// Rich document
db.gps_timeseries.insertOne({
  timestamp: ISODate("2023-10-27T08:30:00Z"),
  metadata: {
    deviceId: "truck-123",
    driverId: "driver-456",
    licensePlate: "京A12345"
  },
  location: { type: "Point", coordinates: [116.3974, 39.9093] },
  speed: 65.5,
  heading: 234,
  accuracy: 10,
  fuelLevel: 78.5,
  isMoving: true
});

// Simple record
db.gps_timeseries.insertOne({
  timestamp: ISODate("2023-10-27T08:31:00Z"),
  metadata: { deviceId: "truck-123" },
  location: { type: "Point", coordinates: [116.3980, 39.9098] },
  speed: 70.1
});

Core advantages

Storage optimization: Automatic columnar compression reduces disk usage by 50‑70 %.

Query performance: Indexes on timestamp and metadata fields are highly efficient.

Automatic bucketing: MongoDB groups measurements into internal buckets, accelerating aggregations.

TTL support: expireAfterSeconds removes stale data without external jobs.

Solution 2 – Traditional Collection (legacy or complex schemas)

Use when MongoDB version is below 5.0 or when the data model contains deeply nested structures that do not fit the time‑series model.

Document examples

{
  deviceId: "truck-123",
  timestamp: ISODate("2023-10-27T08:30:00Z"),
  gps: { type: "Point", coordinates: [116.3974, 39.9093] },
  speed: 65.5,
  heading: 234,
  extra: { temperature: 28, ioStatus: 1 }
}
{
  deviceId: "car-789",
  timestamp: ISODate("2023-10-27T08:30:00Z"),
  gps: { type: "Point", coordinates: [121.4737, 31.2304] },
  mileage: 12345.6
}

Optimization suggestions

Indexes

db.gps_data.createIndex({ deviceId: 1, timestamp: 1 });
db.gps_data.createIndex({ gps: "2dsphere" });

Sharding for large datasets

sh.shardCollection("db.gps_data", { deviceId: 1, timestamp: 1 });

Note: A compound shard key that includes the device identifier keeps a single device’s data on the same shard, reducing query scatter.

Comparison

MongoDB version: Time series requires >= 5.0; traditional works on all versions.

Storage efficiency: Time series – high (auto compression); traditional – lower, needs manual tuning.

Query performance: Time series – optimal with time + metaField; traditional – depends on indexes.

Development convenience: Time series – automatic bucketing and TTL; traditional – manual index and shard management.

Schema‑free support: Both allow flexible fields; time series enforces a structured metaField.

Aggregation: Time series includes built‑in optimizations; traditional relies on explicit pipeline design.

Recommendations

For write‑heavy workloads and time‑based queries, prefer the Time Series Collection .

For complex nested documents or older MongoDB versions, use a Traditional Collection .

Common query examples (Time Series)

Recent one‑hour trajectory

db.gps_timeseries.find({
  "metadata.deviceId": "truck-123",
  timestamp: { $gte: new Date(Date.now() - 3600*1000) }
}).sort({ timestamp: 1 });

Average speed for a time window

db.gps_timeseries.aggregate([
  { $match: {
      "metadata.deviceId": "truck-123",
      timestamp: {
        $gte: ISODate("2023-10-27T08:00:00Z"),
        $lt: ISODate("2023-10-27T09:00:00Z")
      }
    }
  },
  { $group: { _id: null, avgSpeed: { $avg: "$speed" } } }
]);

Latest point inside a geographic polygon

db.gps_timeseries.find({
  location: {
    $geoWithin: {
      $geometry: {
        type: "Polygon",
        coordinates: [[[116.3,39.9],[116.4,39.9],[116.4,40.0],[116.3,40.0],[116.3,39.9]]]
      }
    }
  }
}).sort({ timestamp: -1 });

Best practices

Store shared attributes (deviceId, driverId, etc.) in metadata for efficient aggregation.

Enable expireAfterSeconds to automatically purge data older than the retention period.

Even with time‑series collections, create indexes on metadata.deviceId and timestamp to support ad‑hoc queries.

Leverage schema‑free flexibility to add non‑core fields (speed, fuelLevel, temperature, etc.) as business needs evolve.

Monitor collection size and shard distribution in high‑volume deployments to avoid hotspots.

Conclusion

Preferred solution: Time Series Collection – efficient writes, fast time‑based queries, storage compression, and native TTL.

Schema‑free advantage: Allows flexible field extensions for diverse devices and changing requirements.

Index & aggregation: Proper index design, geospatial indexes, and aggregation pipelines remain essential even with time‑series collections.