---

Features

• Fast
  Transferring an MBTiles file is faster than transferring millions of tile images when loading them onto USB stick, mobile device, or when transferring over a network. The trade-off in database access versus filesystem access when using MBTiles is, in our experience, negligible.
• Offline
  Because MBTiles files are self contained, they can be used without an Internet connection.
• Compatible
  Images are stored as blob data, so tiles can be read by most SQLite clients. There are many implementations of MBTiles from different organizations -- notably TileMill, TileStream, Arc2Earth, TileStache, and MapBox for iPad.
• Open
  MBTiles is an open-source specification. The specification text itself requires attribution, but there are absolutely no restrictions or requirements placed on implementations.

FAQ

Am I locked into MBTiles?

Of course not. You can always turn an MBTiles file into a directory of normal images by using mbutil. MBTiles is a very simple SQLite schema for storing normal images: it's not complex or proprietary.

Do you need a server to read MBTiles?

You'll either need a server, or be using the tiles on a device like an iPad. All that a server needs to do is pull individual tiles out of an MBTiles file and serve them to your browser: browsers aren't capable of reading the SQLite format that defines MBTiles files.

Do people download an MBTiles file when they visit my map?

No: MapBox Hosting stores an MBTiles file and serves individual tiles from it. An average user will only consume a few megabytes of bandwidth from actively using a map. The full size of an MBTiles tileset, whether it's 10MB or 2GB, is never actually transferred unless the user wants to download it to use it in the MapBox iPad app offline.

Why shouldn't I just keep tiles on S3?

Originally we managed tilesets on S3, but came up with MBTiles because of the massive management and efficiency problems that this posed. S3 is extremely slow for transfering millions of tiny files because each file needs to be a separate request with lots of communication overhead. When you want to move tiles - for instance, in renaming a tileset from world-light to world there is no batch-rename: you need to rename every file individually. In our experience, operations like deleting tilesets, changing their name, and updating them were extremely slow given these constraints - often an overnight task.

For instance, the Geography Class tileset is 205MB as an MBTiles file, but 800MB when you export it into images files with mbutil.

Why shouldn't I just keep tiles on a hard disk?

Most filesystems are terribly inefficient for millions of small files, and MBTiles can constitute a massive space savings, just by managing them better. Copying files - which requires building a filesystem node - tends to be very slow, and high zoom levels can run against inode limits - from which there is no recourse.

You can compress tilesets by linking similar tiles together - for instance, all blank blue tiles for sea area can be the same image. MBTiles makes this optimization internally and keeps it consistent even if you move the tileset around. Doing this with symlinks and other filesystem constructs is difficult or impossible across systems.

Example

Download the Haiti Terrain Grey tileset. Then, open the MBTiles file in the sqlite client.

sqlite3 haiti-terrian-grey.mbtiles

Next, run this SQL statment.

SELECT * FROM tiles WHERE zoom_level = 5;

This displays a row for each tile on zoom level five.

5|8|17|????
5|8|18|????
5|9|17|????
5|9|18|????
5|10|17|????
5|10|18|????

The ???? characters represents PNG images stored as blob data.