Regardingh Combined domain network of Water and electric utility in a single Enterprise SQL database

PragatiSingh · ‎12-10-2025

we are moving to arcgis utility network for our electric and water geometric network data to Postgres enterprise database. How we separate the two domain networks within the postgres instance? Do we need to create separate databases within the instance

VishApte_NGIS

Separate geodatabase for Water and Electric seems to be a good choice if two different teams edit and maintain it. There are few considerations though:

1. If you have to develop attribute rules that refer to common dataset such parcel or property polygon, city council boundary, bushfire zones etc. using functions like FeatureSetByName, they only work within one geodatabase. This means you will need to have two copies of the common data, one in each GDB. Or register data views across the database if the use for common data is read-only.

2. If you have common structural assets e.g. bridge or trench or other structural boundaries, this will be difficult to model without duplication.

3. Relationship between water and electric service points and common customer information such as critical medical customer relying on water and electricity like dialysis machine.

4. Workflow for converting abandoned water pipes into a duct for electric cable.

5. Power supply for water and sewer pumps and treatment plants, though currently there is no-cross domain traceability between the domains.

Keeping Water and Electric UNM in a same geodatabase but different feature datasets e.g. WaterUNM and ElectricUNM in also an option. However, from memory, it creates structural feature classes and tables as StructureJunction_1 etc. for the second feature dataset.

Keeping Water and Electric in a single feature dataset and single topology model is ok if editing user permissions is not a problem. But if topology needs tweaking in either domain, the whole UNM needs disabling, causing outage across both domains.

Hope this helps.

Cheers,

Vish

View solution in original post

AyanPalit

@PragatiSingh There are multiple considerations in making a design decision here. Electric and Water typically don't mix - best to keep them as separate databases/schemas, one for each domain network.

Organizations are unique in their mix of utility domains that drive functional requirements, workload separations, IT policies (e.g RDBMS platform), integration needs. Recommend a holistic approach factoring in all parameters.

Ayan Palit | Principal Consultant Esri

JakeJacobsAVA

We recently received advice from Esri to have our gas and electric UN's in one database but in separate schemas. @AyanPalit can you describe what the criteria are for deciding on separate schemas vs separate databases? Also PostgreSQL here.

RichRuh

I would base it on the structure of your organization. If one GIS group serves both water and electric, then putting them in a single utility network makes sense.

If most of your users are using water or electric, and you want different permissions for each domain (e.g., water GIS users can view electric, but not edit) , then it might make sense to split them up.

JakeJacobsAVA

Oh interesting. How does that work with the permissions? I thought that was just managed at the portal level with what groups the feature service is shared with?

RichRuh

When you publish a utility network to a feature service, you need to include the *entire* utility network.

If you put both domain networks (water, electric) in a single utility network, that entire utility network is included in the feature service. You can only set permissions on the feature service as a whole.

If you split them up into two utility networks, you would publish them as two services, and could set different permissions on each one.

Another consideration is if you want to share the structure network between domains. While you don't often see water pipes attached to poles, they may share trenches or other facilities.

JakeJacobsAVA

Interested still to know about the distinction between putting two utility networks in separate schemas (which Esri recommended to us recently) and two separate databases (which Ayan Palit recommended here). Seems like in that case it wouldn't be for permission management.

AyanPalit

@JakeJacobsAVA As is evident in this thread, there are multiple parameters in play.

Organizations are unique in their mix of utility domains that drive functional requirements, workload separations, IT policies (e.g RDBMS platform), integration needs. Accordingly, one size/recommendation will not fit all. Advice community members to consider their unique requirements/circumstances to right-size the Utility Network design.

Ayan Palit | Principal Consultant Esri

RobertKrisher

@PragatiSingh there's lots of discussion here. You have two domain networks, and the assumption is that you want them to be in separate utility networks You could put them in the same utility network if you wanted them to share structures or had some other compelling reason, but that is not typical for water/electric.

If you do want to have multiple utility networks, then you can have options. If you just want to manage one database, you can put them in the same database but give each one separate schemas. If you put them in the same schema you will get name conflicts on the structure classes (so you'll have structurejunction and structurejunction_1).

If you want to manage them in separate databases, then you are free to do that using however many databases, instances, and servers that you want because the two utility networks are not related in any way.

PierreloupDucroix

Interesting topic. I'm working on a migration project where the client manages an electricity and water network.

Their common use case is to use the unique identifier of the utility poles (an identifier that indicates the pole's position on the network) to locate each field intervention, including on the water networks, since they don't have addresses.

While it's possible to manage this without merging the two domains into a single unified UN, it could be useful to associate the water elements with their corresponding utility poles and use this association in tracing, for example, to easily find the nearest pole to send a field team to.

CEO of MAGIS