Technical Reference

Deployment & permissions

Everything your team needs to evaluate, deploy, and operate SIXTA. Database privileges, network requirements, autonomous actions, and audit logging — in one place.

Data Flow Permissions Network Autonomous Actions Extensibility Audit Logging Support Setup Timeline
01
Data flow

A summary of what data SIXTA collects, where it goes, and what never leaves your network.

No PII collection: SIXTA does not access or collect personally identifiable information. It reads only performance metadata, query fingerprints, schema structure, and configuration values. PII is excluded by the way SIXTA queries your databases — not filtered after the fact.

Database telemetry

Query performance metrics, execution plans, lock and session data, replication status, schema metadata, capacity metrics. Collected directly from PostgreSQL and MySQL via read-only connections.

Stays local — processed within your infrastructure

LLM reasoning context

Performance metadata, query fingerprints, table names, and configuration values are sent as tool context for root-cause analysis and recommendation generation. No PII is collected or transmitted.

Sent to configured LLM endpoint (Anthropic API, internal, or local)

Findings and recommendations

Root-cause analysis, remediation recommendations, alerts, and status updates. Delivered as structured messages to your team's workflow, or available programmatically via API for custom interfaces.

Delivered to Slack, Microsoft Teams, API, or your own systems

Observability enrichment

Metrics, logs, APM traces, incidents, and SLO data ingested from your existing monitoring platforms. Enriches SIXTA's diagnostics by correlating database anomalies with infrastructure events, deployment activity, and application-level signals.

Pulled from AWS CloudWatch / Performance Insights / Datadog / Percona PMM

No row-level data access

Your business data in tables is never read or transmitted

No PII collection

Excluded by design — not filtered after the fact

No SIXTA telemetry

SIXTA does not send usage data, metrics, or diagnostics back to SIXTA the company
02
Access & credentials

SIXTA uses two distinct access levels for databases. Read-only is required and covers all diagnostic capabilities. Autonomous permissions are optional, separately credentialed, and only needed if you enable autonomous actions. SIXTA can also integrate with your observability platform for enriched diagnostics.

PostgreSQL MySQL Datadog Percona PMM AWS
PostgreSQL

One GRANT pg_monitor plus the pg_stat_statements extension covers the entire read-only surface. Autonomous privileges are additive — grant only what you enable.

Privilege What it enables Mode
pg_monitor role Visibility into pg_stat_activity (all sessions), pg_stat_replication, and other stats views Read-only
SELECT on pg_stat_statements Query risk analysis and performance baselining. Requires the pg_stat_statements extension to be installed by your DBA. Read-only
Standard catalog access pg_class, pg_locks, pg_database are readable by any connected role. pg_settings, pg_stat_user_tables, pg_stat_database, and other pg_stat_* views require pg_read_all_stats and pg_read_all_settings for full visibility — both included in pg_monitor. Read-only
pg_table_size(), pg_total_relation_size(), pg_indexes_size() Capacity and growth tracking. Available to all roles by default. Read-only
ALTER SYSTEM on specific parameters (PG 15+) or superuser (PG 14 and below) Required for ALTER SYSTEM SET and pg_reload_conf(). In PostgreSQL 15+, superuser can grant ALTER SYSTEM privilege on individual parameters to a non-superuser role, enabling least-privilege tuning. In earlier versions, only superuser can modify server parameters. This role is separate from the diagnostic role and never used for read-only operations. Autonomous — tuning
Table ownership on target tables Required for CREATE INDEX CONCURRENTLY. PostgreSQL requires the index creator to own the table. In practice, the autonomous role is granted ownership of the specific tables where SIXTA manages indexes. Autonomous — indexes
pg_signal_backend role Required for pg_terminate_backend() to terminate runaway queries. Cannot terminate superuser sessions. Autonomous — query termination
Table ownership or MAINTAIN (PG 17+) Required for VACUUM and ANALYZE on specific tables. Alternatively, superuser covers this. Autonomous — maintenance
MySQL

Minimum read-only: SELECT on performance_schema and sys, plus PROCESS and REPLICATION SLAVE. No grant needed for information_schema. Autonomous privileges are additive.

Privilege What it enables Mode
SELECT on performance_schema.* and sys.* Query performance data (wait events, statement history, thread activity) and the sys schema's aggregated diagnostic views. information_schema is accessible to all users by default — no explicit grant required. Read-only
PROCESS Visibility into all active connections and sessions. Enables SHOW ENGINE INNODB STATUS, access to INFORMATION_SCHEMA InnoDB tables, and EXPLAIN FOR CONNECTION for execution plans on running queries. Note: a known MySQL bug may require SUPER for EXPLAIN FOR CONNECTION in some versions. Read-only
REPLICATION SLAVE Topology detection via SHOW REPLICAS. Required for replication-aware diagnostics. Read-only
SYSTEM_VARIABLES_ADMIN (8.0+) or SUPER (5.7) Runtime parameter tuning via SET GLOBAL. Only required if autonomous parameter tuning is enabled. Autonomous — tuning
INDEX on target schema(s) Required for CREATE INDEX and DROP INDEX. Scoped to specific schemas. Autonomous — indexes
CONNECTION_ADMIN (8.0+) or SUPER (5.7) Required for KILL to terminate runaway queries. Autonomous — query termination

With these grants, SIXTA can read query text from events_statements_history and generate execution plans for running queries via EXPLAIN FOR CONNECTION.

Datadog

When configured, SIXTA ingests observability data from your Datadog environment to enrich diagnostics — correlating database anomalies with metrics, deployments, application traces, and incident history. Requires an API Key, a scoped Application Key (ideally tied to a service account), and your Datadog site identifier.

Application Key scope What it enables Required
metrics_read Baseline metrics and timeseries queries — CPU, connections, throughput, and custom metrics your team tracks Core
events_read Events such as failovers, deployments, and configuration changes — used for incident correlation Core
monitors_read Your existing alert configurations — helps SIXTA understand what your team already tracks and cares about Core
dashboards_read Dashboard definitions — provides context on which metrics and views your team prioritises Core
logs_read_data, logs_read_index_data Slow query logs, error logs, Aurora-specific issues, and application errors forwarded to Datadog Log Management If using Log Management
apm_read APM traces — lets SIXTA trace which application endpoints drive database load and correlate anomalies to specific services If using APM
incident_read Incident history — correlates SIXTA's anomaly detection with real incidents your team has handled, and enables lookback analysis If using Incident Management
slos_read SLO definitions and status — provides reliability targets as context for risk assessment and prioritisation. Verify this scope is available for your Datadog plan. If using SLOs

All Datadog scopes are read-only. SIXTA never writes to, modifies, or creates resources in your Datadog environment.

Percona PMM

When configured, SIXTA connects to your PMM Server to ingest infrastructure metrics, query analytics (QAN), and inventory data. Authentication is via a Grafana Service Account Token (prefixed glsa_) assigned the Viewer role. SIXTA connects to the PMM Server API only — no direct access to PMM Clients is required.

Data source API endpoint What it enables
Infrastructure metrics Prometheus-compatible query API
/select/0/prometheus/api/v1/query
/select/0/prometheus/api/v1/query_range		 CPU, IOPS, connections, replication lag, and all other metrics collected by PMM exporters. Supports instant and range queries via VictoriaMetrics endpoints.
Query Analytics (QAN) QAN API Query fingerprints, execution times, wait event breakdowns, and per-query performance metrics. QAN data is collected by PMM Client agents from performance_schema or slow query logs and stored in ClickHouse on the PMM Server.
Inventory /v1/inventory/nodes
/v1/inventory/services		 Node and service metadata — monitored instances, database engines, versions, and topology. Used for environment mapping and correlation.
Alerts and advisors Alerting and advisor APIs Fired alerts and advisor check results — helps SIXTA understand what your PMM environment is already flagging and correlate with its own anomaly detection.

The Viewer role provides read-only access to all metrics, dashboards, QAN data, and alerts. SIXTA cannot modify configurations, add services, manage alerts, or make administrative changes. Access can be further restricted using PMM's Label-Based Access Control (LBAC) to limit visibility to specific environments or service types via Prometheus label selectors.

AWS (RDS instances)

When monitoring AWS-hosted databases, SIXTA uses read-only AWS API access to collect metrics, logs, and instance metadata from your account. Authentication is via IAM User access keys, IAM Role (recommended for EC2/ECS deployments), or AWS CLI profile.

Service IAM actions What it enables
CloudWatch cloudwatch:GetMetricData, cloudwatch:ListMetrics CPU, IOPS, latency, and other RDS instance metrics
CloudWatch Logs logs:FilterLogEvents, logs:GetLogEvents Enhanced Monitoring OS-level metrics (CPU per process, memory, filesystem). Scoped to RDSOSMetrics log group.
Performance Insights pi:GetResourceMetrics, pi:DescribeDimensionKeys, pi:GetDimensionKeyDetails Top queries by load, wait event analysis, and dimension breakdowns. Requires Performance Insights to be enabled on the RDS instance.
RDS rds:DescribeDBInstances, rds:DescribeEvents Instance metadata (engine, version, class, storage, parameters) and RDS events (failovers, maintenance, configuration changes)

All AWS permissions are read-only. The IAM policy can be scoped to a single RDS instance for rds:DescribeDBInstances, and Performance Insights can be scoped to specific database resources via ARN. CloudWatch metrics permissions (GetMetricData, ListMetrics) require Resource: "*" because AWS does not support resource-level restrictions for these actions — SIXTA only queries the instances you configure.

RDS prerequisites: Performance Insights (recommended) and Enhanced Monitoring (optional) should be enabled on your RDS instance for full diagnostic depth. Both are enabled via the RDS console.

03
Network & deployment

SIXTA deploys inside your infrastructure as a container or VM. All database telemetry is processed locally. Certain integrations (Slack, Microsoft Teams) require a connection to api.sixta.ai for message coordination. With a local model and custom integrations, SIXTA can operate with zero external connections.

Outbound connections
Destination Purpose Notes
api.slack.com Delivering findings, recommendations, and alerts to your Slack workspace HTTPS. Required if using Slack integration.
Microsoft Teams API Delivering findings, recommendations, and alerts to your Teams channels HTTPS. Required if using Teams integration.
api.sixta.ai Message coordination for Slack and Microsoft Teams integrations. Handles websocket connectivity for real-time interaction. No database telemetry or customer data is transmitted. HTTPS/WSS. Required only when using Slack or Teams. Not required for custom integrations or API-only access.
LLM reasoning endpoint Reasoning engine for root-cause analysis, recommendation generation, and investigation. SIXTA does not collect personally identifiable information — only performance metadata, query fingerprints, and configuration values are sent as tool context. See model deployment options below.
AWS regional endpoints CloudWatch metrics and logs, Performance Insights, and RDS APIs. See AWS permissions for exact IAM actions. HTTPS. Only when AWS-hosted instances are configured. Authenticates via IAM Role, access keys, or CLI profile.
Datadog API Ingest metrics, logs, APM traces, incidents, and SLO data from your existing Datadog environment HTTPS. Only when Datadog integration is configured. Uses your API Key and scoped Application Key.
Percona PMM Server Ingest infrastructure metrics, Query Analytics (QAN) data, inventory, and alerts from your PMM environment. See PMM permissions for details. HTTPS (port 443). Only when PMM integration is configured. Authenticates via Grafana Service Account Token with Viewer role.
Customer databases PostgreSQL, MySQL connections via native protocols Within your VPC. Uses credentials you provide.
Model deployment options

SIXTA's reasoning engine is model-flexible. You choose where the LLM runs based on your data residency and network requirements.

Option How it works Outbound impact
Anthropic API Default SIXTA connects to api.anthropic.com. Tool context is sent as conversation context over HTTPS. Requires outbound HTTPS to api.anthropic.com
Your internal model Point SIXTA at your organisation's existing LLM endpoint — self-hosted or private cloud. SIXTA uses a standard API interface compatible with common model serving frameworks. Internal network only. No external LLM traffic.
Local model Run a model on the same host or within the same network segment as the SIXTA agent. All reasoning stays within your infrastructure boundary. None. Fully air-gapped LLM reasoning.

SIXTA does not collect personally identifiable information. The data sent to the reasoning engine consists of performance metadata, query fingerprints, table names, and configuration values — PII is excluded by design, not filtered after collection. When using a local or internal model, no database context leaves your network at all. The choice of model may affect reasoning quality for complex root-cause analysis.

Inbound connections

None required. No inbound firewall rules needed.

Compute requirements
Resource Requirement
Deployment Container (Docker / ECS / EKS) or VM
CPU 2 vCPU typical
Memory 4 GB RAM typical
GPU Not required

Scales with number of monitored instances. Contact us for guidance on larger estates.

04
Autonomous actions & guardrails

SIXTA operates in three modes: Observe (read-only diagnostics), Recommend (analysis with human review), and Act (autonomous execution with guardrails). Each action type is individually gated — you enable exactly what you want.

Observe — read-only, default

All diagnostic capabilities. Query plan analysis, lock and session inspection, replication health monitoring, capacity assessment, baseline learning. No database modifications of any kind.

Recommend — human review

SIXTA produces specific remediation SQL — covering indexes, parameter changes, vacuum priorities — and delivers it to your Slack or Teams workflow. Your team reviews and executes.

Act — autonomous, opt-in
Action What it does Rollback Status
Parameter tuning ALTER SYSTEM SET (PostgreSQL) / SET GLOBAL (MySQL) / ModifyDBParameterGroup (AWS RDS). Dry-run by default. Previous values recorded for rollback. Automatic. Previous values stored and restorable. Live
Index creation CREATE INDEX CONCURRENTLY. SIXTA's query risk analyzer produces the exact DDL with risk classification. Drop the created index. Planned
Query termination Terminate runaway queries exceeding defined thresholds. N/A — query can be re-executed by the application. Planned
Vacuum execution Execute VACUUM / ANALYZE based on SIXTA's vacuum advisor recommendations. N/A — maintenance operation, always safe to run. Planned

For planned actions, SIXTA's diagnostic tools produce the exact SQL today and deliver it via Recommend mode. Autonomous execution is gated behind approval workflows under development.

05
Extensibility

SIXTA's action layer accepts custom scripts and binaries via a manifest-based registry. Registered actions inherit the same progressive trust model, approval workflows, and audit logging as built-in database operations.

Concept How it works
Action manifest Each custom action is registered with a manifest that declares its inputs, risk classification, and approval requirements. SIXTA applies the same guardrails and audit logging as built-in actions.
Custom scripts and binaries Add executables to SIXTA's action registry. Examples include failover procedures, backup verification, certificate rotation, custom health checks, cache invalidation, and team-specific remediation playbooks.
Trust model inheritance Custom actions use the same Observe → Recommend → Act progression. SIXTA can recommend executing a registered script with reasoning, or run it autonomously if that action type is enabled. Every invocation is logged with the standard audit schema.
Context-aware scheduling Recurring operational tasks — partition maintenance, post-deploy verification, periodic restarts — can be registered as SIXTA actions. SIXTA triggers them based on environment conditions rather than fixed schedules.

Custom actions are subject to the same approval workflows and risk thresholds as built-in actions. SIXTA cannot execute anything that has not been explicitly registered and permitted.

06
Audit logging

Every tool invocation is recorded with full context. Two log schemas are shown below: one for general diagnostic actions and one for parameter changes. These schemas represent the current implementation and will evolve — approval status, risk assessment scores, and recommendation delivery tracking will be added as approval workflows are implemented.

General action log

Recorded for every SIXTA tool invocation. Default retention: 90 days.

id ULID // time-sortable unique ID timestamp UTC ISO 8601 tool string // "vacuum_advisor" | "tune_apply" | "query_risk_analyzer" | ... instance_id string // logical name, e.g. "prod-pg" action_kind string // "result" (auto-stored tool output) severity enum // "info" | "warn" | "critical" params JSON // original invocation parameters data JSON // full tool output (complete assessment/result) summary string // one-line human-readable description db_engine enum // "postgresql" | "mysql" expires_at timestamp // 90 days default
Parameter change log

Recorded for every tune-apply and rollback operation. Provides full before/after state.

id UUID timestamp UTC ISO 8601 action enum // "apply" | "rollback" dry_run boolean // true = simulated, no changes made instance object // { host, user, database } score_before number // fitness score before change workload enum // "oltp" | "olap" | "mixed" | "web" changes array // per-parameter detail: knob string // e.g. "shared_buffers" previous_value string // e.g. "128MB" new_value string // e.g. "1GB" applied boolean // false if skipped error string // e.g. "requires restart" rolled_back boolean rollback_id UUID // links to the rollback entry that reversed this
Planned additions

As approval workflows are implemented, the following fields will be added across both log schemas:

Field Purpose
approved_by Identity of the user who approved the action (when approval workflows are enabled)
approval_status Whether the action was auto-approved, manually approved, or pending
risk_score Pre-action risk assessment — impact radius, reversibility, and historical success rate
policy_id Reference to the guardrail policy that governed the action
recommendation_id Link to the recommendation that triggered the action, enabling end-to-end traceability from finding to execution
07
Support & reliability

SIXTA is in design partner stage. Support is direct, responsive, and hands-on — not routed through a ticketing system. Here is what we commit to today and what we are building toward.

Current support model
Aspect What we offer
Channels Shared Slack channel (day-to-day) and email (support@sixta.ai) for formal requests. You work directly with the engineering team, not a support queue.
Hours Monday to Friday, US Eastern timezone business hours.
First response Within 1 hour during business hours for any reported issue.
Outside hours Best-effort. We monitor for critical issues but cannot guarantee response times on evenings or weekends.
Onboarding Every design partner is onboarded directly by the SIXTA team. We configure deployment, validate permissions, and stay hands-on through baselining.
Incident response — SIXTA-initiated actions

When SIXTA operates in autonomous mode, incident response behaviour is configurable per action type:

Mode Behaviour When to use
Auto-rollback If SIXTA detects that an autonomous action caused degradation, it automatically rolls back the change and notifies your team with full context (what changed, what was observed, what was reversed). Parameter tuning and other reversible operations where speed of recovery matters.
Notify-only SIXTA flags the issue and provides its assessment, but leaves the rollback decision to your team. Actions where human judgement is preferred before reverting, or where rollback has its own risk.

Both modes are configurable per action type and per environment. Every autonomous action and its outcome — including rollbacks — is recorded in the audit log.

Roadmap

As SIXTA matures beyond the design partner programme, we plan to introduce formal support tiers with contractual response and resolution commitments. If your organisation requires a formal SLA for evaluation or procurement, contact us — we are open to structuring agreements that reflect the level of support we already provide.

08
Setup timeline

SIXTA is onboarded like a team member. It builds understanding progressively and gets more accurate over time.

Connect
Hours
Deploy the SIXTA container or VM in your infrastructure. Establish read-only database connections. Verify network connectivity to Slack/Teams and Anthropic APIs. Initial telemetry collection begins immediately.
Baseline
Days
SIXTA maps your database topology, catalogs query patterns, and builds an initial baseline of normal behaviour. Time-of-day and day-of-week patterns begin to emerge. Anomaly detection starts distinguishing real problems from routine workload variation.
Deep understanding
2–4 weeks
Full environment understanding. SIXTA recognises seasonal patterns, correlates incidents with deploy events, and builds institutional knowledge from every investigation. Recommendations improve in accuracy and specificity as context accumulates.

Ready to get started?

Connect your first database and see SIXTA working alongside your team in minutes.

Connect Your First Database