PostGIS setup & schema design
Spatial database design and deployment using PostgreSQL and PostGIS — the open-source backbone for serious GIS work.
PostGIS is PostgreSQL with a spatial extension — the open-source backbone for any GIS work that’s outgrown shapefiles or single-user geodatabases. Multi-user concurrent access, real query performance on serious data volumes, and the foundation a Web GIS portal sits on top of.
We deliver PostGIS setup and schema design for telecom planning, utility asset management, and infrastructure projects. This is delivered through our partner Geodars — the team behind this side of LayerSpec is GIS-led with deep PostGIS experience.
Why PostGIS, when
PostGIS is the right choice when:
- Multi-user concurrent editing is needed — shapefiles fall over, file geodatabases support multi-user uneasily
- Data volumes are non-trivial — millions of features, repeated complex spatial queries, real-time analysis
- You need open-source — licensing, governance, or technical preference
- Integration with non-GIS systems matters — PostGIS is PostgreSQL, so it integrates cleanly with web stacks, APIs, ETL pipelines
- Web GIS portals will sit on top — most modern Web GIS deployments back to PostGIS
It’s not always the right answer. ESRI Geodatabase has its place where the wider ESRI stack is in use. Single-user file workflows are fine when you really are a single user. We pick the platform that fits.
What’s in a PostGIS deployment
A complete deployment covers:
- Server setup — PostgreSQL + PostGIS extension, version aligned with project requirements
- Schema design — tables, geometry types, spatial reference systems, indexes
- Data loading — initial migration from existing sources
- Spatial indexing — GIST indexes on geometry columns, configured for query patterns
- Query optimisation — analysing and tuning the queries that drive the application
- Backup and replication — operational continuity, disaster recovery
- User and role-based access — who can read, who can write, who can administer
- Documentation — schema reference, query patterns, operational runbook
Deployment options
Three common deployment models:
1. Managed cloud — AWS RDS for PostgreSQL with PostGIS, Azure Database for PostgreSQL, Google Cloud SQL. Reduces operational burden, fits most projects.
2. Self-hosted cloud — PostgreSQL + PostGIS on a cloud VM, full control, more operational work.
3. On-premises — for organisations with on-prem requirements (data residency, network isolation, regulatory).
The right choice depends on data volume, operational team capability, and constraints (data residency, security policies). We assess at the start.
Schema design — the part that matters
A productive schema design covers:
- Geometry types and SRID — picked deliberately for the use case (geographic vs projected, accuracy requirements)
- Table design — normalised where appropriate, denormalised where query performance demands
- Foreign keys and constraints — actually enforced, not optional
- Versioning approach — how data history is preserved
- Topology — for utility networks, structural topology that supports tracing and connectivity queries
- Indexes — spatial GIST indexes plus B-tree indexes on commonly-filtered attributes
- Standards alignment — fibre/telecom asset schemas, utility data models, project-specific structures
Schema gets reviewed before data is loaded — far cheaper than discovering structural issues with millions of rows in place.
Inputs we need
A PostGIS engagement runs on:
- Use case — what’s the database for, what queries will run against it
- Data volume — feature counts, expected growth rate
- Source data — what data is being migrated in, in what formats
- Operational requirements — uptime, recovery, performance SLAs
- Integration points — what systems need to read or write to the database
- Security requirements — access control, encryption, audit
Common pitfalls in outsourced PostGIS work
Schema designed without query patterns. A schema optimised for storage that’s poor for retrieval produces an unusable database. We design with query patterns in mind.
Indexes added reactively. Spatial indexes added only after queries are slow add operational cost. We build indexes for known query patterns up front.
No versioning thought. Data without history is fine until you need to know what changed last week. We design versioning into the schema even where it’s not the headline requirement.
Backup as an afterthought. A database without tested backup is a database that loses data. We deliver backup with documented restore procedure that’s actually been tested.
Typical timelines
- Single-purpose deployment (e.g. asset records for a defined network) — 2-4 weeks
- Multi-purpose deployment with several schemas, integrations — 4-8 weeks
- Enterprise deployment with high availability, replication, complex integrations — 8-16 weeks
Migration from existing sources runs alongside or after — see GIS data migration & cleansing.
How we deliver
Geospatial work runs through our partner Geodars, who lead PostGIS, ArcGIS, and broader GIS engineering. The team has direct experience deploying PostGIS for utility, telecom, and infrastructure projects.
Talk to us about a PostGIS deployment
Tell us the use case, expected data volume, and operational context. We’ll scope and price for your project.
Typical deliverables
- PostGIS database deployment (cloud or on-premises)
- Schema design for fibre, utility, or asset data
- Spatial indexing and query optimisation
- Migration from shapefiles, file geodatabase, or other sources
- Backup, replication, and operational documentation
- User and role-based access control
Who buys this
Organisations needing a spatial database for fibre planning, utility asset management, telecom network records, or any GIS work that's outgrown file-based workflows.
Talk to us about delivery options
Tell us what you need delivered, what your timeline is, and what format the downstream team needs the output in. We'll come back with scope, price range, and proposed approach.