Heimdall Database Proxy - Caching ArchitectureHeimdall optimally operates via a two-layer cache system. The first layer (L1) is an in-heap cache, the size of which is controlled by the heap size in the VDB->proxy settings. The second layer (L2) is used as secondary storage and as a means of communication amongst the deployed proxies. The user will choose any of the supported cache engines to provide a distributed cache between nodes.

Heimdall Database Proxy - Use CasesThe key use cases for Heimdall database proxy include: Connection pooling from serverless applications, including support for multi-user pooling. Automated caching and invalidation to the cache of your choice (e.g. Redis). Read/Write split (i.e. query routing) to reduce load on write-masters in a multi-node cluster. Improving the performance of DML Ingestion, in particular in Analytics Database environments (Pivotal Greenplum and AWS Redshift). Analytics. Heimdall supports a variety of databases including Postgres and Postgres based databases (AWS Aurora, Redshift and Greenplum), MySQL and SQL Server databases. For caching, it supports Hazelcast and Redis.