Frequently Asked Questions

When should you use the Heimdall Proxy?

Repetitive, duplicate queries: Caches SQL results to the grid-cache of your choice, offloading database processing and improves response times.
Horizontal database scale-out with Strong Consistency: Read/write split for better use of read replicas without code changes. Ensures fresh data with replication lag detection.
Connection Pooling: Minimizes backend connections by a ratio of 1000:1. Limits connections per user and per database instance.
SQL Performance Analytics: Identifies the SQL bottleneck: Application? Database? Network latency?
Database Disaster Recovery: SQL-aware failover solution for Postgres, SQL Server, MySQL, MariaDB, Oracle and DB2; persists connection during a failover reducing application errors and reconnects.
SQL Firewall: Detects and blocks SQL injection anomalies. There are no signature or profile updates. Our proxy prevents ZERO day database attacks.

How are you different from other Database Proxies (Pg-Bouncer, ProxySQL, RDS Proxy)?

Summary of how Heimdall Proxy uniqueness:

Read/Write splitting with ACID Compliance
Automated Query Caching and Splitting for queries in transactions.
2-tier Connection Pooling: Per-user and Per-database
X Other proxies do not guarantee data consistency, nor support multiple proxies as a single unit.
Check out this webinar

Does Heimdall Data support all databases (SQL and NoSQL)?

Heimdall Data supports most all relational database (e.g. MySQL, Postgres, Amazon RDS, Oracle, SQL Server, MariaDB). Our solution is transparent to the application and database. We are a software add-on installed on application servers.

Heimdall Data does not optimize for NoSQL databases at this time. However, Heimdall can support SQL-to-NoSQL dialect translation giving developers access to multiple data sources.

Is Heimdall Data compatible with ORM (Object Relational Mapping)?

Yes. Heimdall Data works with ORM’s.

An ORM (Object-Relational Mapping) is a tool that queries and manipulates data from a database using an object paradigm. Below are the added benefits of Heimdall Data:

Heimdall Data is installed as data access layer after the ORM in the data flow towards the database and caches SQL result sets. We are transparent to ORMs.
While ORM’s has SQL caching functionality, the user must choose which queries to cache. Heimdall automates caching and invalidation and has proven to improve performance alongside ORM’s.
Heimdall Data aggregates caches nodes as a single cluster across application servers for efficient cache management. ORM’s caching is on a per application server basis and data is not synchronized upon updates.

How is Heimdall Proxy used as a transparent caching solution?

Heimdall Data is not a cache. Heimdall provides the caching logic for existing grid-caches. The operational elegance of the Heimdall Proxy is that it does not require any application code changes. This is ideal for those deploying 3rd party applications (e.g. HR, manufacturing, finance) requiring performance improvement. Installation is in minutes.

For application developers, cache policies are typically coded into their application code. This creates inefficiencies: 1) Trial and error of what to cache, and 2) Longer development cycles. The Heimdall proxy automates caching with “one-click”. Our algorithms determine what queries to cache and invalidate to ensure maximum performance and data integrity.

Do you support Cloud Providers or On-premise?

Whether in cloud service providers or on-premise environments, Heimdall Data can be supported. As long as you can install software into your application server, we will provide SQL optimization.

Heimdall Data is a technology partner of AWS, Azure, and Google Cloud and is installed as a separate proxy tier. For AWS, our configuration wizard detects Amazon Elasticache and Amazon RDS via IAM roles. Just point to your storage of choice (in-memory or Elasticache) and RDS instances, and we will take it from there.

Why Heimdall Data if we are already deployed in the cloud?

Heimdall Data enhances an already existing application-database in AWS/Azure/GCP in 3 ways:

Auto-caching / Auto-invalidation: If you already deployed SQL caching (e.g. in-memory, Elasticache, Redis), our proxy will make your caching better performing and more reliable. Our caching algorithms will only cache the queries that provide a performance benefit. We will also ensure your cache nodes are synchronized and up-to-date so that there is no stale data. You get all of this without code changes.
Better usage of Read replicas: When read replicas are created, the developers must modify the application to appropriately route queries. Also, AWS reader endpoints are based on DNS, which can result in all the connections going to a single replica instead of an even load distribution across replicas. The Heimdall Proxy is not based on DNS and directly interfaces with the Amazon RDS API to track health status and state. This allows us to evenly load balance across RDS instances.
Heimdall supports read/write split which will route queries to the appropriate database server. It is a simple configuration policy on the Heimdall console requiring zero code changes.
Persistent connection automated failover: Amazon RDS supports automated failover. However, Heimdall’s SQL failover is from an application perspective. When Heimdall detects an unhealthy database instance, it will queue up the current connection and gracefully failover to the replicate database. This results in minimal to no application errors and exceptions.
Seamless AWS integration: Heimdall is tightly integrated with Amazon Elasticache, RDS/Aurora, CloudWatch, and Redshift. Our configuration wizard provides a user-friendly console to connect Heimdall to your AWS components. All integration is without code changes.

Heimdall Data is available in the AWS Marketplace and is installed in your EC2 application instance. With the Heimdall-AWS configuration wizard, we automatically connect to Amazon Elasticache and RDS based in IAM roles. Just point to our storage of choice (in-memory or Elasticache) and RDS data source, and we will take it from there. Installation is easy in Azure and Google Cloud.

But we already cache at the business object and web level. Does Heimdall Data still add benefit?

Absolutely. Working alongside the application caches and web caches, the Heimdall cache provides additional for performance benefits, particularly for dynamic content. Application level caches may have constrained parameters (e.g. per session) limiting the caching required for optimal performance. Because Heimdall caches at the data access layer, it sees the unrestricted flow traffic going to the database and optimizes performance that other cache systems will not be able to detect.

Web level caching is static content. And, one can only start streaming static content once the dynamic pieces have been generated. It is that dynamic content from the database that Heimdall optimizes.

How is Heimdall Data different from middleware (IBM, Oracle, Microsoft, , Tibco)?

Middleware products provide flexibility of data interfaces for integration and management. Also, users of middleware require users to program to an API. From its inception, Heimdall Data’s value proposition is to be transparent, requiring ZERO application code level changes so that there is no integration work by the customer. Additionally, Heimdall Data is focused on improving application performance and scale, not on supporting multiple access methods (e.g. SOAP, REST, ODBC) like middleware vendors. Heimdall Data complements and is compatible with middleware products.

What makes the Heimdall Data High Availability failover unique compared to Oracle and existing load balancing solutions?

The Heimdall Data HA failover solution is database vendor neutral. For customers who deploy multiple data sources, Heimdall can be used as a common platform for automated database failover. Heimdall Data supports databases such as MySQL, PostgreSQL and Oracle. Additionally, customers do not have to purchase piecemeal solutions as Heimdall is a platform for supporting 1) SQL optimization, 2) Automated failover and 3) SQL security.

Solutions in the market today (e.g. TCP load balancer) are not application aware. The TCP load balance may successfully failover to a redundant database, but if the application time out and be forced to reconnect. The Heimdall Data Resiliency Platform is application aware ensuring that upon a database failover, the application connection will be maintained and is at top performance.

Heimdall Data can automate the failover on the master node for disaster recovery. We do not support database replication or slave promotion.

How much CPU and RAM load does Heimdall take up on the application server?

Although application dependent, we have found that enabling Heimdall caching or Heimdall HA failover consumes minimal server load. On the average, initial estimates show single digit percentage load of CPU and RAM when Heimdall is enabled.

How is Heimdall Data different from Hibernate ORM (Object-Relational Mapping) framework?

Heimdall is a SQL optimization platform that supports caching, security, and high availability. Heimdall Data can work together with Hibernate and make your environment more scalable and higher performing.

From a SQL context, Hibernate requires the user to program to its APIs. Hibernate can interface with grid caches and manipulate SQL queries. Heimdall Data can do the same but is deployed transparently, requiring zero application code level changes. Heimdall is much easier to manage and deploy. Moreover, the performance of Hibernate is no comparison to that of Heimdall Data. Heimdall was architected to increase application performance and offer a platform of services (i.e. SQL optimization, HA, and security)

What is the pricing model for Heimdall Data?

A customer can purchase directly from Heimdall Data as an annual subscription; or from AWS, Azure, or Google Cloud on a per usage basis.

Does the use of Heimdall invalidate the support contracts for databases?

While vendors have their own policies, the answer should be no. As we are operating above the vendor JDBC level, Heimdall is comparable from a support point of view to being part of the application itself, not part of the database access layer, at least as far as the database is concerned. Another way to put it is if you change your own code, will this invalidate a database’s support license? This is in contrast with devices and systems that operate at the protocol level, which may need to be certified to access the database to maintain support.

Our Web Application Firewall is used protect against SQL attacks.

SQL injection attacks trick the application into performing adversely. Because this form of attack is dependent the application behavior, there are cases where the WAF or application does not see such an attack. Hence, the Heimdall solution will act as a last line of defense for SQL data leakage.

How does Heimdall Data benefit Big Data?

Big data generally refers to how data is processed on multiple computing systems, and how a client can access the data from such systems (e.g. sharding). As Heimdall operates above the actual access layer for the data, it offers benefits much like any other database, as long as the underlying access driver is JDBC compliant, including visibility of what queries are taking the most time to process, which in a big data environment may be significant.