I haven't spent a lot of time looking into it. But the last time I looked at commonly-used vector tile formats, the one I found was clunky to generate/parse.
(And/or, maybe I just missed the right one. Please correct me if there is something out there that is clean and simple -- and has common library support.)
If you want to distribute sets of tiles to people, PMTiles is the best container format as you can just throw the file on hosting that supports HTTP Range requests (e.g. S3) and add the appropriate plugins to your client library. If you have to support clients which can't do the range requests from pmtiles, you can throw a thin layer in front of it to turn HTTP z/x/y requests into the pmtiles range requests.
There are no good file formats for distributing minutely updates of tiles but there's no need for this. If you are keeping your tiles up to date up to the minute you have a reasonable internet connection and you can just download individual tiles instead.
I just browsed the spec again (https://github.com/mapbox/vector-tile-spec/tree/master/2.1) -- I didn't have as bad of a reaction as I did the first time I looked at it.
I guess the idea of using (Google) protobufs for the "packaging" and then a super tight, custom, byte-encoded format for drawing commands seems... weird to me. But, honestly, it probably makes sense.
IMHO maintaining a large number of files on disk (be it 16m or 1.5b) should be a non-starter (not to mention that zipping them to slightly reduce the count removes one of the benefits of having them in the first place). A database makes sense - as does SOC between generation and distribution if it brings benefit - but immediately writing off SQLite because of write performance[1]? Similarly the arguments against pmtiles feel outdated and ignorant of the developing nature of the protocol (appreciate it's a 2yo post!).
OSM deciding on a format here has potential to significantly shape things to come. Hopefully Paul has progressed his thinking a bit since this was written.
I'm assuming the requirement is not really to build a single .mbtiles file, but to have some way for a process to serve the correct tile when given a z/x/y tuple.
The situation Paul is addressing is one unique to OpenStreetMap itself, which is minute-level updates of a global scale tileset. This is a use case pmtiles is designed explicitly not to address, where using a database is a better fit.
Which is to say, distribution of OSM data feels like a large part of the process. Of course there are various bottlenecks / considerations around edits / writes, but in practice surely reads are the bigger vector. I wonder how many OSM-external use cases rely on "minutely" updates or need the full fidelity of the raw data source. Feels like there is a solid case for providing less frequent (hourly, daily?) official updates via official "single-file" formats that could be widely distributed to the benefit of all, and e.g. allow OSM to loosen up their hot-linking policies and ensure continued investment in the chosen protocols.
But mainly I was questioning how a somewhat proven format like SQLite, with its many benefits (interoperability, distribution, etc.), would be so easily dropped from consideration without even a test having been run. Just my thoughts of course!
The key distinction is "official" - the only "official" data product of OpenStreetMap are its XML and PBF data dumps at planet.openstreetmap.org. The frequently-updated tiles you see on osm.org are "quasi-official", they're created by a separate project called OpenStreetMap Carto. These tiles have a special status within the OSM ecosystem for historical reasons; by virtue of OSM being map data, it should probably show something for human eyeballs on the website.
The design goals of OSM Carto are to show feedback to map editors; the linked vector tiles project is intended as a successor, or at least complement, to OSM Carto. The consumption of the tiles by third-party sites is a side-effect tolerated by OSMF; the general consensus within OSM seems to be that a consumable tile service for third parties is outside the scope of the project.
Definitely not in a position to question the status quo, let alone the OSM community consensus. Other than to say that - even if the focus is currently on internal software / editors alone - it still feels like a massive opportunity. And one that aligns with a number of strategic goals of OSMF[1], specifically around efforts to grow the community, extend the core developer base (and more) ... by fostering a closer relationship between OSM data-derived products / the wider (non-editor) community.
Let it be known I love scope creep.
That's the challenge with the osm.org feedback map, you need to quickly update the small fraction of tiles that very recently changed, while hopefully not processing the remainder.