We are a small team focused on one thing: making sure work that touches a production database is assessed before it happens and provable afterwards. This page states what we are and what we are not yet.
The enterprise IT stack matured around the application layer. Source repository, code review, delivery pipeline, release tag: on the application side the answer to what went to production sits in one place and nobody argues about it.
The database layer never reached that maturity, and the reason is not technical: work that touches the database does not flow through a single channel. A schema change goes through the pipeline; a data correction does not. Nor does a permission change, nor an emergency fix at night. A request to extract production data for an audit was never any pipeline's business. In most organisations the process covers exactly one of the roads into production and the rest proceed unrecorded.
SQL Change Guard was written for that gap. It does not replace your existing tools; it answers the question they leave open: was the text that ran the text that was approved, and who reached production data, on what stated basis?
These are not marketing lines but engineering decisions with real consequences that we live with.
We do not offer a cloud service. Your scripts, query results and records never leave your environment. This is the harder distribution model for us, since installation and release management live on the customer side. We still think it is the right call: for a product that touches a production database, where the data sits should not be up for discussion.
Keyword matching is fast and easy, and it misleads: whether a statement is unqualified, which object it touches and what type it is can only be established reliably by analysing it against the grammar of the language. Maintaining three separate parsers for three databases is expensive; assuming a shared syntax produces silent errors.
What the product cannot do sits under its own heading on the security page. We cannot stop someone with full database access from deleting records; what a signed chain gives is detectability rather than immutability. We say this in a sales meeting before being asked, because saying it when asked is too late.
You will not find a customer logo, a testimonial, a certification badge or an analyst quote on this site. We have none of them and we do not pretend otherwise. Instead we put up real product screens, real flows and verifiable technical detail.
We are an early stage product. We say so up front because it affects your evaluation. In practice that means:
The first conversation is not a product pitch. We map together where decisions are made in your organisation and where the evidence sits. Every step that follows a demo request is written out on the contact page.
Request a demo →Related pages: what Database Operations Governance is, security architecture, compliance and control mapping, product documents.