Documentation

Enterprise Scale

Absolute DB scales from a single Raspberry Pi to a 65,536-node planetary cluster without changing your application. This guide covers every enterprise-grade capability available in the Enterprise Edition.

Multi-Tenancy

Absolute DB supports up to 100,000 isolated tenants per server instance with full schema isolation, per-tenant resource quotas, and dedicated encryption keys (DEKs). No cross-tenant data leakage is architecturally possible.

Tenant Lifecycle

SQL / C API
-- Provision a tenant
CALL absdb_tenant_create('acme_corp', '{"quota_gb": 100, "max_connections": 500}');

-- Tear down (async — data purged within TTL window)
CALL absdb_tenant_drop('acme_corp');

-- Export full snapshot (GDPR portability)
CALL absdb_tenant_export('acme_corp', '/backups/acme_corp_2026.snap');

-- C API
absdb_tenant_create(db, "acme_corp", &opts);
absdb_tenant_drop(db,   "acme_corp");

Isolation Model

ResourceIsolation BoundaryEnforcement
Schema / NamespacePer-tenant dedicated schemasearch_path + RLS
Encryption Key (DEK)Unique AES-256-GCM key per tenantKMS-managed, never shared
Connection QuotaConfigurable per tenantEnforced at authenticator
Storage QuotaConfigurable per tenant (GB)Enforced at WAL commit
CPU / I/OCgroup-aware schedulingWork-stealing scheduler
Scale: 100,000 tenants × 500 connections each = 50 million virtual sessions handled via the built-in connection multiplexer with only ~4 MB RAM at idle.

Connection Pooling

The built-in connection multiplexer (no PgBouncer required) supports 65,536 virtual clients over a small thread pool, using PostgreSQL wire protocol session multiplexing.

absdb.conf
# Connection pool settings
max_connections        = 65536      # virtual clients
pool_mode              = transaction # session | transaction | statement
pool_size              = 256        # real backend connections per database
pool_idle_timeout      = 30s
pool_max_lifetime      = 3600s
pool_reserve_pool_size = 5          # emergency slots
ParameterDefaultDescription
max_connections65,536Maximum virtual client connections
pool_modetransactionMultiplexing granularity
pool_size256Real backend connections per DB
pool_idle_timeout30sIdle connection reclaim

Raft Consensus Cluster

Absolute DB ships a full Raft implementation supporting up to 31 nodes per Raft group, with leader election, log replication, log compaction, pre-vote, joint consensus, witness nodes, and read-only replicas.

Cluster Initialization

Shell
# Bootstrap a 3-node cluster
absdb-server --node-id 1 --cluster-init   --peers "node2:9091,node3:9091" --data-dir /data/node1

absdb-server --node-id 2 --join node1:9091 --data-dir /data/node2
absdb-server --node-id 3 --join node1:9091 --data-dir /data/node3

Cluster Status

SQL
SELECT * FROM absdb_cluster_nodes;
-- node_id | address        | role     | log_index | state
-- 1       | 10.0.0.1:9091  | leader   | 18423     | healthy
-- 2       | 10.0.0.2:9091  | follower | 18423     | healthy
-- 3       | 10.0.0.3:9091  | follower | 18422     | healthy
CapabilityCurrentNotes
Nodes per Raft group31Hierarchical Raft (Raft-of-Rafts) → v9.0 for unlimited
Consensus latency< 1 ms LANGroup-commit batching, 64 records/fsync
Witness nodesYesVote-only nodes for quorum without data
Read-only replicasYesFollower reads with configurable staleness
Joint consensusYesOnline membership changes, zero downtime
Log compactionYesSnapshot + truncation on configurable interval

C-RAID Storage

C-RAID is Absolute DB's distributed storage layer offering RAID-0 striping, RAID-1 mirroring, and RAID-5 parity with consistent hashing DHT, auto-rebalance, and dirty-shutdown self-heal. Predicate pushdown eliminates the Data Movement Tax by executing SQL filter conditions directly at the storage node.

RAID Configuration

SQL
-- RAID-1 mirroring across 2 nodes
CREATE TABLESPACE ts_mirror
  LOCATION '/data/primary'
  WITH (raid_mode = 1, replica_nodes = 'node2:9092');

-- RAID-5 parity across 4 nodes
CREATE TABLESPACE ts_parity
  LOCATION '/data/stripe'
  WITH (raid_mode = 5,
        stripe_nodes = 'node2:9092,node3:9092,node4:9092');

Auto-Balancer

The C-RAID auto-balancer monitors heartbeats every 500 ms. A node is flagged for re-mirroring when it is 3× slower than the cluster average for 3 or more consecutive checks.

SQL
-- View balancer status
SELECT * FROM absdb_raid_balance_status;
-- node_id | throughput_mbs | status   | last_rebalance
-- 1       | 1240           | healthy  | 2026-04-05 14:22:00
-- 2       | 1180           | healthy  | 2026-04-05 14:22:00
-- 3       | 124            | slow     | rebalancing...

Predicate Pushdown

SQL
-- This WHERE clause is serialized to binary wire format
-- and executed AT the storage node, not the query coordinator.
-- Eliminates moving millions of rows across the network.
SELECT order_id, amount
FROM orders
WHERE status = 'pending' AND amount > 10000;
-- EXPLAIN shows: Remote Filter: (status = 'pending' AND amount > 10000)

Geo-Replication

Absolute DB supports multi-region deployments with CRDT-based conflict resolution, Last-Write-Wins (LWW) registers, and Hybrid Logical Clocks (HLC) for causally consistent cross-region writes.

SQL
-- Mark a column as conflict-free (CRDT)
ALTER TABLE inventory
  ALTER COLUMN stock_count SET CONFLICT_FREE CRDT_TYPE pn_counter;

-- Hybrid Logical Clock timestamp on every row
ALTER TABLE events
  ADD COLUMN hlc_ts HLC DEFAULT absdb_hlc_now();

-- View replication lag per region
SELECT region, lag_ms FROM absdb_geo_replication_status;
CRDT TypeUse CaseMax Nodes
PN-CounterInventory counts, vote tallies65,536
LWW-RegisterProfile data, settings, flags65,536

Multi-Region Deployment

Use LOCALITY clauses to pin data to specific regions, ensuring compliance with data-residency requirements (GDPR, data sovereignty) while maintaining global query capability.

SQL
-- Pin table data to EU region
CREATE TABLE eu_customers (...) LOCALITY 'eu-west-1';

-- Cross-region query (coordinator fetches from remote)
SELECT c.name, o.amount
FROM eu_customers c JOIN us_orders o ON c.id = o.customer_id;

-- Data version control: branch per region for staging
CREATE DATABASE eu_staging FROM main LOCALITY 'eu-west-1';
SELECT * FROM absdb_branch_diff('eu_staging', 'main');
v9.0 target: Full geo-partitioning with LOCALITY clauses and multi-region CRDT sync are targeted for v9.0. The current release provides single-region Raft HA with CRDT column types.

LDAP / Active Directory Authentication

Absolute DB integrates directly with corporate LDAP and Microsoft Active Directory via the native LDAP auth module — no external proxy required.

absdb.conf
# LDAP authentication
ldap_enabled      = true
ldap_server       = ldap://ad.corp.example.com:389
ldap_bind_dn      = CN=svc-absdb,OU=ServiceAccounts,DC=corp,DC=example,DC=com
ldap_bind_password = {{ vault:ldap_svc_pass }}
ldap_base_dn      = OU=Users,DC=corp,DC=example,DC=com
ldap_user_filter  = (sAMAccountName={username})
ldap_group_filter = (memberOf=CN=DBUsers,OU=Groups,DC=corp,DC=example,DC=com)
ldap_tls          = starttls  # none | starttls | ldaps

Group → Role Mapping

SQL
-- Map an AD group to a DB role
CREATE ROLE db_readonly;
CALL absdb_ldap_map_group('CN=DBReadOnly,OU=Groups,DC=corp,DC=example,DC=com', 'db_readonly');

-- Verify mapping
SELECT * FROM absdb_ldap_group_mappings;

OAuth2 / OIDC / JWT Authentication

Absolute DB accepts bearer tokens from any OIDC-compliant identity provider (Auth0, Okta, Azure AD, Google, Keycloak). Tokens are validated locally using JWKS — no round-trip to the IdP on every query.

absdb.conf
jwt_auth_enabled  = true
jwt_issuer        = https://auth.example.com/
jwt_audience      = absdb-production
jwt_jwks_uri      = https://auth.example.com/.well-known/jwks.json
jwt_jwks_refresh  = 3600   # seconds between JWKS cache refresh
jwt_claim_role    = db_role  # JWT claim mapped to DB role
jwt_require_https = true
SQL
-- Verify JWT status
SELECT absdb_jwt_validate('eyJhbGciOiJSUzI1NiIsInR5...');
-- Returns: {"sub":"alice","role":"analyst","exp":1775000000,"valid":true}

Zero-Trust mTLS

Every TCP connection to Absolute DB in Enterprise mode requires a valid client certificate. No anonymous or password-only connections are permitted. Certificates are validated against a CA chain maintained in the database keystore.

absdb.conf
tls_mode          = require         # disable | allow | prefer | require | verify-full
tls_cert_file     = /etc/absdb/server.crt
tls_key_file      = /etc/absdb/server.key
tls_ca_file       = /etc/absdb/ca.crt
mtls_require      = true            # client cert mandatory
mtls_ca_file      = /etc/absdb/client-ca.crt

Per-Peer ACLs

SQL
-- Grant connect from a specific mTLS identity
GRANT CONNECT FROM 'CN=analytics-service,OU=Services,DC=corp,DC=example,DC=com'
  TO ROLE analytics_reader;

-- Hot certificate rotation (zero downtime)
CALL absdb_zerotrust_rotate_cert('/etc/absdb/new-server.crt', '/etc/absdb/new-server.key');
Zero downtime: Certificate rotation uses ML-DSA-65 (FIPS 204) signing to authenticate the new certificate chain before the old one expires. Active sessions are not interrupted.

SPIFFE / SVID Identity

Each Absolute DB node issues and validates X.509 SPIFFE Verifiable Identity Documents (SVIDs), enabling cryptographic workload identity without managing per-service passwords.

SQL
-- View current node SVID
SELECT absdb_spiffe_svid();
-- spiffe://cluster.local/absdb/node/1

-- Grant access from a Kubernetes workload
GRANT CONNECT FROM 'spiffe://cluster.local/ns/payments/sa/checkout'
  TO ROLE payments_writer;

-- Verify peer SVID on an incoming connection
SELECT * FROM absdb_active_connections WHERE spiffe_id IS NOT NULL;

FIPS 140-3 Level 4 HSM

Absolute DB includes a PKCS#11 shim for hardware-backed cryptographic operations. All DEK generation, signing, and key derivation operations can be offloaded to a FIPS 140-3 Level 4 certified Hardware Security Module.

absdb.conf
pkcs11_enabled    = true
pkcs11_lib        = /usr/lib/libCryptoki2_64.so  # HSM vendor library
pkcs11_slot       = 0
pkcs11_pin_env    = ABSDB_HSM_PIN               # PIN from environment variable
pkcs11_key_label  = absdb-master-key
pkcs11_operations = sign,unwrap,derive           # offloaded operations
SQL
-- Verify HSM is active
SELECT * FROM absdb_hsm_status;
-- hsm_vendor | model         | fips_level | slot | key_label         | status
-- Thales     | Luna Network  | 4          | 0    | absdb-master-key  | active

-- Generate a tenant DEK in the HSM
SELECT absdb_kms_generate_dek('tenant_acme', 'hsm');
HSM OperationAlgorithmUse
Master Key StorageAES-256Wraps all DEKs
DEK GenerationAES-256-GCMPer-tenant data encryption keys
Node Identity SigningML-DSA-65 (FIPS 204)Raft membership + cert rotation
TLS Private KeyX25519 / ML-KEM-768TLS 1.3 + hybrid PQC handshake

Continue Reading

Backup & Restore Replication Compliance Guide

Ready to run Absolute DB?

~154 KB binary  ·  zero external dependencies  ·  2,737 tests passing  ·  SQL:2023 100%

Download Free → View Pricing All Docs