Gallium Data is a programmable proxy that sits between your database server(s) and your database client(s):

There can be any number of servers, clients and proxies:

Because Gallium Data intercepts all traffic between database client(s) and database server(s), it can observe, modify, inject and delete traffic, and change the interaction between client and server.

Gallium Data works at the wire protocol level, which means that it works with any kind of database client, whether it be written in JavaScript, Swift, C++, Python, Java, etc… All database clients are supported: mobile apps, application servers, business applications, report writers, etc… If it works with the database, it works with Gallium Data.

Database clients are completely unaware that they’re talking to Gallium Data, which behaves exactly like a database server.

Similarly, database servers are under the impression that they are talking to normal clients, as there is no observable difference in behavior.

This is Gallium Data’s superpower: it’s invisible, yet powerful.


Without Gallium Data


With Gallium Data, you can hide or change data without changing the database or the application.


With Gallium Data

Filters

Filters are bits of logic that are executed in Gallium Data whenever certain conditions are met. There are many different kinds of filters, including open-ended filters that enable you to execute arbitrary code that can monitor, reject or even modify the traffic between client and server. This gives you unfettered flexibility to affect how your applications and your databases interact, in ways that are difficult or near-impossible otherwise.

Filters can be applied to both requests and responses, therefore they can affect any aspect of the dialog between database clients and database servers.

Filters can be predefined and parameterized, and can also be implemented using custom logic, written in server-side JavaScript. Writing this custom logic is made easy thanks to Gallium Data's admin app, which includes a debugger:

Example: update rejection

It's very easy to add a filter to reject certain actions. For instance, you might decide that certain updates are not allowed under certain conditions. This is the type of thing that would normally require a significant amount of work to implement, yet it's a trivial filter in Gallium Data.

For instance, if we wanted to reject updates on the customers table during the weekend, we can simply create a filter that catches all SQL requests that update that table and attach a bit of code to the filter:


This is a trivial example, but since you have access to the full power of JavaScript, and of the underlying Java platform, your logic can be arbitrarily sophisticated. It is compiled and optimized at runtime, so it can be changed on the fly without any interruption, which makes for very productive coding -- no delays, no compilation, you can experiment and try new things instantly.

Example: query rewrite

Let’s assume that database user Alice often issues a very large query, which you have determined is overkill and is putting an undue burden on the database.

One way you can discover this, of course, is by using a Gallium Data monitoring filter to detect this situation. Let's assume you’ve already made this determination.

One solution, obviously, would be to talk to Alice and ask her not to do that. But perhaps that’s not an option — perhaps Alice is is using an application over which she has no control.

Using a Gallium Data monitoring filter, you have determined that a specific SQL query is a killer: it takes a long time to execute, and it returns a huge amount of data, almost all of which is actually never used.

This can easily be remedied with a query filter in Gallium Data, which will look for the offending query and rewrite it on the fly to make it less expensive.

The offending query is:

select * from customers

Because the database contains millions of customers, this is really fetching far more data than is required.

We can use a simple filter in Gallium Data to rewrite this query before it gets sent to the database server, so that it now is:

select * from customers limit 200

Note that Alice, and whatever application(s) she uses, have no idea that this happening. The only change she will notice is that she now only gets the first 200 customers.

Example: modifying and hiding data

Filters can also apply to responses from the database. It is therefore easy to have a filter that looks for certain types of data and acts on it.

You could decide, for instance, to hide data rows based on their value, or to hide or change only some column values for these rows. This can give you extremely fine-grained access control that is at best difficult without Gallium Data.

For instance, you might decide that database user Alice should be able to see employee records, but not their salaries. Perhaps you could even be more specific: she should be able to see salaries only for employees in Canada. This can be done with a simple filter, specified for the employees table:

When writing code, the debugger can be a big help to understand how your code executes.

Gallium Data is a unique tool and platform -- it inserts itself transparently between database clients and servers, enabling you to inject your logic, and opening up all kinds of new possibilities.