Improve application performance for Amazon SQL Databases. No code changes required.

Amazon RDS video: Read/Write split, Query caching, & Connection Pooling


RDS Video Topic Video Start Time (sec)
Query Caching 9:20
Read /Write Split 13:25 
Connection Pooling 18.00 and 25:22
Q&A 18:25


Read/Write Split

Horizontally scaling Amazon RDS or Aurora requires application changes to route queries to the write-master and read-only replicas.

The Heimdall proxy intelligently routes queries to the appropriate database instances without code changes. For read queries, we ensure users receive the most up-to-date  data with our replication lag detection. Check out our AWS blog.

Heimdall for ElastiCache

Automated Query Caching: Executed in the application tier, removes latency to the database. Result sets are cached to the storage of your choice: 1) Local memory, 2) Amazon ElastiCache, or 3) Both. Automated invalidation is supported. Deployment requires zero code changes.


Transparent Batching of INSERT’s

Heimdall Data improves performance over 1000x! We batch singleton INSERT’s under a single transaction.

  • Ideal use case:  INSERT a large amount of data at once on a thread. Heimdall processes at once much faster than if individual queries outside of a transaction were completed. See below demo video.


  • Not so ideal use case: Concurrent writes and reads against the same table, on the same thread will not be beneficial with this solution, as everything will just block until the DML operation is completed anyway.

Watch how batching INSERTs improved performance 1000x!


Redshift Video Topic Video Start Time (sec)
Batch Processing 0:00
Query Caching 7:30
Connection Pooling 12:25
Q&A 14:57


Automated Persistent Connection Failover

Heimdall detects database health and performs a failover to the standby. But doesn’t Amazon RDS/Aurora already support this? How is Heimdall different?

Heimdall’s failover takes an application-centric approach: Upon a failure, Heimdall queues up the connection and transparently creates a new connection at the backend to the standby instance. This greatly reduces and/or eliminates application errors and exceptions. Hence, failover is transparent to the application and user; not so, with a DNS or IP based failover solution.