Platform Hunger Games
Picture this: you’re a small, scrappy geospatial start up with a dream. Maybe you want to map floods, or maybe quantify soil carbon. Maybe you want to count cars in a parking lot, who knows! Don’t let your investor’s dreams be dreams. Where are you going to get imagery, merge it with compute in order to deliver beautiful models and maps?
Five years ago, the landscape certainly looked different: at the time, Descartes Labs1 (now EarthDaily) was certainly still a strong option, and possibly the only viable one at the time. Planetary computer has just launched. Google Earth Engine (GEE), while it had launched much earlier in 2010, still did not offer a commercial license.
These days: while Microsoft has launched Planetary Computer Pro (pricing tbd), GEE is probably the most established commercial geospatial platform as it stands2. There is of course a final option: roll your own! Yes, writing GDAL is scary, wrangling AWS Batch/Lambda is scary, scaling compute and storage access is scary, and geospatial data engineers are expensive! However you may be surprised to find that under some conditions, this might be the most economical solution.
Earth Engine Economics
GEE pricing is quite interesting. We can see below that the ‘Professional’ plan costs a flat fee of $2000 per month.
But what on earth are EECU-hours?? From the page itself:
An Earth Engine Compute Unit (EECU) is a mechanism for representing an amount of instantaneous processing power. Earth Engine tracks the total computational footprint of tasks as a function of their EECU usage through time (EECU-seconds, EECU-hours, etc.). Because Google has many different types of processor cores, architectures, etc., EECUs are a useful abstraction for talking about computational power.
Got it, so EECU-seconds ~ cloud compute.
Usage costs themselves are displayed a little further down the page, so reading between the lines we can see that on the Professional plan $2000 you get $200 of Batch credits, and $40 of Online credits.
There is tiered pricing to take into account too: as you use more, the cost per EECUs drops:
Earth Engine Compute Units
The esoteric nature of EECUs make it very difficult for companies to estimate their potential usage costs. The GEE team itself appears unsure about exactly how to do this, at least in the general case. In the following examples, I’m going to run some experiments myself, but it should be noted that even for the same workload, EECUs costs can be highly variable due to caching and changes to the GEE backend. Nonetheless, if you look at Len’s comment here, it provides a workflow by which to estimate costs: run some sample workflows on a subset of tiles/tasks, and extrapolate.
In this particular case let’s look at what is likely a common use case: access to imagery for model inference. Unfortunately this workflow still can not be performed fully in GEE. Yes there is a ee.Model.fromVertexAi, but using it is quite challenging, particularly due to the limit on maxPayloadBytes
.
Typically in this particular workflow users will define imagery exports over areas, these will result in GeoTIFFs stored in a Google Cloud Storage (GCS) bucket, which will then be pulled for subsequent inference, rather than wrestling with the still experimental ee.Model.fromVertexAi.
I happen to be running a similar workflow for another project so here is what our export looks like:
Cloud mask using cloudscore+, and reduce to the median over 2024-01-01 - 2024-12-31.
Separate out each Sentinel-2 band, and export in its native resolution as
uint16
Export by MGRS tile, over the island of Java in Indonesia.3
Tally up the EECUs cost per MGRS tile. Remember an EECU-hour is $0.4. In this particular case the total cost works out to around $258.
I’ve plotted the results both in terms of cost per MGRS tile and cost per km^2:

Since Java represents about 0.1% of the worlds land-mass, excluding the Arctic and Antarctic, and I can’t really find this information anywhere else, I’m going to extrapolate the cost of a GEE-generated global annual composite. Taking into account the tiered pricing this results in a cost of around $1600004.
I’m sure that the folks at Google could easily optimize this export process to be at least four times as efficient, so let’s set a range for a global annual composite between $40000 - $160000. This is a lot of money, and remember, we have not paid for compute/inference yet!
A Rock and a Hard Place
So what are your alternatives? In the case of Sentinel-2, could you simply access the open data yourself. Of course this means paying data engineers to build and maintain your data pipelines. I happen to have the privilege of knowing several people who have built or maintained custom global geospatial inference pipelines. Based on the aggregate of the estimates given to me on total costs to run a model on every Sentinel-2 pixel in the world for a year, I’d estimate this value to lie in the range of $15000 - $350005, including compute/inference time.
So let’s make some simple assumptions, and see how this plays out:
It takes a Senior Data Engineer about 6 months full time to make a full imagery pipeline + inference pipeline.
It takes the same engineer about 3 months to set up an equivalent pipeline using GEE as the image provider.
Once set up, the GEE pipeline takes 0.1 FTE of the engineers time to maintain, while the custom pipeline takes 0.2 FTE.
Senior Geospatial Data Engineers are paid $160000 annually.
On the GEE professional plan, the company pays a membership of $2000 a month. The company pays the full membership each year (i.e no stop-starting).
The company runs global Sentinel-2 inference once a year.
Global inference costs around $40000 - $160000 on GEE, and $15000 - $35000 on the custom pipeline in terms of compute + data transfer/storage.
Running this simulation gives us the following plot:
Its interesting to note that except that even with these fairly generous assumptions: that my extrapolation is off by a factor of 4, that the custom pipeline takes double the amount of time to set up and maintain, the cost of running this process of GEE very quickly outstrips the cost of the custom pipeline. This tells us that GEE is fundamentally mis-priced: since it is essentially a premium on compute + storage that one must pay every time we wish to compute anything, as opposed to the cost of the custom pipeline where the price to set the pipeline up is amortized over time.
The Math ain’t Mathin’
So how should GEE be priced? Well for one, Google could stop charging both a membership AND for usage. How do our plots look in the case where Google drops the monthly membership?
Much better, as we’re reducing the cost per year by $24000. Although the custom pipeline still appears to be cheaper in a lot of cases over time. Let’s pull another lever: assume Google decides to drop usage based costs by 50%, what do our lines look like in that case?
While there certainly appear to be benefits in the first couple of years, GEE costs eventually eat these benefits up over the long term. Of course at this point we’re probably splitting hairs, and its unclear if geospatial companies plan on 5-year timescales anyway.
Conclusion
GEE is expensive, if you use it as an imagery pipeline. Of course the magic of GEE is that you can do so, so much with it. Want to train a pixel-wise harmonic regression and then train a random forest on top of your coefficients? You can do that. Want to do massive zonal stats computations? You can do that. Want to run Landtrendr, or CCDC, with a few lines of code? You can do that. Dynamic world runs and is available on GEE, as is cloudscore+ and countless other datasets. There is additionally also the community-maintained awesome-gee-community-catalog which contains an absolute treasure trove of datasets.
Every single dataset on GEE can be seamlessly overlaid/intersected with every other. This means you can easily ask questions like: “out of all the pixels in dynamic world which were forest in 2024, and are crop in 2025, which ones had the highest peak MODIS NDVI in 2025” in a couple of lines of code, and just let it run. No need to handle resampling, overlaying etc…
There is so much value in being able to perform these operations, and GEE makes it so easy. However, if we want geospatial companies to succeed on GEE, which I think Google does as this means more money in the long run: the current cost appears to be high.
My unsolicited advice to the GEE/Google team: remove the monthly membership costs, and reduce usage based costs by 25-50%, and you will be a much more compelling platform for companies.
The DL platform was my first introduction to the magic of geospatial data at scale. I’m truly grateful to Caitlin Kontgis who ran the science program at the time for giving me free, unfettered access to the platform. Fun fact: for a long time I apparently led the internal DL leaderboards on consumption for non-paying users.
This is pure speculation on my part. Feel free to correct me if you have evidence to the contrary!
Yes this is probably inefficient from a pure export perspective, we could at least do a full UTM zone as some of the MGRS tiles are smaller, but I find MGRS tiles are a handy unit of work for these types of workflows.
Extrapolating the Java test run (2.33 million EECU-s ≈ 646 EECU-hr) linearly to the entire ice-free land surface of Earth (~128.8 million km²) yields **≈ 627 715 EECU-hr**.
Applying the current tiered rates—$0.40 for the first 10 k EECU-hr, $0.28 for the next 490 k EECU-hr, and $0.16 thereafter—produces a total cost of **≈ US $161 600** (Tier 1 ≈ $4 000, Tier 2 ≈ $137 200, Tier 3 ≈ $20 400).
If you think this number is lower, I’d very interested to hear from you! If you think this number is higher, then you should probably have a look at how to optimize your pipelines :).
Hi Christopher, I really enjoyed reading this and was nodding along until the end when you addressed dataset availability. I think you're pointing out that Earth Engine gives users the ability to skip the initial ETL and just get straight to analysis and prototyping of workflows - something that's still time consuming with most other platforms. But your conclusion goes straight from acknowledging that capability to "Earth Engine is too costly".
If that's Google's secret sauce, so to speak, what value could we reasonably assign it? For the large majority of customers who I'd bet (citation needed) aren't running a global scale model, so aren't factoring compute of that size, I wonder if the ability to jump straight to piloting and prototyping an analysis with specific datasets has huge value. Then, they can decide if they want to run it in Earth Engine itself, or continue building an ingestion pipeline somewhere else.
For that kind of use case, I'd guess it's *not* too expensive, but your article proves it's missing a customer there, who *does* want to use Earth Engine for the full compute, but can more economically perform the work elsewhere.
Anyway, I'd be curious for a bit more of your thoughts on how the dataset availability you touch on at the end could or should factor into the equation here.
Hi Chris, awesome and timely post! Are the annual cloud costs baked into the 0.2FTE to maintain the custom pipeline?