In most setups, an application talks directly to its database. One address, one account, one password, and every query goes straight to the engine. That works perfectly well, right up to the day you expect more from the database than it can deliver on its own: refusing a query it should never have received, holding up when the load doubles on a Monday morning, staying reachable when the server it runs on goes down.
Those three expectations have one thing in common: none of them is handled cleanly in application code. You can add checks, reconnection attempts, some logic to send certain queries elsewhere, but every application does it its own way, with its own gaps, and it all has to be done again for the next one.
So we chose to deal with them in a single place: a layer sitting between the application and the database. The application connects to it as it would to an ordinary database, with the same protocol and the same queries. That layer decides what is allowed through, which server to send it to, and what to do when one of them stops answering.
It brings together three building blocks. None of them is mandatory: you switch on the ones that fit your situation, and you can add another later without redesigning anything. Like the rest of our services, the whole thing is set up, tuned and operated by Redswarm as part of your hosting.
Which combination for which need?
The three building blocks combine freely. A few configurations come up often:
- An exposed application with modest load: the SQL firewall on its own. You don't need several servers to want control over what reaches your database.
- A database that slows down at peak hours: replication plus the load balancer in read / write mode. Reads move off the primary.
- A business that can't afford downtime: replication plus the load balancer for server monitoring, with or without splitting the flows.
- Sensitive data and sustained traffic: all three together.
What's worth knowing before you choose
Each building block brings something, and each comes with its own rules. We'd rather set them out here than in a crisis meeting.
A replica always lags slightly behind. It receives changes a few moments after the primary. A read that immediately follows a write may therefore not see it yet. Several safeguards limit the effect: queries within a transaction stay on the primary, a replica that falls too far behind is taken out of the rotation, and reads that need fresh data, such as a shopping cart right after an item is added, can be sent to the primary by a dedicated rule. We identify those cases with you before switching the mode on.
The firewall has to keep up with your releases. A new feature brings new queries that aren't in the inventory yet. They are added at deployment time. One-off operations, such as a schema migration or a bulk import, go through a dedicated account with its own rules.
Replication is not a backup. A row deleted by mistake is copied to the replicas just as faithfully as a legitimate change. Backups remain essential, and replication doesn't replace them.
The firewall doesn't fix the code. A vulnerable query stays vulnerable, and parameterised queries remain the rule. The firewall limits how far a flaw can reach; it doesn't make it go away.
A database doesn't have to carry everything on its own. It just needs to receive only what it should handle, where it can handle it.
Where to begin?
The right combination depends on what worries you most today: what gets into your database, how much it can take, or what happens the day it stops. There's no reason to switch everything on at once. Many start with a single building block and add the next one when the need arises.
The first step costs nothing: book a slot and we'll look at your database, its load and its access together, to see what makes sense for you.