MobilityDB: trajectory data types inside PostgreSQL and PostGIS

Trajectories as a column type rather than a separate system

MobilityDB is described as an open source geospatial trajectory data management and analysis platform, and as a database management system for moving object geospatial trajectories, such as GPS traces. The mechanism is extension rather than replacement. It adds support for temporal and spatio-temporal objects to PostgreSQL and its spatial extension PostGIS, so a trajectory is a value in a column rather than a row format you parse outside the database. The primary language of the repository is C, and the benefits the README lists start with compact geospatial trajectory data storage, rich mobility analytics, big data scale and performance, and an easy to use full SQL interface.

The provenance and the governance are worth knowing, because they explain the design. MobilityDB is developed by the Computer and Decision Engineering Department of the Université libre de Bruxelles under the direction of Prof. Esteban Zimányi, ULB is an OGC Associate Member and a member of the OGC Moving Feature Standard Working Group, and the project is managed by a steering committee. It is compliant with the OGC Moving Features standards and has been adopted by the Open Source Geospatial Foundation as a community project. The last push to the repository was on 2026-10-19, and the recent releases are v1.3.1 and v1.2.2 from 2026-09-29 and v1.3.0 from 2026-05-01.

The requirement list is where the friction starts

The Requirements section is short and unforgiving, and it is the part to read before anything else. You need Linux, with the note that other UNIX-like systems may work but remain untested. You need CMake at 3.12 or newer. You need a C++17 compiler, for example GCC 7 or newer, Clang 5 or newer, or MSVC 19.14 or newer, and the reason given is that the polygon Boolean engine was migrated to a vendored Clipper2. You need PostgreSQL 16 to 19, and the build stops with an explicit error outside that range. Then PostGIS 3.0 or newer, GEOS 3.8 or newer, PROJ4 6.1 or newer, JSON-C, and the development files for all of them.

So the shape of the project is a compiled PostgreSQL extension with a native dependency chain. The top level of the repository shows the parts: the meos/ directory is the type library, mobilitydb/ is the SQL layer, pgtypes/ holds the PostgreSQL type support, there are vendored copies of clipper2/ and postgis/, an h3-pg/ directory, a pointcloud-pg/ directory, doxygen/ for the API documentation, cmake/ for the build files, contrib/, tools/, and docker/ for container builds. The presence of clipper2/ in the tree, alongside the requirement note, tells you the Boolean geometry work is done in-tree rather than delegated.

The README also gives an apt invocation for installing the build dependencies on a Debian-based system with PostgreSQL 16 and PostGIS 3.

apt install buil

The package list in that command is not spelled out in full, so the requirement list above is the more reliable thing to work from.

A Python path in, and a visual path out

The project gives you two ways to reach the data from outside SQL. PyMEOS provides database adapters to access MobilityDB from Python, supporting psycopg and asyncpg, so the same trajectory types are available from a Python process without a separate wire format. And a set of integration projects covers the display side, with MobilityDeck for deck.gl, MobilityDB-Leaflet for Leaflet, MobilityOpenLayers for OpenLayers and MobilityQGIS for QGIS, plus a MOVE plugin to display the result of MobilityDB queries directly in QGIS.

The visualisation group matters because SQL on spatiotemporal data is only as useful as the ability to see the answer. A query that returns a set of trajectories is a table of coordinates until something draws it, and these adapters mean the same query result can be rendered in a browser map or in a desktop GIS. The public transport group follows the same pattern with a different standard: MobilityDB-PublicTransport integrates with public transport standards such as GTFS and Netex, and MobilityDB-OpenTripPlanner integrates with OpenTripPlanner, which suggests MobilityDB is being used as the storage and analysis layer underneath existing routing tools rather than as a replacement for them.

Benchmark tooling and the BerlinMOD generator

There is a data generator and benchmark tool based on the BerlinMOD benchmark, which takes input data from Open Street Map and uses pgRouting to generate routes between pairs of source and target locations. That is a specific and useful choice: the generated data is real road network geometry rather than synthetic points, so a benchmark on it exercises the spatial predicates a trajectory workload actually hits, and the routes are produced by a routing engine rather than by interpolation. The generator lives in a separate MobilityDB-BerlinMOD repository, separate from the main tree.

The companion website for the Mobility Data Science book carries the datasets used in the book along with the scripts that load them into PostgreSQL and reproduce the use cases, visualisations and exercises, which is a practical way to get a non-trivial trajectory corpus into a local instance without inventing one. The book itself, Mobility Data Science: From Data to Insights by Mahmoud Sakr, Alejandro Vaisman and Esteban Zimányi, published by Springer in 2025, is where the README says you can find detailed explanations of MobilityDB and its use in various application scenarios.

There is also an extensive workshop repository illustrating various usage scenarios, and the project publishes pregenerated user and developer documentation, with a documentation generation section in the README for producing it locally.

Branches, releases and the version matrix

The branching model is stated plainly in the README. The master branch has the development of the next release, and the stable-major.minor branches have the patch releases of the corresponding major.minor release, with the complete list of releases linked from the repository. There is a mobdb_version.txt file at the top level that holds the version, and the versioning convention visible in the release list has the form MobilityDB v1.3.1, so the major.minor.patch scheme carries into the tag names.

For a deployment, that means choosing between the next release and a patched stable line, and the choice matters because a trajectory database is usually the store under a set of analyses rather than a scratch instance. The CI configuration runs against a matrix of PostgreSQL versions, which is visible in the build badge pointing at a pgversion workflow, and the coverage badge points at coveralls for the master branch. The two mailing lists are on the OSGeo list server, a user list for general questions about how to use MobilityDB and a developer list, and the README asks that general questions go to the user list.

Where MobilityDB is the wrong answer

Three situations point elsewhere. The first is a platform where PostgreSQL is not the system of record. MobilityDB's value is that trajectory analysis happens in the same SQL engine as the rest of your data, and if you already run a spatial warehouse, a time series store or a proprietary mobility platform, that value is much smaller. The second is a development environment that is not Linux, because the requirements name Linux and say other UNIX-like systems may work but remain untested, and the whole stack has to be compiled from source with a C++17 toolchain and PostgreSQL development headers. That is a real barrier for a developer who wants to try a query.

The third is a workload where the trajectory data is small enough to analyse in memory. The project lists big data scale and performance as a benefit, and the benchmark tooling is aimed at large corpora, so a modest dataset of GPS points is better served by a Python library and a notebook, where the iteration loop is seconds rather than a build and load cycle. The genuine alternative to compare against is a columnar store with a spatial extension, where trajectories are rows rather than a first-class type. The difference in approach is real: with a dedicated mobility type, the database understands trajectory as a value and can answer temporal and spatiotemporal predicates over it, while a columnar design leaves the temporal reasoning to your application code.

Editorial conclusion

MobilityDB fits a team that already runs PostgreSQL, has trajectory or moving object data, and wants to query it in SQL alongside the rest of the relational data rather than in a separate spatial or mobility platform. It does not fit a team on a PostgreSQL version outside 16 to 19, and it does not fit a Windows or macOS developer, since the requirements name Linux and say other UNIX-like systems may work but remain untested. Before you build it, read the Requirements section in full and check the pinned dependency versions, and decide which branch you want, since master carries the next release while the stable-major.minor branches hold the patch releases.

Frequently asked questions

Official sources

1. Issues
2. MobilityDB/MobilityDB on GitHub
3. Project website
4. README
5. Releases