Skip to main content
Question

Error writing to large Geopackages

  • March 17, 2026
  • 4 replies
  • 69 views
knutos
Contributor
Forum|alt.badge.img+8

I am exporting a large dataset to Geopackages divided into municipality, county and nationwide datasets. Only for some of the largest ones I get errors like this: 

2026-03-14 21:22:05|3087.0|  4.4|ERROR |OGCGEOPACKAGE writer: sqlite3_exec(DETACH DATABASE "temp_rtree_48b1c18db46d5df6f87d84127b4186ce") failed: database temp_rtree_48b1c18db46d5df6f87d84127b4186ce is locked

As far as I can see, the produced geopackage works fine and the content is complete. But an additional file is left together with the zipped geopackage file.

The full file name of the extra file is something like Basisdata_0301_Oslo_25832_FKB-Gronnstruktur_GPKG.gpkg.tmp_rtree_bunnsjikt.db. Have anyone else seen this? Could this be related to some kind of size limitation of the Geopackage/SQLite format? Are there any workaround or solution? The FME version is 2024.2.3. 

    4 replies

    knutos
    Contributor
    Forum|alt.badge.img+8
    • knutosContributor
    • Author
    • Contributor
    • March 18, 2026

    I found that this issue is related to spatial indexing on large geopackages. If I turn spatial indexing off, the error does not occur.

     

    crystalwang
    Safer
    Forum|alt.badge.img+21

    Hi ​@knutos,

    Thank you for posting on the FME Community, and glad you found the spatial indexing workaround in the meantime!

    It seems like this is a known issue with to our development team (FMEENGINE-84487), and it has resolved in FME Form 2025.0+. Could you try upgrading and let us know if that clears it up?

    Hope this helps!

    ctredinnick
    Supporter
    Forum|alt.badge.img+20
    • ctredinnickSupporter
    • Supporter
    • April 14, 2026

    This was a bug in FME2024 I remember reporting. The workaround was to separate the writers and feature types. ie if you have one feature writer, writing two tables to gpkg, then when it starts writing the second table it will run into its own lock from the first table  if the feature count is high enough (~100000 features).

    knutos
    Contributor
    Forum|alt.badge.img+8
    • knutosContributor
    • Author
    • Contributor
    • April 14, 2026

    Hi ​@knutos,

    Thank you for posting on the FME Community, and glad you found the spatial indexing workaround in the meantime!

    It seems like this is a known issue with to our development team (FMEENGINE-84487), and it has resolved in FME Form 2025.0+. Could you try upgrading and let us know if that clears it up?

    Hope this helps!

    Hi,
    Thanks for the information. This is a big data processing environment at one of our customers. Unfortunately upgrading FME is not an option right now. So I am not able to test that now. Anyway, using the spatial indexing workaround is satisfying.

      Community Stats

      32,470
      Posts
      123,347
      Replies
      40,634
      Members
      Terms & ConditionsCookie settingsAccessibility statement
      A product of
      Safe Software respectfully acknowledges that we live, learn and work on the traditional and unceded territories of the Kwantlen, Katzie, and Semiahmoo First Nations.