Multi-Database Connectors

How it works

One DuckDB hub, every source

A single in-process DuckDB engine ATTACHes each source read-only via its scanner/attach extension — postgres_scanner, mysql_scanner, the bundled sqlite, plus community mssql, bigquery, and gsheets. No per-vendor ADO.NET driver to ship.

Automatic spatial discovery — detects typed GEOMETRY/WKB columns, BLOB columns recognized by st_geometrytype, and common names (geom/geometry/the_geom).
Lat/long virtualization — pole and outage tables with no geometry column get a synthesized POINT view via ST_Point(lon, lat, 4326) from lat/long pairs (flagged isLatLongVirtualized).
Three facades over the same data — MVT, OGC API Features, and ESRI FeatureServer, reused by the local-file DuckDBs too.
Smart layer pickup — auto-chooses MVT for large layers (>2000 rows), GeoJSON for small ones.

POST /api/connectors

# connect and discover spatial tables
curl -X POST http://localhost:5059/api/connectors \
  -H 'Content-Type: application/json' \
  -d '{
    "name":"prod-pg",
    "kind":"Postgres",
    "connectionString":
      "host=localhost port=5432
       dbname=gis user=postgres
       password=secret"
  }'

→ profile saved, DPAPI-encrypted
→ collections discovered & served

Three ways to read the same data

Point any client at it

Each discovered collection is exposed under /api/spatial/{dbId}/... — so ArcGIS Pro, QGIS, MapLibre, and any OGC client across the utility can consume your existing tables with no extra wiring.

▢

Dynamic MVT

/collections/{c}/tiles/{z}/{x}/{y}.mvt — fast PBF vector tiles generated on demand via DuckDB ST_AsMVT.

🌐

OGC API Features

/collections/{c}/items?bbox=&limit=&filter= — modern RESTful GeoJSON with filtering and sorting.

🗺️

ESRI FeatureServer

/FeatureServer/{i}/query?where=&geometry= — drop it straight into an ArcGIS map.

🔒

DPAPI-encrypted profiles

Connection strings encrypted with Windows DataProtectionScope.CurrentUser to connectors.json; decrypted only in memory at connect time.

🔌

Read-only by design

Sources are ATTACHed read-only — your authoritative systems of record are never written to from the desktop. VoltGrid gives them a live map view, and pairs with GRID State for the operational record itself.

✈️

Airgap-aware

Community extensions fail gracefully (profile saved, lastError shown); only bundled official extensions are guaranteed offline — a fit for isolated OT networks.

The API surface

Manage, test, and serve

Group	Endpoint	Notes
Management	GET / POST /api/connectors	List / register a source profile
Management	POST /api/connectors/test	Validate before saving
Management	GET /api/connectors/{id}/collections	Discovered spatial collections
Spatial facade	GET /api/spatial/{dbId}/collections/{c}/items	OGC API Features (bbox, filter, sortby)
Spatial facade	GET /api/spatial/{dbId}/collections/{c}/tiles/{z}/{x}/{y}.mvt	Dynamic vector tiles
Spatial facade	GET /api/spatial/{dbId}/FeatureServer/{i}/query	ESRI FeatureServer query

Base URL http://localhost:5059. Browser smoke test at /connectors-test.html. Npgsql is not used — by design the app relies on DuckDB's scanner extensions, not per-vendor ADO.NET.

Walkthrough · captured in-app

DuckDB Spatial vector layer loaded natively

Auto-discover, query, and style regional vector polygons and parcels in-process with hardware-accelerated symbology.

DuckDB Spatial EngineNavarra Region Vector PolygonsZero ETL

VoltGrid desktop — DuckDB spatial vector data of Navarra rendered natively — DuckDB Spatial vector layer (Navarra region) auto-discovered and rendered natively as a styled map layer

New · Microsoft Fabric OneLake New

Your enterprise lakehouse, on the map

For utilities standardizing on Microsoft Fabric, VoltGrid reads Delta tables straight from OneLake — no extract, no sync, no Power BI export. Drop in your Lakehouse URI + account key and every .delta table you name is registered as a DuckDB view over delta_scan('abfss://...'), served through the same MVT / OGC API Features / FeatureServer facades as every other connector.

Delta Lake native — reads via DuckDB core azure (auth) + delta (reader) + spatial extensions. No community-extension dependency, no version-locked binary.
Account-key auth via DPAPI — connection strings live in <dataDir>/fabric/profiles.json, encrypted with Windows DataProtectionScope.CurrentUser. Never written to disk in cleartext.
Per-table view registration — supply a tableFilter (e.g. ["assets","outages","meters"]); VoltGrid composes abfss://<workspace>@<account>.dfs.fabric.microsoft.com/<lakehouse>.Lakehouse/Tables/<table> per table and registers a view. No bucket-listing surface.
Read-only by design — every OneLake view is a SELECT, so VoltGrid can never mutate your lakehouse. Pair with GRID State for the operational write layer.
Capability-gated & never-throws — if the Fabric subsystem isn't wired at startup, the connector surfaces a clear "not initialized" error instead of crashing. Test before you save via POST /api/connectors/test.

POST /api/connectors · FabricLakehouse

// OneLake Delta tables → DuckDB views
{
  "name": "fabric-prod",
  "kind": "FabricLakehouse",
  "connectionString": {
    "oneLakeUri": "abfss://util-workspace@onelake.dfs.fabric.microsoft.com/Assets.Lakehouse",
    "accountName": "utilstorage",
    "tableFilter": ["poles","conductors","outages"]
  },
  "accountKey": "..."
}

→ profile saved, DPAPI-encrypted
→ per-table views registered via delta_scan()
→ served at /api/spatial/fabric-prod/…

Microsoft Fabric OneLake connectivity directly queries Delta Parquet tables over secure Azure Storage endpoints.

Map the asset data you already have

Seven sources — six databases plus Microsoft Fabric OneLake — auto-discovered spatial tables, three serving facades — without moving a single row out of the systems your utility trusts.

Live feeds & StreamServer → Read the docs

The databases your utility already runs. Already on the map.