Performance
One of the most common questions about Gallium Data is: will it affect my database performance?
The short answer is: yes, but not as much as you might think, especially when you consider the alternatives.
By definition, accessing a database through Gallium Data is going to be somewhat slower than accessing the database directly. But Gallium Data is highly optimized to minimize this, and can be scaled to any extent, either by scaling up the machine on which it runs, or by multiplying the number of machines.
The performance cost of Gallium Data must also be measured against the alternatives. In many scenarios, the only other option is to add a middle tier in front of the database, which is almost always far more expensive, time-consuming, and has usually much worse performance because of the added layers of abstraction. Gallium Data works at the wire protocol level, which is as low as you can get. This allows it to have all kinds of optimizations that are simply not possible when working at the application level.
In general, depending of course on the complexity of your logic, most people see a 10%-15% increase in latency.Â
Scaling up Gallium Data
Gallium Data can be scaled:
vertically, by giving it more resources: more memory, more CPU cores. Gallium Data will automatically adapt to available resources. It is usually not useful to scale memory beyond a few gigabytes, except in unusual cases. In terms of cores, Gallium Data will use as many as you give it. A single core can usually handle many database connections concurrently, depending on the volume of the connections. In typical applications, one core can usually handle hundreds of connections.
horizontally, by running multiple instances. This is usually done with a TCP load balancer such as HAProxy or seesaw. Your Docker environment (such as Kubernetes, OpenShift, etc...) will also usually have some load balancing capabilities. Any TCP (network level 4) load balancing solution should work fine.