External Databases

External database connections let ActiveManage read from (and optionally write to) databases that aren't part of the platform's own storage — legacy systems, data warehouses, partner databases, analytics stores.

Supported Engines

• MySQL / MariaDB — full read/write.
• PostgreSQL — full read/write.
• SQL Server — read/write via ODBC.
• Oracle — read/write via OCI.
• SQLite — read-only by default.
• Snowflake / BigQuery / Redshift — read-only analytics access.

Connection Settings

• Hostname, port — direct or through a tunnel.
• Authentication — password, certificate, IAM role.
• SSL/TLS — always enable for production connections.
• Read-only toggle — refuses to send any non-SELECT statement.
• Connection pool size — how many simultaneous connections to maintain.
• Query timeout — kill slow queries automatically.

Step-by-Step

1. Open Architect Panel → External Databases and click Add Connection.
2. Pick the engine and provide credentials.
3. Click Test connection — the platform makes a sample SELECT.
4. Pick whether this connection is read-only.
5. Configure pool and timeout.
6. Save and assign to the relevant datastores or queries.

Worked Examples

• Legacy ERP read: Read-only MySQL connection to the on-prem ERP, used to display order history in the customer service screen.
• Data warehouse: Read-only Snowflake connection used by the reporting engine for big aggregations.
• Multi-write integration: PostgreSQL connection to a third-party billing system; ActiveManage writes invoice records on creation and reads payment status periodically.
• Analytics-only: BigQuery connection used by the dashboards for time-series customer behaviour.

Warning: Never use the same DB credentials for the platform's own storage and an external connection. Compromise of one shouldn't grant access to the other.

Where the external database actually lives matters for connectivity, latency, security and cost. This article covers the common deployment patterns and what to watch for.

Same-Region Cloud DB

Fastest. Both ActiveManage and the database run in the same region (e.g. AWS eu-west-1). Latency under 5ms, no internet egress charges, easy network ACL.

Other-Region Cloud DB

Connection works but every query pays 50-200ms. Suitable for low-frequency, batch-style integrations; painful for per-request lookups in interactive UI.

On-Premises via VPN

Common for legacy databases. ActiveManage connects through a site-to-site VPN to the customer's data centre. Plan for occasional VPN drops and configure retries.

On-Premises via SSH Tunnel

Lighter than VPN. Forward the DB port over SSH; the platform supports persistent SSH tunnels with auto-reconnect. Limited bandwidth — fine for small queries.

Third-Party SaaS DB

Some SaaS providers (notably modern data warehouses) expose direct SQL. Use their connection strings; respect their concurrency limits.

Network Security

• Allowlist the platform's egress IPs at the database firewall.
• Always use TLS unless inside a controlled VPN.
• Rotate credentials annually.
• Use per-purpose users (read-only user for reporting, separate writer for ingestion).

Worked Examples

• Same-region: RDS Aurora in AWS eu-west-1 connected from ActiveManage in eu-west-1. 2ms latency, no special infra.
• Legacy on-prem: On-prem SQL Server reached via IPsec VPN. Customer's DBA opened a read-only account.
• SSH tunnel: A consultancy reaches a small client's PostgreSQL through SSH; tunnel re-establishes automatically on disconnect.
• BigQuery: Direct connection with service-account JSON key, query limited to specific datasets.

An external-source-linked datastore appears to your application like any other datastore — list, create, search — but the data lives in an external database. You read and write through ActiveManage's normal interfaces while bytes stay where they belong.

Setup Flow

1. Create an external DB connection (covered in “Connecting to an External Database”).
2. Create a datastore in ActiveManage, choose “External source” as the storage backend.
3. Pick the source connection and the target table.
4. Map columns: source column → platform field. Auto-mapping suggests by name similarity.
5. Set sync policy:
   • Read-only: Cannot write to the external table; ActiveManage acts as a read-through cache.
   • Read-write: Updates in ActiveManage flow back to the external table.
   • Hybrid: Read external; store some additional fields in ActiveManage's own DB and join on key.
6. Optionally enable caching with a TTL.

Queries

Every query against the linked datastore is translated to SQL against the external DB. The platform handles type conversions, NULL handling, and pagination. Complex filters work but may be slower than against native datastores.

Worked Examples

• Legacy customer service: Show order history from the legacy ERP without migrating it. Datastore Legacy Orders linked read-only.
• Two-way sync of contacts: Contacts datastore backed by external CRM DB. Edits in ActiveManage UI flow back to the CRM.
• Analytics overlay: Reports datastore backed by data warehouse — fast aggregations available to dashboards.
• Migration bridge: During migration, run the new system on top of the old DB until the old system is fully retired. Then unlink, retain in ActiveManage's own DB.

Tip: Test query performance early. A datastore linked to a slow remote DB feels slow everywhere — list views, search, exports. If latency is bad, consider caching or replicating data into ActiveManage's own DB.