Stats
brettwooldridge/HikariCP is an open source project licensed under Apache License 2.0 which is an OSI approved license.
HikariCP Alternatives
Similar projects and alternatives to HikariCP based on common topics and language
-
Hasura
Blazing fast, instant realtime GraphQL APIs on your DB with fine grained access control, also trigger webhooks on database events.
-
Efficient-Pagination-SQL-PoC
A PoC that provides better guidance on creating a more efficient pagination without using SQL OFFSET and LIMIT.
-
Scout APM
Scout APM - Leading-edge performance monitoring starting at $39/month. Scout APM uses tracing logic that ties bottlenecks to source code so you know the exact line of code causing performance issues and can get back to building a great product faster.
-
-
FlexyPool
FlexyPool adds metrics and failover strategies to a given Connection Pool, allowing it to resize on demand.
-
-
-
SaaSHub
SaaSHub - Software Alternatives and Reviews. SaaSHub helps you find the best software and product alternatives
Posts
- How big should your connection pool be?
- 25 February 2021- Daily Chat Thread
- About connection pool sizing
-
Java database connection
A better option is to use a connection pool such as Hikari. Just initialize your connection pool with a fixed size and fetch connections from this pool. Whenever you are done with the connection, the connection automatically gets returned to the pool.
In a more modern application we might use a connection pool library (like c3p0 or HikariCP) which also supplies us a Connection, but it's pretty much doing the same thing as what we have in the application server (pooling connections with high control over the configurability).
-
Understanding Connections and Pools
Related, about sizing DB connection (counterintuitively): https://github.com/brettwooldridge/HikariCP/wiki/About-Pool-...
-
API pagination design by using cursors instead of offsets
If the API takes a cursor and a number of items to fetch, the idea of a "page" or how large it is exists entirely on the client. You can fetch 40 results in one query and say it corresponds to the next four "pages", if you're configured to show ten items per page
It seems worth noting a high number of concurrent queries to the same database shard as part of the same overall page load can be very wasteful of CPU as database load increase, due to the cost of context switching. https://github.com/brettwooldridge/HikariCP/wiki/About-Pool-... dives into that.