Point it at SQL Server.
Walk away with insights.
DecisionBox connects to your Microsoft SQL Server database — on-prem, in the cloud, or Azure SQL Database — in a few minutes. No schema migration, no pipeline to build. The agent reads your tables in place over an encrypted connection, runs read-only queries against them, and surfaces validated insights from what is already in your database.
Three things to know on day one.
Read-only, scoped by a SQL Server login
Create a SQL login — or a contained user on Azure SQL Database — with SELECT on the schema and tables you want the agent to see, nothing more. SQL Server's GRANT model is the access boundary; the agent cannot reach anything it has not been granted.
Built for a database that's also serving your app
Small connection pool, per-query timeout, and row counts read from the engine's partition metadata (sys.dm_db_partition_stats) so the agent never asks SQL Server to scan a table just to count rows. Safe to point at a primary or a readable secondary.
Reads your schemas in place
No tables to refactor, no data pipeline to stand up, no server-side changes. Point DecisionBox at a database and a schema, and the agent picks up your tables on its first run — and re-checks them on every run after. Metadata is read from INFORMATION_SCHEMA, not from full table scans.
Five things the agent does so it stays out of your way.
SQL Server is most often a transactional database that something else is already depending on. Every default in the provider is set so a discovery run cannot disturb that workload — small pool, short timeouts, fast metadata reads, encrypted connection, read-only at the login level.
sys.dm_db_partition_stats — fast, engine-maintained counts, with a sys.partitions catalog-view fallback for logins without VIEW DATABASE STATE. No full table scan just to read a row count.encrypt=true out of the box, with strict available. Leave Trust Server Certificate at false in production so the certificate is actually validated.SELECTs. The SELECT-only login you give it is the second, server-enforced layer.These are the provider's built-in defaults, tuned for an agent that is sharing a database with a live application — a small pool, a short per-query timeout, and metadata-only reads. A discovery run stays well inside the headroom a production server already has.
Two ways in. Both standard SQL Server.
Pick the one that matches how you already hand SQL Server credentials to the rest of your stack. Both options end at the same login and schema you configured — what changes is whether you fill in the connection fields one at a time or paste a full sqlserver:// connection string.
SQL Login (Username / Password)
Fill in host, port, database, user, schema (defaults to dbo), and the encrypt setting in the project config, then paste the password as the credential. The password is stored encrypted and never written to logs.
Connection String
Paste a full sqlserver:// URL — sqlserver://user:pass@host:1433?database=db — as the credential. Use it for Azure SQL Database, a named instance, or any setup that needs extra TDS parameters as query options.
Both options end at the same SQL Server login and schema you configured — SELECT on the tables you opted in, and nothing more. If your security team has already approved how the rest of your stack talks to this database, they have already approved DecisionBox.
Open source, and not SQL Server-only.
Open source, AGPL v3
Every line of the SQL Server integration — the login and connection-string auth flow, the INFORMATION_SCHEMA metadata reads, the T-SQL the agent writes — is in the public repo. Anyone can read and audit it before turning it on.
Not locked to SQL Server
The same agent runs against any of them. If your warehouse moves, your DecisionBox install moves with it.
Try it on your SQL Server, in two minutes.
Clone the repo, run docker compose up, and point it at a SQL Server host and a read-only login. Encryption is on by default; nothing else to configure.