Stop Duplicating Your GeoTIFFs in GeoServer: Use External GeoTIFF for Enterprise GIS

When building an enterprise GIS platform, storage architecture is just as important as application architecture. During the development of a raster management system for GeoServer, I discovered that every uploaded GeoTIFF was being stored twice—once in the SAN storage and again inside GeoServer's data directory.

At first, this seemed like a bug. In reality, it was the result of using the wrong GeoServer REST API endpoint.

This article explains why it happens, how to avoid duplicate storage, and which approach is best for enterprise deployments.

The Problem

Suppose your application uploads GeoTIFF files to a centralized storage location:

/data/raster_catalog/raster/
    sentinel_2_2025.tif
    landsat_5_2007.tif
    avnir_2008.tif

Your Node.js application then publishes the raster to GeoServer using the REST API:

await geoserver.put(
  `/workspaces/${workspace}/coveragestores/${fileName}/file.geotiff`,
  fs.createReadStream(rasterPath),
  {
    headers: {
      "Content-Type": "image/tiff"
    }
  }
);

After publishing, another copy appears:

/opt/geoserver/data_dir/data/workspace/
    sentinel_2_2025/
    landsat_5_2007/
    avnir_2008/

Now every raster exists twice.

For a few files this is harmless.

For hundreds of GeoTIFFs, especially those measuring several gigabytes each, this becomes a serious storage problem.

Why Does GeoServer Create Another Copy?

The endpoint

PUT /coveragestores/{store}/file.geotiff

is an upload endpoint.

When you send a TIFF stream,

fs.createReadStream(rasterPath)

GeoServer assumes you are uploading data that it should manage itself.

Internally it:

1. Receives the TIFF.

2. Copies it into its own data directory.

3. Builds the coverage store from the copied file.

Your original file is no longer used for rendering.

The Better Alternative: External GeoTIFF

If the raster already exists on the GeoServer machine, there is no need to upload it again.

Instead, publish it as an external GeoTIFF.

await geoserver.put(
  `/workspaces/${workspace}/coveragestores/${fileName}/external.geotiff`,
  `file:/data/raster_catalog/raster/${fileName}.tif`,
  {
    headers: {
      "Content-Type": "text/plain"
    }
  }
);

Instead of sending the TIFF, the application sends only its filesystem path.

GeoServer stores the reference and reads the raster directly from its original location.

No duplicate file is created.

Architecture Comparison

Using file.geotiff

Upload API
      │
      ▼
SAN Storage
      │
      ▼
GeoServer Upload
      │
      ▼
GeoServer Data Directory

Result:
Two copies of every GeoTIFF

Using external.geotiff

Upload API
      │
      ▼
SAN Storage
      │
      ▼
GeoServer references existing file

Result:
Single copy

Does External GeoTIFF Improve Rendering Performance?

This is a common misconception.

The answer is No.

GeoServer renders the raster in the same way regardless of whether the file is located inside its own data directory or in an external directory.

If both files are on the same storage device, rendering performance is essentially identical.

The difference lies in storage management, not rendering speed.

What Actually Makes Raster Rendering Faster?

If your goal is faster WMS rendering, focus on the following optimizations instead.

1. Cloud Optimized GeoTIFF (COG)

COGs support efficient partial reads and internal tiling, allowing GeoServer to access only the data required for the current map view.

2. Build Overviews

Generate image pyramids using GDAL.

gdaladdo -r average image.tif 2 4 8 16 32

GeoServer can then use lower-resolution versions when users zoom out, greatly reducing disk I/O.

3. GeoWebCache

Tile caching prevents GeoServer from rendering the same map repeatedly.

Frequently viewed areas are served directly from cache, improving response times significantly.

4. Fast Storage

Store rasters on SSDs or high-performance SAN/NAS storage.

Disk speed has a much greater impact than the choice between file.geotiff and external.geotiff.

5. JVM and GeoServer Tuning

Appropriate heap size, image cache settings, and connection pool configuration improve performance under heavy workloads.

Why External GeoTIFF Is Better for Enterprise GIS

For organizations managing hundreds or thousands of raster datasets, external GeoTIFFs provide several operational benefits:

• Only one copy of each raster

• Reduced storage requirements

• Faster publishing because no file copy occurs

• Easier backup and disaster recovery

• Shared storage can be accessed by multiple GeoServer instances

• Cleaner separation between data storage and application configuration

This architecture scales much better than allowing GeoServer to maintain its own duplicate copy of every raster.

Recommended Architecture

Client
   │
   ▼
Node.js Upload Service
   │
   ▼
SAN Storage (/data/raster_catalog/raster)
   │
   ▼
GeoServer External Coverage Store
   │
   ▼
Coverage
   │
   ▼
WMS / WMTS / WCS

GeoServer becomes a rendering service rather than a file storage system.

Final Thoughts

The file.geotiff endpoint is useful when GeoServer is expected to own and manage uploaded raster files.

However, for enterprise GIS deployments with centralized storage, using external.geotiff is the more scalable approach. It avoids duplicate storage, simplifies system administration, and fits naturally into modern spatial data infrastructures.

Although it does not directly improve rendering speed, it creates a cleaner, more maintainable architecture that is better suited for large raster repositories and long-term growth.