Yes, lately I have noticed that always feels a bit cumbersome working with it. Where those built-in DBMS SQL or NoSQL?

Looks interesting, thank you. Have you used it yourself? If so how do you deal with queries like: 'my' private messages from a single user.

I also try to avoid ORM's but ditching them makes mapping to struct/objects cumbersome. How you deal with mapping joins in Go and node.js?

I find having results in object form for CRUD API's most of the time is unnecessary, and this is a lot of what happens and people use ORM's for.

When I do need the data in object form I use what is probably an unpopular method for a lot of people, that is I build a serialize/deserialize solution (or use one already built). It isn't hard in either node.js or Go. It can add some fragility into the codebase, however, depending how it is implemented. Frankly though, I like this because essentially this is what an ORM would do too, just an ORM would be trying to build the query, guess on keys, indexes etc and then still serialize and deserialize my data, which again may not be ideal because of generic choices it has to make.

Also, a fairly common pattern for CRUD APIs is I do not need to map the returned data into an object ever, I simply need a json object to return. And at least when using postgres I can use jsonb_agg and to_jsonb to help make life really easy. MySQL has similar json functions. When doing updates the submitted json data is used to build the query so there is no need to really have things in native object form.

Hopefully that all makes sense.

Does anyone recommend a good alternative which embraces the open source mentality so I am allowed to permanently store the data.

If you need an alternative, please consider MAPCAT. Our OSM-based public map portal is already live, and the map API is just about to be launched. For more info please check http://www.mapcat.com and http://try.mapcat.com

They have listed only alternatives that have a similar philosophy: https://mapzen.com/blog/migration/

Not so, unfortunately.

For example, while Mapbox use open source (OSM) tiles, other services - e.g. their search API - aren't open, as Mapzen's is(/was). Yet they are listed on that page by Mapzen as an alternative for Search.

There may be other such examples in that list.

I'm an engineer on Mapbox's search (geocoding) team, and our geocoding engine is actually open source: https://github.com/mapbox/carmen

Our data isn't, but as other commenters here have said, it's not currently possible to build a good geocoder with the open data available. We're constantly working to support open data efforts, but it's not there yet.

> For example, while Mapbox use open source (OSM) tiles, other services - e.g. their search API - aren't open, as Mapzen's is(/was).

The geocoding engine[1] powering the Mapbox Search API is open source, and has been since its inception in 2012. The same is true of the routing engine[2] powering the Mapbox Directions API (OSRM), and the engine used to create Vector Tiles[3] for the Mapbox Maps API, along with the engines powering most Mapbox APIs.

Non-open code at Mapbox is usually tightly coupled to our infrastructure or data processing pipelines, which would not be generally useful to the community at large. The useful bits of even this infrastructure code is also typically abstracted into generally useful libraries for community use, such as earcut[4], rasterio[5], tile-cover[6], and hundreds of other modules of all varieties.

  - [1] https://github.com/mapbox/carmen
  - [2] https://github.com/project-osrm/osrm-backend
  - [3] https://github.com/mapnik/mapnik
  - [4] https://github.com/mapbox/earcut
  - [5] https://github.com/mapbox/rasterio
  - [6] https://github.com/mapbox/tile-cover

I was aware of this, but the gp said

> embraces the open source mentality so I am allowed to permanently store the data

which pertains to data. So I was referring to data.

Yes you are right, please have look. I have updated the question text.