In-VPC Architecture: A Deep-Dive

Why Your Data Should Stay in Your VPC

The traditional data warehouse model requires you to upload your data to a vendor's cloud. Your tables, your queries, and your results all pass through infrastructure that someone else controls. For many organizations — especially those in regulated industries — this is an increasingly uncomfortable arrangement. Data residency requirements, compliance obligations, and simple security hygiene all argue for keeping sensitive data within your own network boundary.

But running a data warehouse entirely on your own infrastructure means giving up the management, scaling, and feature velocity that cloud services provide. You end up maintaining database clusters, managing upgrades, monitoring performance, and debugging operational issues — all things that distract from your actual work.

HatiData resolves this tension with a two-plane architecture: the data plane runs inside your VPC, while the control plane runs in HatiData's cloud. Your data never leaves your network. Management, billing, and feature updates come from HatiData. The two planes communicate through a narrow, encrypted control channel.

The Two-Plane Model

Data Plane (Your VPC)

The data plane is a single native binary that runs on a VM or container within your VPC. It speaks the Postgres wire protocol and executes queries against HatiData's embedded columnar engine backed by high-performance local SSD storage.

The data plane handles:

• Query execution — SQL queries are parsed, transpiled (if needed), and executed against the query engine
• Memory storage — Agent memories are written to the engine and embedded via the embedding service
• Vector search — A vector index runs alongside the proxy for approximate nearest neighbor operations
• CoT logging — Reasoning traces are stored in append-only tables
• Branch isolation — Isolated schemas provide sandboxed environments for agent exploration

Everything the agent interacts with — data, memories, reasoning logs, branches — lives on the data plane. No query data, no results, and no agent memories ever leave your VPC.

Your VPC
+--------------------------------------------------+
|                                                  |
|  Agent ──> HatiData Proxy                        |
|                |                                 |
|                +──> Query Engine (SSD-backed)     |
|                |                                 |
|                +──> Vector Index                  |
|                |                                 |
|                +──> Embedding Service             |
|                |                                 |
|                +──> MCP Server                    |
|                                                  |
+--------------------------------------------------+
         |  Control channel (TLS, metadata only)
         v
+--------------------------------------------------+
|  HatiData Cloud                                  |
|                                                  |
|  Control Plane                                   |
|    +── Billing                                   |
|    +── Auth (WorkOS)                             |
|    +── Dashboard                                 |
|    +── Org management                            |
|    +── Feature flags                             |
|                                                  |
+--------------------------------------------------+

Control Plane (HatiData Cloud)

The control plane is a managed API with 100+ endpoints. It handles everything that does not require access to your data:

• Authentication — WorkOS-based SSO, SAML, OIDC, SCIM directory sync
• Billing — Per-second billing, usage metering, quota management
• Organization management — Multi-tenant org structure, member management, API key issuance
• Dashboard — Web UI for monitoring agents, viewing CoT replays, managing triggers
• Feature configuration — Tier-based feature gating, policy templates, cloud region settings

The control plane never sees your data. It receives aggregated metrics (query counts, latency percentiles, storage usage) but never query text, results, or agent memories.

Postgres Wire Protocol Compatibility

The data plane speaks the Postgres wire protocol. This means any tool or library that connects to PostgreSQL can connect to HatiData without modification. psql, DBeaver, DataGrip, Python's psycopg2, Node's pg library, Go's pgx — they all work out of the box.

# Connect with psql
psql -h localhost -p 5439 -U admin -d hatidata

# Query as if it were PostgreSQL
SELECT namespace, COUNT(*) AS memories
FROM agent_memories
GROUP BY namespace
ORDER BY memories DESC;

The proxy translates between the Postgres wire protocol and the engine's native API. For most queries, this translation is transparent — standard SQL works as expected. For queries using features specific to other SQL dialects, HatiData's transpiler converts them automatically.

The Multi-Stage Query Pipeline

Every query that enters the data plane passes through a multi-stage pipeline before results are returned. The pipeline is organized into five groups, each enforcing a different concern:

Admission

• Concurrency control — Prevents resource exhaustion from too many simultaneous queries
• Query analysis — Identifies which tables the query references for subsequent checks

Security

• Policy evaluation — ABAC policies are evaluated against the query, agent identity, and table attributes
• Row filtering — Automatic namespace and row-level security filters are injected into the query

Processing

• Cost estimation — Query complexity is estimated before execution for quota deduction
• Quota enforcement — Agent's remaining quota is verified against the estimated cost
• Transpilation — SQL dialect differences are resolved automatically

Execution

• Query execution — The query runs against the engine with snapshot isolation for consistent reads
• Auto-healing — If the query fails, the error is analyzed and a corrected query is attempted automatically

Post-Processing

• Column masking — Sensitive columns are masked or redacted based on the agent's permissions
• Metering — Actual resource consumption is recorded for billing
• Audit logging — The complete query lifecycle is logged for compliance

Each stage is implemented as an independent middleware, making the pipeline extensible and testable. Stages can be skipped based on configuration — for example, cost estimation and quota checks are disabled in free-tier deployments.

High-Performance SSD Storage

The query engine's performance depends heavily on storage I/O, particularly for analytical queries that scan large tables. HatiData deploys on instances with high-performance local SSD storage to maximize I/O throughput.

On managed Kubernetes deployments, a DaemonSet configures local SSDs with optimal formatting and mount options. The engine's data directory is mapped to the SSD volume, giving the database direct access to the fastest available storage.

Each major cloud provider offers instance types optimized for local storage throughput. HatiData's deployment automation selects the optimal instance family for each provider, ensuring consistent performance regardless of which cloud you deploy on.

Private Network Connectivity

For production deployments where even DNS-level network exposure is unacceptable, HatiData supports private network connectivity on all three major clouds:

• AWS PrivateLink — The data plane is exposed as a VPC endpoint service. Agents in the customer's VPC connect through an interface endpoint with private DNS.
• GCP Private Service Connect — Similar to AWS PrivateLink, using Google's private networking fabric.
• Azure Private Link — The data plane is accessible through a private endpoint in the customer's VNet.

Private connectivity ensures that traffic between agents and the data plane never traverses the public internet. The connection is entirely within the cloud provider's backbone network, with no public IP addresses involved.

Multi-Cloud Deployment

HatiData supports deployment on AWS, GCP, and Azure. Each cloud has dedicated infrastructure-as-code modules for compute, networking, storage, and security.

The deployment is configured through a single variables file that specifies the cloud provider, region, and instance types. The infrastructure modules handle cloud-specific implementation details — networking, IAM, storage — while presenting a consistent interface.

A single HatiData organization can run data planes in multiple clouds simultaneously. An agent connecting to the US-East data plane gets its data from one cloud region, while an agent connecting to the APAC data plane gets its data from another. The control plane manages both through the same dashboard.

Auto-Suspend and Per-Second Billing

The data plane supports auto-suspend to minimize costs during idle periods. When no queries have been received for a configurable interval (default 5 minutes), the proxy enters a suspended state where the engine releases memory and the compute instance scales down.

When the next query arrives, the proxy resumes within seconds — the engine reloads its metadata and the query executes normally. The agent experiences a slightly higher latency on the first query after suspension, but subsequent queries run at full speed.

Billing is per-second, based on actual compute consumption. There is no minimum commitment, no hourly rounding, and no charge during suspended periods. This model is particularly advantageous for agent workloads, which tend to be bursty — intense query activity during task execution, followed by idle periods between tasks.

Next Steps

The two-plane architecture is the foundation for all of HatiData's security and compliance capabilities. For deployment guides specific to your cloud provider, see the multi-cloud documentation. For a hands-on introduction, install HatiData locally with the CLI and run your first queries — the local deployment uses the same data plane binary, just without the cloud control plane.