It doesn't necessarily require a non-traditional backend, as you could design your backend using plain old rdbms. What does require a non-traditional design would be your app, however.
Not really, Postgres works fine for most of this stuff, and as of 9.1 without PostGIS
'nearby' means ordering your query using the <-> operator.
'meeting criteria' goes in the where clause.
For example to find interesting things nearby in postgres:
SELECT * from interesting_things as it where (it.A ='A' AND it.B ='B' AND it.C = 'C')
order by it.location <-> point '(current_lat,current_lon)' LIMIT 10
Some of the data sources of interest for location-based applications generate tens of millions of updates per second. I love PostgreSQL but it does not operate at that scale. The index locking alone would kill it even if you weren't touching disk.
Extremely high spatial ingest rates concurrent with queries requires different architecture and algorithms.
Sure, Postgres works great and it's not our competition. The idea is that you'll store all of your static stuff in Postgres, and all of your dynamic objects in SpaceBase. We've been approached by companies that need to track thousands of vehicles, each updating its location every second or so, and Postgres just couldn't handle it. For LBSs, SpaceBase complements Postgres.
Yeah postgres would fall down pretty fast on that workload without sharding, and it's the kind of ephemeral data that doesn't need ACID semantics.
Do you have a trial? Or other demo? I may be encountering those kinds of problems in the near future and would like to see whats out there. Right now Postgres is perfect for our workload but we've crafted the problem we're solving to avoid the realtime issue.
