Overview

The Heimdall Data is a SQL platform for application developers, database administrators, and infrastructure owners. Whether on-premise or cloud, Heimdall helps organizations deliver faster, more reliable, and secure content generation.

Heimdall Architecture

 

Heimdall Data is a distributed Database Proxy that optimizes from an application perspective. It gives users visibility and control over their SQL environment. Our proxy can be installed anywhere: 1) On each application instance, 2) Separate proxy tier, or 3) On the database. We are transparent to the application and database.

Caching: Today’s SQL solutions incur data latency from application-database round trips. Caching on the database improves scale, but does not remove the latency. The Heimdall proxy can be deployed as a sidecar process across application instances. This distributed model results in optimal performance and predictive scale.  

With Heimdall caching, queries that would have gone to the database are now cached locally on the application tier. You choose the cache of choice (e.g. Amazon Elasticache, Redis) and Heimdall determines which query results to cache and invalidate. Best of all, caching does not require writing a single line of code.

Read/Write Split: To scale the database tier horizontally with master and read replicas, applications modifications are required. Heimdall is SQL aware and routes queries to the appropriate database instances (writes or read replicas). As an added benefit, we support replication lag detection to ensure fresh data is always served.

Automated Failover: Health checks each database instance. Upon a failure, Heimdall holds the connection as it transitions to the redundant database instance. This results in failovers that are transparent to the application.

The above chart shows how Heimdall Data compares with other database proxies. How are we unique?

  1. Granular 1) Per user and 2) Per database server connection limits
  2. Read/write split with replication lag detection to ensure fresh data
  3. Auto-cache and Auto-invalidation requiring no application changes
  4. Database vendor neutral, allowing users to standardize on a single data access layer for an Enterprise with diverse databases