tidwall

tidwall/tile38

Go MIT Data

Real-time Geospatial and Geofencing

9.7k stars
618 forks
active
GitHub +4 / week

9.7k

Stars

618

Forks

165

Open issues

30

Contributors

1.38.0 09 Jun 2026

AI Analysis

Tile38 is an in-memory geospatial database and real-time geofencing server written in Go that indexes and queries location data using spatial indexes. It is purpose-built for applications requiring geofencing, location tracking, and proximity searches—best suited for ride-sharing platforms, fleet management, location analytics, and IoT systems rather than general-purpose data storage.

Data Database Discovery value: 4/10
Documentation 8/10
Activity 9/10
Community 8/10
Code quality 7/10

Inferred from signals mentioned in the README (tests, CI, type safety) — not a review of the actual code.

Overall score 8/10

AI's overall editorial judgment — not an average of the bars above, can weigh other factors too.

geospatial real-time location-services spatial-indexing in-memory-database
Actively maintained Well documented MIT licensed Niche/specialized use case Production ready
Deep Analysis · Based on README and public signals
2w ago

Tile38: In-memory geospatial database with real-time geofencing, built on Redis-compatible protocol

Tile38 is a purpose-built, in-memory geospatial data store and spatial index server that provides real-time geofencing via webhooks and pub/sub. It targets engineers building location-aware applications — fleet tracking, delivery logistics, asset monitoring, proximity alerts — where low-latency spatial queries and live boundary notifications are required. It speaks the Redis RESP protocol, making it approachable for teams already familiar with Redis tooling. With ~9,700 stars, a Slack/Discord community, and a dedicated documentation site, it has meaningful traction in the geospatial backend niche.

Origin

Created in March 2016 by Josh Baker (tidwall), a prolific Go open source author. It predates widespread PostGIS-in-the-cloud offerings and filled a gap for lightweight, fast, standalone geofencing without heavy GIS infrastructure.

Growth

Growth was strongest in 2016-2019 as the 'Uber-ification' wave drove demand for real-time fleet and delivery tracking. Star velocity has slowed considerably — only 4 stars in the last 7 days as of mid-2026 — suggesting the initial discovery wave has passed. The project likely retains a loyal, stable user base rather than experiencing explosive new adoption.

In production

The project has a dedicated documentation site (tile38.com), official Docker Hub image, Homebrew formula, and a listed set of client libraries across multiple languages. A Slack and Discord community exist. These are consistent with real production usage. However, no specific named production deployments or case studies are cited in the README. Adoption not verified at named-company scale from available metadata alone, but community infrastructure strongly suggests active real-world use.

Code analysis
Architecture

Appears to be a standalone server binary written entirely in Go, with an in-memory spatial index persisted to disk. Likely uses an R-tree or similar spatial index internally. Supports leader/follower replication. Exposes Redis RESP protocol, HTTP, WebSockets, and Telnet interfaces. The single-process, in-memory design implies vertical scaling is the primary model.

Tests

README mentions a 'make test' target, suggesting a test suite exists, but coverage percentage and test depth are not documented in README.

Maintenance

Last push was 2026-06-09, approximately 18 days before the evaluation date — the project is actively maintained. Given the maturity of the codebase (10 years old), low commit frequency may reflect stability rather than neglect. Prometheus metrics support and Docker images indicate ongoing operational improvements.

Honest verdict

ADOPT IF: you need a lightweight, self-hosted geofencing server with real-time event notifications and low-latency spatial queries — particularly for fleet, delivery, or proximity use cases where Redis geo commands are insufficient and PostGIS is operationally heavy. AVOID IF: you require complex spatial analytics, multi-table joins, persistent horizontal sharding, or a fully managed cloud service with SLA guarantees — Tile38's in-memory single-instance model has hard limits there. MONITOR IF: your geospatial workload is growing and you are evaluating whether a dedicated spatial layer is justified, or if cloud-native managed geospatial services will cover your needs before you commit to self-hosting Tile38.

Independent dimensions

Mainstream potential

3/10

Technical importance

8/10

Adoption evidence

5/10

Risks
  • Single maintainer dependency: tidwall is the primary author; bus-factor risk exists despite community presence.
  • In-memory architecture limits dataset size to available RAM; no native horizontal sharding means vertical scaling is the ceiling.
  • Limited managed/cloud-native deployment options — teams relying on fully managed infrastructure may find operational overhead significant.
  • The geofencing-as-a-service market (Google, HERE, AWS Location Service) may reduce the addressable audience for self-hosted solutions over time.
  • Slow new star growth suggests limited new community inflow, which may reduce the pool of future contributors and long-term maintenance sustainability.
Prediction

Tile38 will likely remain a stable, maintained niche tool for teams with specific real-time geofencing requirements. Major category expansion appears unlikely given slow growth, but it is unlikely to be abandoned given its active maintenance and loyal user base.

0 found this helpful

Newsletter

Get analyses like this every Monday

Free weekly digest of the most interesting open-source discoveries.

Languages

Go
98.9%
Shell
0.5%
HTML
0.4%
Makefile
0.1%
Dockerfile
0.1%

Information

Language
Go
License
MIT
Last updated
1w ago
Created
126mo ago
Analyzed with
anthropic/claude-haiku-4-5

Stars over time

Loading…

Contributors over time

Top 100 contributors only — repos with more will plateau at 100.

Loading…

Similar repos

go-spatial

go-spatial/tegola

Tegola is a production-grade vector tile server written in Go that delivers...

1.5k Go DevOps
TileDB-Inc

TileDB-Inc/TileDB

TileDB is an embeddable C++ storage engine for dense and sparse...

2.1k C++ Data
tess1o

tess1o/geopulse

GeoPulse is a self-hosted, privacy-first location tracking platform that...

1.3k Java IoT
developmentseed

developmentseed/titiler

TiTiler is a Python framework for building dynamic raster tile servers using...

1.1k Python Data
opengeos

opengeos/GeoLibre

GeoLibre is a free, open-source GIS platform that visualizes and analyzes...

1.6k TypeScript Data
vs. alternatives
Redis with geo commands

Redis offers basic GEOADD/GEORADIUS queries but lacks native geofencing, real-time pub/sub on boundary events, or rich spatial search (Within, Intersects). Tile38 is more specialized for geofencing use cases; Redis is more general-purpose and better supported in managed cloud offerings.

PostGIS (PostgreSQL extension)

PostGIS is the dominant geospatial database solution with vastly richer spatial query support and mature ecosystem. Tile38 trades SQL expressiveness and complex polygon operations for in-memory speed and built-in real-time geofencing push notifications — different operational profile.

MongoDB with geospatial indexes

MongoDB supports 2dsphere indexes and $geoNear queries but does not provide native real-time geofencing notifications. Tile38 is simpler, lighter, and designed specifically for the geofence event model.

Turfjs/turf

Turf is a client-side/serverless spatial computation library, not a database. The two are complementary rather than competing — Turf for in-process geometry math, Tile38 for persistent, queryable, real-time spatial state.

Google Maps Platform / HERE Geofencing APIs

Commercial managed geofencing APIs eliminate infrastructure burden but introduce vendor lock-in and per-query costs at scale. Tile38 is self-hosted with no per-query pricing, making it attractive for high-volume or cost-sensitive workloads.