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.
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.
-- 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");
| Resource | Isolation Boundary | Enforcement |
|---|---|---|
| Schema / Namespace | Per-tenant dedicated schema | search_path + RLS |
| Encryption Key (DEK) | Unique AES-256-GCM key per tenant | KMS-managed, never shared |
| Connection Quota | Configurable per tenant | Enforced at authenticator |
| Storage Quota | Configurable per tenant (GB) | Enforced at WAL commit |
| CPU / I/O | Cgroup-aware scheduling | Work-stealing scheduler |
The built-in connection multiplexer (no PgBouncer required) supports 65,536 virtual clients over a small thread pool, using PostgreSQL wire protocol session multiplexing.
# 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
| Parameter | Default | Description |
|---|---|---|
max_connections | 65,536 | Maximum virtual client connections |
pool_mode | transaction | Multiplexing granularity |
pool_size | 256 | Real backend connections per DB |
pool_idle_timeout | 30s | Idle connection reclaim |
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.
# 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
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
| Capability | Current | Notes |
|---|---|---|
| Nodes per Raft group | 31 | Hierarchical Raft (Raft-of-Rafts) → v9.0 for unlimited |
| Consensus latency | < 1 ms LAN | Group-commit batching, 64 records/fsync |
| Witness nodes | Yes | Vote-only nodes for quorum without data |
| Read-only replicas | Yes | Follower reads with configurable staleness |
| Joint consensus | Yes | Online membership changes, zero downtime |
| Log compaction | Yes | Snapshot + truncation on configurable interval |
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-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');
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.
-- 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...
-- 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)
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.
-- 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 Type | Use Case | Max Nodes |
|---|---|---|
| PN-Counter | Inventory counts, vote tallies | 65,536 |
| LWW-Register | Profile data, settings, flags | 65,536 |
Use LOCALITY clauses to pin data to specific regions,
ensuring compliance with data-residency requirements (GDPR, data sovereignty)
while maintaining global query capability.
-- 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');
LOCALITY clauses
and multi-region CRDT sync are targeted for v9.0. The current release provides
single-region Raft HA with CRDT column types.
Absolute DB integrates directly with corporate LDAP and Microsoft Active Directory via the native LDAP auth module — no external proxy required.
# 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
-- 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;
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.
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
-- Verify JWT status
SELECT absdb_jwt_validate('eyJhbGciOiJSUzI1NiIsInR5...');
-- Returns: {"sub":"alice","role":"analyst","exp":1775000000,"valid":true}
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.
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
-- 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');
Each Absolute DB node issues and validates X.509 SPIFFE Verifiable Identity Documents (SVIDs), enabling cryptographic workload identity without managing per-service passwords.
-- 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;
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.
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
-- 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 Operation | Algorithm | Use |
|---|---|---|
| Master Key Storage | AES-256 | Wraps all DEKs |
| DEK Generation | AES-256-GCM | Per-tenant data encryption keys |
| Node Identity Signing | ML-DSA-65 (FIPS 204) | Raft membership + cert rotation |
| TLS Private Key | X25519 / ML-KEM-768 | TLS 1.3 + hybrid PQC handshake |
~154 KB binary · zero external dependencies · 2,737 tests passing · SQL:2023 100%