Improve Amazon RDS scale and reduce costs up to 50%: No code changes.
 How is the Heimdall Proxy Unique?
- All database and supported versions (e.g. Postgres, MySQL, SQL Server, RDS, Aurora)
- Support for Postgres 13+
- Guaranteed data consistency
- Check out our webinar
Read/Write Split with Strong Consistency
Intelligently routes queries to writers and readers without code changes. Evenly load balances to the lowest latency replica without DNS issues. Users receive the most up-to-date data with our replication lag detection. Check out our AWS blog.
Automated Query Caching: Removes latency to the database, SQL results are cached and invalidated into Amazon ElastiCache. Deployment requires zero code changes.
Users directly accessing the database can be a security risk. Extra resources are required to manage passwords (e.g. resets, employee departures). The Heimdall Proxy secures data access with:
1) Authentication and Authorization with Active Directory
2) Synchronization of users/groups to roles with the database
This removes the need for multiple places of authentication management. As a database firewall, our proxy identifies unknown and rogue queries to guarantee data integrity. Check out our video below or AWS blog.
Connection Pooling
The Heimdall proxy supports true multi-user pooling. Operators can safely scale without overwhelming database resources:Â
- Connection Pooling: Multiple client connections are associated to a database connection. Users can limit connections per user and per database.
- Connection Multiplexing: Backend connections are created for only “active”, non-idle queries. This results in lower memory, and reduced database costs. Check out our AWS blog.
Heimdall Data improves performance over 1000x!Â
- Ideal use case:Â INSERT a large amount of data at once on a single connection. See below demo video.
- Not so ideal use case: Concurrent writes and reads against the same table
Automated Persistent Connection Failover
But doesn’t Amazon RDS already support failover?
We take an application-centric approach: Upon a failure, we queue up the connection and transparently failover to the standby RDS instance. This greatly reduces application errors and exceptions; not so, with a TCP/IP load balancer.
