Hacker News Reader

Comment by fleitz | Hacker News Reader

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

http://wiki.postgresql.org/wiki/Whats_new_in_PostgreSQL_9.1#...

View on HN

Founder of Parallel Universe here.

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.

E-mail us and we'll gladly send you a trial version.

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.

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.

Reply on news.ycombinator.com