In general, your first reaction would be “Do we really need something new? Not Invented Here syndrome”, and you may be right, most of the time.

So let’s see why we need a new database.

Use case

Take 10,000 geo points. Put them in the database. Easy.

Once every 10 seconds, move the 10,000 points around. This requires 1,000 updates per second.

Now make those 10,000 points 10,000 mobile users whose app is showing what’s around them. That’s another 1,000 updates per second to store their ‘viewport’.

At this point, you’re wondering if your database can do 2,000 updates/s.

Now let’s notify users when other users are moving around or new users appear, or existing users disappear from the map. If each user is within reach of 10 other users, we’re talking 1,000 geo queries per second to find who we should show, 1,000 notifications to answer the moving points, and 10,000 change notifications per second to notify those affected by your own move.

But you want to send differences only, you don’t want to send what hasn’t changed. So instead of 1,000 geo queries, you should do 2,000: one before, and one after each move, to compute and send the difference.

That’s a lot to handle for a database, it’s definitely going to cost a lot. Actually, there are many more reasons to not use a geo-capable database in this context.

So you’ll have to implement all this stuff yourself and handle corner cases (like when your server is restarted and all your data is still in the database).

With the launch of Geeo.io, that is “Not Invented Here”.

A more concrete example

The 10,000 points are 10,000 mobile users with an app built with Geeo. They want to see who’s around them in real time, and they’re all moving. Maybe the app will even send their location in the background when it’s not active.

And they can send a message to users near their position to chat.

Now add Points of Interest. They’re fixed points, added to the batch of notifications sent to users as they move around… say restaurants and bars.

Your users are now walking/driving, seeing bars, restaurants, plus other users of the app.

Maybe a user could create a geo event “who’s up for a beer” around his position, and other users close-by will get the event.

Let’s say you want to collect precise data about people entering/leaving the vicinity of each restaurant. You’d use ‘air beacons’ as we call them. Set a beacon at the bar’s location, and when someone enters/leave the area, your backend is notified and can produce actionable statistics about venues.

Use your statistics to reach out to restaurants and bars owners, with precise historical user count in their area.

Next, you can easily tell your backend to count users in the area of each venue and to trigger a new geo event sponsored by the place owner, a geolocated one: buy one beer, get one free… And Geeo will inform those users in the vicinity of the event.

All in real time. And it scales to tens of thousands of connected users, on a single server instance.

You couldn’t do any of that easily with any existing database.

That’s why we created Geeo.io and it’s in Beta now.

Come talk with us on HN here…