Trust & Security
TDS 8.0 and SQL Server 2025 transport security
How BuildWithHQ protects service-to-database traffic with SQL Server 2025, TDS 8.0, strict encryption, and layered authorization.
BuildWithHQ uses Microsoft SQL Server 2025 for its database layer and the TDS 8.0 strict-encryption model for production service-to-database traffic. Customers do not connect their browser or app directly to SQL Server. BuildWithHQ APIs and workers establish the database sessions on their behalf, so the transport policy is applied centrally and cannot be weakened by an end-user setting.
Where BuildWithHQ uses TDS
TDS carries traffic between authorized BuildWithHQ backend services and the appropriate database plane: the platform control plane, Template Library, Platform Orchestration, SaaS database, SaaS Vector DB, or SaaS Immutable Logs. Frontends receive bounded API responses; they never receive a SQL connection string, database credential, physical database name, or a way to select a database route.
How the connection is protected
Production SQL connections require strict encryption and certificate validation. TDS 8.0 begins TLS before the traditional TDS pre-login exchange, keeping negotiation, authentication, commands, and results inside the encrypted session. BuildWithHQ uses the expected SQL Server hostname when validating the certificate and does not use TrustServerCertificate as a production bypass. A certificate that is expired, untrusted, or issued for the wrong name must cause the connection to fail closed.
SQL Server 2025 and TDS 8.0 support TLS 1.3 when the operating system and client driver support it, with TLS 1.2 as the compatible protocol floor for the strict TDS 8.0 path. BuildWithHQ pins supported drivers for services and workers rather than assuming that server settings can upgrade an incompatible client.
Encryption is paired with least privilege
An encrypted connection is not automatically an authorized connection. Each BuildWithHQ service identity receives object-level permission only for its reviewed stored procedures. Browsers cannot issue SQL, controllers do not perform ad-hoc data changes, and tenant, SaaS app, user, DataRole, and location scope are derived again on the server. Separate database planes and per-tenant routing limit which data a compromised service path could reach.
How BuildWithHQ validates the control
- Release checks lock database identities, procedure signatures, driver expectations, and object-level grants to the current database exports.
- Deployment validation checks the production certificate chain, validity period, intended hostname, and strict connection behavior.
- Health monitoring verifies that required database dependencies remain reachable without returning connection strings, credentials, or tenant data.
- Operational paths such as workers, jobs, recovery tooling, and replicas must use the same encrypted posture; an application-only check is not treated as complete coverage.
What customers can verify
Managed-hosting customers do not need SQL access to test this control. Security reviewers can request BuildWithHQ’s current transport configuration statement and redacted release or deployment evidence. Appliance operators receive the corresponding server-certificate and strict-encryption deployment requirements because they control the SQL Server host; ordinary users still do not handle database credentials.
What TDS does not replace
TDS protects data while it moves between BuildWithHQ services and SQL Server. It does not decide which records a person can read and does not protect database or backup files at rest. BuildWithHQ therefore combines TDS transport protection with server-derived authorization, DataRoles, location scope, reviewed stored procedures, field controls, audit evidence, and database/backup protection.
Microsoft references
- TDS 8.0 in SQL Server
- Connect using strict encryption
- TLS 1.3 support
- SQL Server security best practices