The Problem: Renewable Energy Systems and Financial Modeling at Scale

The renewable energy transition hinges on rapid property assessment. Traditional solar site evaluation requires manual surveys, roof inspections, financing and months of back-and-forth between buyers and installers. This delays projects, inflates costs, and stalls distributed energy resource (DER) deployment. At StationA, we faced a fundamental question: How can we automate property evaluation for renewable energy for hundreds of thousands of sites on-demand and en-masse. To answer this question, we built our evaluation platform on PostGIS, Elastic, and Kubernetes.

Why Consolidating into a Single System Would Not Scale:

PostGIS is a versatile and complete spatial database. While it excels in multiple spatial operations, it is optimized for transactional consistency, not quite for serving millions of reads to thousands of concurrent users. As our operations grew, we realized that a single, all-inclusive data storage system centralized around PostGIS would not scale. Thus emerged the two-layered data architecture.

The Two-Layer Architecture:

Layer 1: PostGIS (Authoritative Source)

PostGIS powers our portfolio enrichment engine (Autoport) where business logic lives. It stores parcel and building geometries of addresses being modeled with ACID guarantees. When new properties enter the platform, PostGIS ensures consistency across related records. Solar system packing, performance modeling, cash flows and financial models produced by our modeling engines are stored in PostGIS for its strong relational and transactional guarantees.

Layer 2: Elasticsearch (Read & Write-Optimized Feature Store)

Garden, our ETL pipeline running on Kubernetes, streams GeoJSON features from multiple sources (Regrid parcel data, weather APIs, public DER programs, hosting capacity maps) and seeds them into Pythagoras, our Elastic-backed geospatial feature store. Here, geometries are indexed as geo_shape documents, denormalized for read speed. Properties are immutable, replicated across nodes, and optimized for retrieval. Keeping this voluminous market intelligence data up to date is a key business requirement. Thus, the Elastic-backed geospatial feature store architecture allows for high-throughput writes and zero downtime updates.

While PostGIS stores input and modeled data for specific addresses in user portfolios, the Elastic feature store houses the universal set of all available data for all possible addresses in our total addressable market.

Trading Complexity for Scale

The two-layered feature store might look excessive for this kind of problem. However, rather than over-engineering PostGIS to handle web-scale reads, or taxing Elasticsearch with complex transactions, we let each tool excel in their own habitats:
- PostGIS: Complex spatial analysis, transactional safety, business rule coordination
- Elasticsearch: Horizontal scaling, millisecond queries optimized for high velocity concurrent reads and writes

The separation also enables independent scaling.

Harmony with GeoJSON and Vector Tiles

When business users interact with the map-view of the app, the front-end fires off a series of queries to services running against PostGIS and Elastic where specific layers are split and stored in a predetermined manner. PostGIS returns results in GeoJSON format and Elastic in MVT (Mapbox Vector Tile) format. When a user pans across a map, the browser requests tiles at specific zoom levels. Pythagoras receives the request, executes an Elasticsearch search_mvt query, and returns only the features intersecting that tile boundary. We re-encode the tile using the layer ID as the layer name, then stream it to the browser. The result: users interact with maps of 100k+ properties smoothly, because we're not sending all 100k features, just the geometries visible in each tile at that zoom level.

Lessons Learned on This Journey

Optimizing a single transactional database to perform analytical queries is not a high-return path. Engineering teams are better off separating their geospatial feature stores across different database systems as their scaling needs evolve. Elastic is a strong FOSS contender for high velocity reads and writes. Although the number of spatial operations and geometric representations might be limited when compared to PostGIS, it makes up for it with extremely fast query performance.

The Three-Layer Architecture: Looking Ahead

As our business needs expand further, we are faced with yet another fork in the road. While we store business critical, transactional data in PostGIS and voluminous market intelligence data in Elastic, we are now challenged with a need to store and render numerical and analytical outputs of the modeling engine. Meanwhile, the landscape of cloud-native geospatial has emerged and matured during the last few years in considerable ways. Thus, we are designing a three-layered architecture with cloud-native, range-read-friendly files on blob store as the third layer. When organized in a STAC-compatible manner, these files open up multiple avenues in which this analytical data can be discovered and queried.