A new open-source GIS written in Rust runs natively and in the browser, starts in a fraction of a second, and treats every button as a scriptable command. Four releases appeared in thirteen days. We read the code, tested RustGIS 0.4 against QGIS and plain Python, and found a young tool with an unusually solid core and some clear rough edges.

Most open-source desktop GIS share the same foundations: GDAL for reading data, PROJ for coordinates, Qt or a web view for the interface. RustGIS replaces almost all of that with code written in Rust. It reads GeoPackage, GeoParquet, FlatGeobuf, Shapefile, GeoTIFF and COG with its own readers, draws maps on the GPU through wgpu, and compiles the whole application to WebAssembly, so the same program runs at web.rustgis.app with nothing to install. GDAL and DuckDB become optional extras on the desktop rather than requirements.

The project comes from opengeos, the organisation of Qiusheng Wu, best known for the Python packages geemap and leafmap. Version 0.1.0 appeared on 12 October 2026, three more releases followed by 25 October, and the repository passed roughly 2,000 stars and 280 forks within its first two weeks.

Four releases in thirteen days

Everything is a command

The design decision that matters most for professional users is not the language. Every action in RustGIS, every ribbon button and menu item, is an engine command with an id and JSON parameters. Version 0.4.0 exposes 497 of them. The ribbon, the command line, the Python package, the AI assistant and external AI agents all call the same commands, so a workflow clicked together in the desktop app can be repeated from a script without translation.

The code is split into layered crates, each depending only on the layers below it. That is what lets the same engine run headless on a server, inside a Jupyter kernel, as a desktop app and in a browser tab.

Same terrain, two interfaces

RustGIS borrows its layout from ArcGIS Pro rather than QGIS: a ribbon with tabs ordered by workflow (Home, Data, Style, Edit, Analyze, View, Publish), a Layers pane on the left and context panes on the right. Here is the same Copernicus GLO-30 elevation tile over the Karkonosze mountains (Poland, Czech Republic) in both programs.

Copernicus DEM GLO-30, tile N50 E015 (© DLR e.V. 2010–2014 and © Airbus Defence and Space GmbH 2014–2018, provided under COPERNICUS by the European Union and ESA).

How it compares on paper

The RustGIS documentation includes its own comparison with QGIS and ArcGIS Pro. It is the developer’s description of their software, so read the RustGIS column as a claim.

The same page is unusually candid about where RustGIS falls short:

• Vector data is held in longitude/latitude; there is no full PROJ.
• PostGIS, MySQL and SQL Server are read-only and desktop-only.
• No versioned or multi-user editing; edits are not written back to databases.
• DWG, JPEG 2000, NetCDF and HDF need GDAL; the web app cannot write GeoPackages.
• Network datasets and advanced spatial statistics need the external tool suite or another GIS.
• Many features are first versions; there is no Python console inside the app.

What we measured

Claims of speed are easy to make, so we wrote a benchmark notebook that runs the same jobs on three engines: RustGIS 0.4.0 through its Python package, QGIS 3.34.11-Prizren through a persistent PyQGIS process (so QGIS starts once, as it does in the desktop app), and plain Python with GeoPandas, Shapely, NumPy and rasterio. Every engine reads the same files and writes the same outputs. Each case runs at least three times and we report the median. Shorter bars are faster; a tick marks the fastest engine.

Reference run on Windows, 16 logical cores, 33.6 GB RAM, RustGIS 0.4.0, QGIS 3.34.11-Prizren. DEM: Copernicus DEM GLO-30, tile N50 E015 (Karkonosze), 2,389 x 3,722 cells in UTM 33N. Absolute times depend on hardware; the ratios between engines carry over better.

What the numbers say

Starting RustGIS costs almost nothing. Loading the engine and creating an empty project took 0.15 s and 16 MB of memory, against 3.16 s and 169 MB for PyQGIS and 1.88 s and 122 MB just to import the Python GIS stack. It is the clearest confirmation of the project’s “fast and small” pitch, and it matters for scripts, notebooks and servers that start many short jobs.

Buffering slows down sharply at scale. Up to 10,000 features RustGIS keeps pace with QGIS and GeoPandas. From 10,000 to 100,000 its buffer time grows about 26 times (an exponent of 1.42, where 1 means proportional), against roughly ten times for the other two. The cause sits in the buffer step itself, not in reading or writing files, which suggests an algorithmic issue the developers can fix.

RustGIS chooses geodesic methods, and they are measurably different. Its buffers are built on the ellipsoid and its IDW uses great-circle distance, where QGIS works in map units. Interpolating 100,000 DEM-sampled points, the geodesic IDW was closer to the real terrain (RMSE 51.6 m against 55.0 m for QGIS, a gain of 6.1 %; small, but consistent). Measured against a true 5 km circle, its buffers are 0.29 % too small, against 0.57 % for QGIS’s planar buffers in UTM.

QGIS is hard to beat on raster work. With QGIS already running, its GDAL-based slope, hillshade and GRASS flow accumulation were the fastest in our tests. RustGIS’s slope time grows in step with raster size, so its raster engine has no scaling problem, but it ran five to seven times slower than GDAL at every size we tried. Its built-in slope matches QGIS on 99.9 % of cells; the differences sit only on the first cell next to nodata.

Drawing is fast, but RustGIS draws what you cannot see. RustGIS rendered 1,000 and 10,000 building footprints faster than QGIS. Zoomed into a 4 × 3 km window of 100,000 buildings, though, it took as long as for the whole area, while QGIS and Python only read the footprints in view. Rendering the DEM from a cloud-optimised GeoTIFF instead of a plain one made QGIS about 1.6 times faster and RustGIS only about 1.1 times, which suggests RustGIS is not yet taking full advantage of COG overviews.

Input, output and scripting are where it shines. RustGIS was the fastest of the three at writing an A4 map at 300 dpi, at reading and writing 100,000 polygons as GeoJSON and as GeoParquet, and at running the same small job 100 times from a script. A loop over QGIS’s command-line tool pays QGIS start-up on every call and took more than fifteen times as long.

The core is fast where Rust is expected to be fast: start-up, file input and output, scripting. The algorithms behind buffering, raster processing and rendering are still catching up.

Our reading of the benchmark

Try it in a minute

The quickest route needs no install at all: the web app at web.rustgis.app is the full program compiled to WebAssembly. On the desktop, winget install OpenGeos.RustGIS (Windows) or brew install --cask opengeos/rustgis/rustgis (macOS) installs the app and its command line. In Python 3.12 or later:

pip install rustgis
import rustgis
s = rustgis.Session(sample=True)
s.run("gp.run", tool="buffer", params={"input": "Cities", "distance": 100})
s.to_png("map.png")

The command line renders maps headless, and registers RustGIS as an MCP server so agents such as Claude Code, Cursor and VS Code can run GIS commands:

rustgis-cli render dem.tif dem.png
claude mcp add rustgis -- rustgis-cli mcp --sample

Where RustGIS stands

Three weeks after its first release, RustGIS is not a QGIS replacement and does not claim to be. It is a credible second architecture for open-source GIS, with a different set of trade-offs.

For the geospatial community, the more interesting question may not be whether RustGIS overtakes QGIS, but what it shows is now possible: a full desktop GIS, with layouts, 3D, cloud-native data and a scripting interface, built in weeks on a modern stack that runs equally on a laptop and in a browser tab. If its algorithms catch up with its architecture, RustGIS will be a serious option for lightweight and web-first GIS work.