Tile38
An in-memory geolocation data store, spatial index, and realtime geofencing server.
What is Tile38?
Tile38 is an open-source, in-memory geolocation data store and spatial index designed for real-time geofencing and location-based queries. It serves as a high-performance server for managing and querying geospatial data with support for multiple object types like points, bounding boxes, and GeoJSON. The project solves the need for efficient, real-time spatial data processing in applications requiring location tracking and boundary monitoring.
Developers and engineers building real-time location-based services, such as fleet tracking, asset monitoring, ride-sharing apps, and IoT spatial analytics. It's also suitable for those needing a lightweight, high-performance geospatial database with Redis protocol compatibility.
Developers choose Tile38 for its real-time geofencing capabilities, support for multiple geospatial object types and protocols (HTTP, WebSockets, Redis RESP), and in-memory performance with optional persistence. Its interoperability with existing Redis clients and tools reduces integration overhead compared to specialized spatial databases.
Overview
Real-time Geospatial and Geofencing
Use Cases
Best For
- Real-time geofencing applications like monitoring vehicles entering or exiting virtual boundaries.
- Building location-based services that require efficient spatial queries (e.g., nearby points, intersections).
- Managing and querying diverse geospatial data types including GeoJSON, Geohashes, and bounding boxes.
- High-performance spatial indexing for IoT or mobile apps with low-latency requirements.
- Integrating geospatial functionality into existing systems using Redis-compatible clients.
- Implementing leader/follower replication for high availability in distributed geolocation services.
Not Ideal For
- Applications focused primarily on non-geospatial data or requiring complex relational joins and transactions.
- Projects with datasets exceeding available RAM, as it's an in-memory store with optional persistence.
- Systems needing automatic horizontal scaling or built-in sharding for massive throughput beyond single-node limits.
- Use cases demanding strict ACID compliance for multi-object transactions or advanced analytics like full-text search.
Pros & Cons
Pros
Supports live boundary monitoring with the FENCE keyword, webhooks, and pub/sub channels for instant notifications on object movements, as demonstrated in the geofencing animation and examples.
Offers HTTP, WebSockets, Telnet, and native Redis RESP protocol, making integration easy with various clients and existing tools, including compatibility with most Redis client libraries.
Stores and queries multiple geospatial types like lat/lon points, bounding boxes, GeoJSON, and Geohashes, providing flexibility for different location-based applications.
In-memory architecture with spatial indexing ensures low-latency searches for methods like Nearby, Within, and Intersects, ideal for real-time applications such as fleet tracking.
Cons
As an in-memory database, data size is constrained by RAM, and while optional persistence exists, it may not efficiently handle terabyte-scale datasets compared to disk-first systems.
Lacks built-in support for complex analytics, full-text search, or advanced query languages beyond basic spatial operations and field filtering, which might require external tooling.
Replication is provided for high availability, but horizontal scaling or automatic sharding isn't natively included, requiring custom setup for distributed deployments.
Frequently Asked Questions
Related Projects
S2 geometryS2 geometry library in Go
mbtileserverBasic Go server for mbtiles
geoosA library provides spatial data and geometric algorithms
osmGeneral purpose library for reading, writing and working with OpenStreetMap data
Found a gem we're missing?
Open-Awesome is built by the community, for the community. Submit a project, suggest an awesome list, or help improve the catalog on GitHub.