DocumentationMumbai
Database Engine
PostgreSQL 16Scale-to-Zero

ExoStore Serverless Database

ExoStore is Exovon's managed, auto-scaling PostgreSQL 16 engine powered by Neon. Hosted in Singapore (aws-ap-southeast-1) with ~35–60ms transit latency to our Mumbai compute, ExoStore separates compute from storage, autosuspends to 0 compute billing when idle, and provides both connectionless HTTP endpoints and pooled TCP sockets.

Stateless HTTP Data API

Execute queries via HTTPS POST requests without holding open persistent TCP socket connections. Eliminates connection pool exhaustion in serverless edge runtimes.

Just-In-Time (JIT) Security

Administrative passwords and tokens are leased on-demand, cached in-memory with short 5-minute TTLs, and never hardcoded in client code or source repositories.

Scale-to-Zero Autosuspension

Compute instances automatically pause after 5 minutes of inactivity to eliminate idle compute consumption, resuming in ~300ms upon incoming traffic.

Provisioning a Database Cluster

You can provision a dedicated PostgreSQL cluster directly from your Exovon project console with one click:

  1. Open your Project Dashboard on exovon.in/dashboard.
  2. Select the Exostore DB item from the sub-sidebar.
  3. Click Provision Database Cluster.
  4. Exovon provisions an isolated database cluster in Singapore (aws-ap-southeast-1 via Neon), configures default schema roles, and automatically mounts the secure DATABASE_URL into your project's environment variables.

Connecting from Your Application

ExoStore supports multiple connection paradigms depending on your framework and runtime environment.

Recommended for Next.js & Edge

Method 1: Serverless HTTP Driver

@neondatabase/serverless

The serverless HTTP driver sends queries over HTTPS (port 443). Because it does not maintain persistent TCP sockets, you can run thousands of concurrent Server Actions or edge route handlers without ever hitting PostgreSQL connection limits.

1. Install package:

Terminal
npm install @neondatabase/serverless

2. Query in Server Actions or Route Handlers (app/api/users/route.ts):

app/api/users/route.ts
import { neon } from '@neondatabase/serverless';
import { NextResponse } from 'next/server';

export async function GET() {
  // DATABASE_URL is automatically injected by Exovon Cloud
  const sql = neon(process.env.DATABASE_URL!);
  
  // Safe tagged template query with automatic parameterized escaping
  const users = await sql`
    SELECT id, email, created_at 
    FROM users 
    ORDER BY created_at DESC 
    LIMIT 20
  `;

  return NextResponse.json({ users });
}

Method 2: Drizzle ORM (Type-Safe)

drizzle-orm

Drizzle ORM pairs natively with ExoStore via the drizzle-orm/neon-http driver for end-to-end TypeScript type safety without heavy engines.

lib/db.ts
// lib/db.ts
import { neon } from '@neondatabase/serverless';
import { drizzle } from 'drizzle-orm/neon-http';
import * as schema from './schema';

const sql = neon(process.env.DATABASE_URL!);
export const db = drizzle(sql, { schema });

// Usage in your application:
// const activeUsers = await db.select().from(schema.users).where(eq(schema.users.isActive, true));

Method 3: Prisma ORM

prisma

When using Prisma with serverless deployments, use the Pooled Connection URL (port 6543) for runtime queries, and the Direct URL (port 5432) for running schema migrations.

prisma/schema.prisma
// prisma/schema.prisma
datasource db {
  provider  = "postgresql"
  url       = env("DATABASE_URL")        // Pooled connection (port 6543)
  directUrl = env("DIRECT_DATABASE_URL") // Direct connection for migrations (port 5432)
}

generator client {
  provider = "prisma-client-js"
}

Connection Pooling Architecture: Pooled vs. Direct Endpoints

ExoStore clusters provide two distinct endpoints to optimize different database workloads:

Pooled Endpoint (Port 6543)

Routed through an integrated PgBouncer pooler. Supports up to 10,000 concurrent client connections using transaction-mode pooling. Use this for all production serverless application traffic, Next.js Server Components, and API routes.

Direct Endpoint (Port 5432)

Connects directly to the PostgreSQL compute instance. Necessary for long-lived operations, session-level variables, LISTEN/NOTIFY commands, and schema migration tools like prisma migrate or drizzle-kit push.

Stateless Serverless HTTP Data API

Every ExoStore compute endpoint exposes an HTTP Data API at https://<endpointHost>/sql. You can execute SQL queries directly over HTTP without installing database drivers, connection pools, or ORMs.

cURL / Raw HTTP Example

cURL Request
curl -X POST "https://ep-delicate-butterfly-b37cr2zm.c-4.ap-southeast-1.aws.neon.tech/sql" \
  -H "Authorization: Bearer ${EXOVON_DB_TOKEN}" \
  -H "Content-Type: application/json" \
  -d '{
    "query": "SELECT id, name, created_at FROM users WHERE active = $1 LIMIT 5",
    "params": [true]
  }'

TypeScript / Fetch Example

TypeScript Fetch
const response = await fetch("https://" + process.env.EXOVON_DB_HOST + "/sql", {
  method: "POST",
  headers: {
    "Content-Type": "application/json",
    Authorization: `Bearer ${process.env.EXOVON_DB_TOKEN}`,
  },
  body: JSON.stringify({
    query: "SELECT id, email, role FROM team_members WHERE team_id = $1",
    params: [teamId],
  }),
});

const { rows } = await response.json();

Cluster Telemetry & Monitoring Suite

The Monitoring tab provides real-time cluster observability across 11 key operational metrics:

1. RAM (GB)

Allocated capacity (4 GB), active used RAM, and buffer cache footprint.

2. CPU (vCPUs)

vCPU consumption curve tracking active transaction threads.

3. Deadlocks (Count)

Stepped lock contention monitor; clean zero confirms serializable execution.

4. Rows (Count)

Mutation throughput tracking rows inserted, updated, and deleted.

5. Compute Cache Hit Rate (%)

Percentage of reads served instantly from RAM buffers (> 99% is nominal).

6. Working Set Size (GB)

Active working data relative to Local File Cache (3.5 GB) and Shared Buffers (0.25 GB).

7. Pooler Client Connections

Active and waiting client sockets connected to the PgBouncer multiplexer (max 10,000).

8. Postgres Connections Count

Active, idle, and total backend processes against the 450 max ceiling.

9. Pooler Server Connections

Dedicated backend connections held by PgBouncer to PostgreSQL.

10. Database Size (MB)

Disk storage footprint of the active database vs total cluster databases.

The 45° Diagonal Hatch: Endpoint Inactive State

When your database engine autosuspends to 0 compute billing, historical charts render the inactive timeframe with a 45° diagonal hatch pattern labeled ENDPOINT INACTIVE. This confirms that compute was halted and zero idle compute billing occurred during that interval.

Scale-to-Zero & Background Polling Guardrails

ExoStore automatically shuts down compute after 5 minutes of inactivity. To preserve this cost-saving architecture, developers and autonomous AI agents must adhere to strict polling guardrails:

Rule 1: Never Poll the Database When Inactive

Executing continuous SELECT 1 health checks or telemetry queries every 5–10 seconds prevents the compute instance from ever entering autosuspend, keeping compute active unnecessarily.

Rule 2: Gate on Cached State First

Check the project's cached endpointState in Firestore. If the status is suspended, suppress all telemetry queries and display the Scale-to-Zero state without issuing queries to the database.

Rule 3: Transparent Auto-Wake

When legitimate user traffic arrives, the cluster wakes automatically in ~300ms–2s. No manual restart is required.

Autonomous AI Agent & LLM Tool Calling Guide

AI coding agents (Antigravity, Cursor, Claude Desktop, and custom autonomous swarms) operating on ExoStore clusters must follow these deterministic operational contracts:

1. Parameter Binding is Mandatory

Never generate queries using string interpolation (SELECT * FROM users WHERE id = '${id}'). Always use positional parameter arrays (SELECT * FROM users WHERE id = $1) to prevent SQL injection and prompt-injection-driven data leakage.

2. Query Plan Diagnosis Before Schema Changes

Before suggesting structural table alterations or rewriting queries, agents should inspect the execution plan using EXPLAIN (ANALYZE, COSTS, VERBOSE, BUFFERS, FORMAT JSON). Identify sequential scans (Seq Scan) on high-cardinality tables and recommend targeted indexes (CREATE INDEX CONCURRENTLY).

3. Automatic Schema-to-Type Synchronization

When an agent modifies table schemas, call getTableTypeDefinitions(tableName) to introspect columns, primary keys, and nullability, and automatically emit synchronized TypeScript entity interfaces, Zod validation schemas, and Drizzle ORM table definitions.

Data Access Rules (DAR) & Multi-Tenant Isolation

ExoStore embraces PostgreSQL native Row-Level Security (RLS) to enforce multi-tenant isolation directly inside the database engine, ensuring users can only read and write their own data:

PostgreSQL RLS Policy
-- 1. Enable Row Level Security on your table
ALTER TABLE documents ENABLE ROW LEVEL SECURITY;

-- 2. Create tenant isolation policy based on authenticated user ID
CREATE POLICY user_isolation_policy ON documents
  FOR ALL
  USING (auth.user_id() = owner_id);

Frequently Asked Questions

Where is my database physically hosted?

ExoStore PostgreSQL clusters are hosted in Singapore (aws-ap-southeast-1 via Neon) with ~35–60ms direct transit latency to our compute clusters in Mumbai (asia-south1). All data is encrypted at rest using AES-256 and in transit via TLS 1.3.

Why should I use the serverless HTTP driver instead of pg/node-postgres?

In serverless architectures (like Next.js on Cloud Run), container instances scale up and down dynamically. If each container opens 10 TCP connections with node-postgres, a sudden traffic spike can exceed PostgreSQL's maximum connection limit and crash the database. The HTTP driver executes queries statelessly over HTTPS without holding connection slots.

What happens when my database is in the Endpoint Inactive state?

When inactive for 5 minutes, compute scales to zero to eliminate idle billing. As soon as any incoming query or application request arrives, the engine wakes up automatically in ~300ms without manual intervention.

How do AI agents safely query ExoStore via MCP?

AI agents connect via the official Exovon Model Context Protocol server (@exovon/mcp-server). Every operation uses short-lived Just-In-Time (JIT) credentials with strict positional parameter binding and automatic query timeouts (statement_timeout=30000).

Was this documentation page helpful?