Run it on your machine.
One process, a SQLite file, and a small RESP2 interface. Keep your data on your own machine or VPS.
A SMALL ENGINE. A FAMILIAR INTERFACE.
Geospatial queries.
One SQLite database.
A native C++ engine, Redis-style commands, and a typed client.
Try the same engine here, compiled to WebAssembly.
A client, not SQL.
Add points and find nearby places with typed methods. The TCP and WASM clients share one interface.
Real SQLite. In your tab.
The C++ engine runs in a Web Worker. Queries never leave the browser. Reloading clears your changes.
Preparing the SQLite WebAssembly playground…
THE ENGINE, EXPLAINED
SQLite geospatial search, with a Redis-style API.
GeoSQLite stores longitude and latitude in SQLite and uses a 3D R*Tree index to find nearby points. Its native C++ engine supports radius searches and nearest results through a small RESP2 command interface. Applications can use the TypeScript client without writing SQL.
The browser playground runs the same C++ search and command handler compiled to WebAssembly. Paris and San Francisco contain synthetic sample points, not a live business directory.
Read the complete SQLite vs Redis benchmarkWhat should you know before using it?
Is GeoSQLite a drop-in replacement for Redis?
No. It implements a focused geospatial command subset, not Redis as a whole. The report compares specific workloads and explains where either engine was faster.
Can I self-host the engine on a VPS?
Yes. The native process uses a disk-backed SQLite database. Keep the unauthenticated TCP listener behind a trusted application boundary. Follow the VPS guide.
Does the playground upload my points?
No. Database queries and edits stay inside this tab’s Web Worker and disappear on reload. The street map requests external map tiles separately.
Is this a production-ready managed database?
No. This is an experimental open-source proof of concept without replicas, tenant authentication, multi-region routing or a production SLA.