Configuration
Configure your ekoDB instance at runtime using the REST API. All configuration changes take effect immediately without requiring a restart.
Configuration endpoints require admin permissions.
API Endpoints
Get Configuration
Retrieve the current configuration:
GET /api/config
Authorization: Bearer {ADMIN_TOKEN}
Update Configuration
Update one or more configuration options. Only the fields you include in the request body will be changed — all other settings remain unchanged.
PUT /api/config
Content-Type: application/json
Authorization: Bearer {ADMIN_TOKEN}
{
"use_typed_values": false,
"storage_mode": "balanced",
"durable_operations": true
}
Response:
{
"status": "success",
"message": "Configuration updated successfully"
}
Core Settings
| Option | Type | Default | Range | Description |
|---|---|---|---|---|
use_typed_values | Boolean | true | — | When true, responses include type metadata (e.g., {"type": "String", "value": "Alice"}). When false, returns plain values. |
default_ttl | Integer | 3600 | 0–604800 | Default time-to-live for new records in seconds. 0 disables expiration. Max 7 days (604,800 seconds). |
token_expiry_hours | Integer | 1 | 1–168 | JWT token lifetime in hours. Max 7 days (168 hours). |
encrypt_ids | Boolean | true | — | Encrypt record IDs with AES-GCM. Disable only for testing/benchmarks. |
access_mode | String | "read_write" | "read", "write", "read_write" | Node access permissions. Use "read" for read replicas, "write" for write-only nodes. |
Example — Configure a read-only replica:
{
"access_mode": "read",
"token_expiry_hours": 24
}
Storage & Durability
Storage Mode
| Option | Type | Default | Values | Description |
|---|---|---|---|---|
storage_mode | String | "fast" | "fast", "balanced", "cold" | Record persistence strategy. |
| Mode | Description | Best For |
|---|---|---|
fast | In-memory primary with WAL-only persistence | Low-latency reads (default) |
balanced | LRU cache with periodic checkpoint batching to disk | General-purpose workloads |
cold | Index-only memory with chunked append storage | Write-heavy ingestion, logging |
Durability & WAL
| Option | Type | Default | Range | Description |
|---|---|---|---|---|
durable_operations | Boolean | true | — | When true, writes are fsynced to disk before responding. When false, writes are buffered and fsynced in the background for higher throughput. |
insert_returns_record | Boolean | false | — | When true, an insert echoes the full stored record (server-applied fields included) instead of just {id}. Costs a read; opt in per-request with ?return_record=true. |
update_returns_record | Boolean | true | — | When true (default), an update returns the full merged record. When false, it returns {id, updated:true}. The merge already loads the record, so returning it is free. |
delete_returns_record | Boolean | false | — | When false (default), a delete returns the minimal {id, deleted:true} ack and skips loading the record body — the fast path. When true, it loads and returns the full deleted record. Override per-request with ?return_record=true. |
group_commits | Boolean | true | — | Batch concurrent writes together with a single fsync. Dramatically improves throughput under concurrent load while maintaining durability. |
group_commit_delay_ms | Integer | 2 | 0–100 | Batching window in milliseconds for group commits. Lower = lower latency, higher = more batching throughput. |
group_commit_mode | String | "leader_election" | "leader_election", "channel" | Group-commit completion strategy. "leader_election" (default, highest throughput): writers share a generation counter. "channel": each writer gets its own per-operation write result (per-write error isolation). Both are equally durable. |
wal_shards | Integer | 4 | 1–16 | Number of parallel WAL shards for concurrent fsync. More shards = higher write throughput under concurrent load. |
wal_max_retry_delay_ms | Integer | 30000 | 1000–300000 | Maximum exponential backoff delay for WAL write retries, in milliseconds. Caps the delay to prevent excessive wait times when many retries accumulate. |
wal_group_commit_timeout_secs | Integer | 30 | 5–300 | Timeout in seconds for the WAL group-commit flusher task. Writers are unblocked automatically if the flusher crashes or stalls. |
wal_ship_interval_secs | Integer | 5 | 1–3600 | Interval (seconds) between WAL-shipment passes to WAL-mode replicas. A cheap no-op unless a WAL-mode ripple is configured. See Ripples — WAL Mode. |
Example — Maximum write throughput:
{
"durable_operations": true,
"group_commits": true,
"group_commit_delay_ms": 5,
"group_commit_mode": "leader_election",
"wal_shards": 8
}
Example — Low-latency single-writer:
{
"durable_operations": true,
"group_commits": false
}
Setting durable_operations to false means data written within the last flush window (typically 0–1 second) may be lost on crash. Only disable for non-critical data like analytics or bulk ingestion.
Transactions
| Option | Type | Default | Range | Description |
|---|---|---|---|---|
default_isolation_level | String | "ReadUncommitted" | "ReadUncommitted", "ReadCommitted", "RepeatableRead", "Serializable" | Server-wide default isolation level for a transaction that does not specify one. A per-transaction value (passed to begin) overrides it. ReadUncommitted (default) is the zero-cost fast path; higher levels validate more at commit. Changeable at runtime. |
The default applies only when a transaction does not request a level; the official client libraries send ReadCommitted per transaction. See Transactions for the full semantics.
Search
| Option | Type | Default | Range | Description |
|---|---|---|---|---|
max_vector_k | Integer | 1000 | 1–1000000 | Upper bound a vector search's k (number of nearest neighbors) is clamped to. Bounds the result heap a single query can allocate. |
max_ef_search | Integer | 4000 | 1–1000000 | Upper bound a vector search's HNSW ef_search (beam width) is clamped to. Bounds the per-query work a single search can demand. |
A vector search request asking for a larger k or ef_search is clamped to these caps, so a single query cannot exhaust memory or CPU. Raise them via PUT /api/config if your workload genuinely needs larger values.
Resource Allocation
| Option | Type | Default | Range | Description |
|---|---|---|---|---|
memory_allocation_percent | Integer | 50 | 1–80 | Percentage of system RAM to use for database caching. |
cpu_utilization_percent | Integer | 100 | 10–100 | Percentage of CPU cores to use for concurrent operations. |
Guidelines:
| Scenario | Memory | CPU |
|---|---|---|
| Dedicated database server | 50–70% | 100% |
| Shared server with other services | 25–40% | 50% |
| Background/minimal service | 10–20% | 25% |
Example — Shared server configuration:
{
"memory_allocation_percent": 30,
"cpu_utilization_percent": 50
}
LLM Providers
Configure LLM providers for Chat/RAG functionality. You can configure multiple providers and select which to use per chat session.
OpenAI
| Option | Type | Default | Description |
|---|---|---|---|
openai_api_key | String | — | API key for OpenAI. Required to use OpenAI models. |
openai_api_url | String | "https://api.openai.com" | Custom API URL for OpenAI-compatible APIs (e.g., LM Studio, Ollama). |
openai_default_model | String | — | Default model for OpenAI chat sessions (e.g., "gpt-4", "gpt-4o"). |
Anthropic
| Option | Type | Default | Description |
|---|---|---|---|
anthropic_api_key | String | — | API key for Anthropic. Required to use Anthropic models. |
anthropic_api_url | String | — | Custom API URL for Anthropic. |
anthropic_default_model | String | — | Default model (e.g., "claude-sonnet-4-5-20250929"). |
anthropic_default_version | String | — | Anthropic API version string. |
Perplexity
| Option | Type | Default | Description |
|---|---|---|---|
perplexity_api_key | String | — | API key for Perplexity. Required to use Perplexity models. |
perplexity_api_url | String | — | Custom API URL for Perplexity. |
perplexity_default_model | String | — | Default model for Perplexity chat sessions. |
Example — Configure OpenAI with a local LM Studio endpoint:
{
"openai_api_key": "lm-studio",
"openai_api_url": "http://localhost:1234",
"openai_default_model": "llama-3.1-8b"
}
Example — Configure multiple providers:
{
"openai_api_key": "sk-...",
"openai_default_model": "gpt-4o",
"anthropic_api_key": "sk-ant-...",
"anthropic_default_model": "claude-sonnet-4-5-20250929"
}
Chat Settings
Fine-tune chat/RAG behavior for each LLM provider. See Chat & RAG for usage.
General Chat Settings
| Option | Type | Default | Description |
|---|---|---|---|
chat_max_context_snippets | Integer | 5 | Maximum number of context snippets returned from search results for each chat query. |
chat_max_tokens | Integer | 4096 | Maximum number of tokens for LLM responses. |
chat_max_merged_messages | Integer | 10000 | Maximum messages to merge when loading chat history. |
Provider Temperature & Sampling
Control the creativity and determinism of LLM responses per provider.
| Option | Type | Default | Range | Description |
|---|---|---|---|---|
chat_openai_temperature | Float | 0.6 | 0.0–2.0 | OpenAI response temperature. Lower = more focused. |
chat_openai_top_p | Float | 1.0 | 0.0–1.0 | OpenAI nucleus sampling. |
chat_anthropic_temperature | Float | 1.0 | 0.0–1.0 | Anthropic response temperature. |
chat_anthropic_top_p | Float | 0.99 | 0.0–1.0 | Anthropic nucleus sampling. |
chat_perplexity_temperature | Float | 0.2 | 0.0–2.0 | Perplexity response temperature. |
chat_perplexity_top_p | Float | 0.9 | 0.0–1.0 | Perplexity nucleus sampling. |
Schema-Aware Search
These settings control how chat queries use collection schemas to improve search results.
| Option | Type | Default | Description |
|---|---|---|---|
chat_schema_search_min_results | Integer | 3 | Minimum text search results before triggering schema-based field matching. |
chat_schema_search_min_word_length | Integer | 3 | Minimum word length for query terms to be used in schema field matching. |
chat_schema_field_match_score | Float | 0.5 | Score added when a query term matches a schema field name. |
chat_field_name_boost_multiplier | Float | 0.3 | Score boost multiplier for results with matching field names. |
chat_schema_sample_records | Integer | 1 | Number of sample records to fetch when schema field names match the query. |
Custom Collection Names
Override the default collection names used by the chat system.
| Option | Type | Default | Description |
|---|---|---|---|
chat_configurations_collection | String | "chat_configurations_{db_name}" | Collection for storing chat session configurations. |
chat_messages_collection | String | "chat_messages_{db_name}" | Collection for storing chat messages. |
Write Performance Tuning
Control which features run inline (synchronous) versus in the background during insert and update operations. Setting features to false defers them to background tasks for maximum write throughput.
Insert Features
| Option | Type | Default | Description |
|---|---|---|---|
insert_features.search_index | Boolean | true | Update text/vector search indexes inline during insert. When false, search indexes update asynchronously. |
insert_features.query_index | Boolean | true | Update query indexes inline during insert. When false, query indexes update asynchronously. |
insert_features.constraints | Boolean | true | Run schema constraint validation (unique, required, enum, min, max, regex) during insert. When false, constraints are skipped entirely. |
insert_features.disk_cache | Boolean | true | Write to disk cache inline during insert. When false, disk cache writes are deferred (WAL still provides durability). |
Update Features
| Option | Type | Default | Description |
|---|---|---|---|
update_features.search_index | Boolean | true | Update text/vector search indexes inline during update. |
update_features.query_index | Boolean | true | Update query indexes inline during update. |
update_features.constraints | Boolean | true | Run schema constraint validation during update. |
update_features.disk_cache | Boolean | true | Write to disk cache inline during update. |
Read Features
Optional per-read work, runtime-tunable via PUT /api/config. Correctness-critical work (record visibility, TTL, auth) is never affected by these flags.
| Option | Type | Default | Description |
|---|---|---|---|
read_features.pattern_logging | Boolean | true | Record access patterns on each read to feed cache warming. When false, per-read access logging is skipped — use for warming-insensitive, read-heavy workloads (e.g. a fully in-memory working set). |
read_features.io_metrics | Boolean | true | Record per-read I/O metrics for analytics. When false, reads are not counted in I/O analytics. |
Example — Maximum insert throughput (defer everything):
{
"insert_features": {
"search_index": false,
"query_index": false,
"constraints": false,
"disk_cache": false
}
}
Example — Fast inserts with constraints still enforced:
{
"insert_features": {
"search_index": false,
"query_index": false,
"constraints": true,
"disk_cache": false
}
}
- Bulk ingestion: Defer all features for maximum throughput, then rebuild indexes after
- No constraints needed: Skip constraints if the collection has no unique/required fields
- Search not critical: Defer search indexing if real-time search isn't required
Security & Authentication
| Option | Type | Default | Range | Description |
|---|---|---|---|---|
jwt_leeway_seconds | Integer | 5 | 0–60 | Clock-skew tolerance for JWT token validation, in seconds. Allows tokens that expired up to this many seconds ago to still be accepted. Limits the replay-attack window if node clocks drift. |
Rate Limiting
Configure rate limiting for public (unauthenticated) endpoints.
| Option | Type | Default | Range | Description |
|---|---|---|---|---|
public_endpoint_rate_limit_enabled | Boolean | true | — | Enable rate limiting on public endpoints (/api/health, /api/auth/register, /api/auth/token). |
public_endpoint_rate_limit_per_minute | Integer | 60 | 10–300 | Maximum requests per IP per minute for public endpoints. |
admin_key_rate_limit_per_minute | Integer | 5 | 1–60 | Maximum requests per IP per minute for admin key endpoints (/api/auth/*/admin_key). Kept intentionally low to resist brute-force attacks on admin credentials. |
Rate limits for authenticated API endpoints are determined by your deployment tier. See Security - Rate Limiting for tier details.
Functions
| Option | Type | Default | Description |
|---|---|---|---|
functions_collection | String | "functions_{db_name}" | Collection name for storing scheduled functions. |
environment_vars | Object | {} | Key-value pairs accessible in functions via {{env.VAR_NAME}} syntax. |
Example — Set function environment variables:
{
"environment_vars": {
"WEBHOOK_URL": "https://api.example.com/webhook",
"AUTH_TOKEN": "token123"
}
}
Maintenance
| Option | Type | Default | Description |
|---|---|---|---|
disable_maintenance | Boolean | false | Disable periodic background maintenance tasks (cache cleanup, compaction). Only disable for benchmarking. |
Full Configuration Example
Here's an example configuring a production instance with multiple LLM providers, tuned durability, and resource limits:
curl -X PUT https://{EKODB_API_URL}/api/config \
-H "Authorization: Bearer {ADMIN_TOKEN}" \
-H "Content-Type: application/json" \
-d '{
"use_typed_values": true,
"token_expiry_hours": 1,
"default_ttl": 3600,
"storage_mode": "fast",
"durable_operations": true,
"group_commits": true,
"group_commit_delay_ms": 2,
"wal_shards": 4,
"wal_max_retry_delay_ms": 30000,
"wal_group_commit_timeout_secs": 30,
"jwt_leeway_seconds": 5,
"admin_key_rate_limit_per_minute": 5,
"memory_allocation_percent": 50,
"cpu_utilization_percent": 100,
"openai_api_key": "sk-...",
"openai_default_model": "gpt-4o",
"chat_max_context_snippets": 5,
"chat_max_tokens": 4096,
"public_endpoint_rate_limit_enabled": true,
"public_endpoint_rate_limit_per_minute": 60,
"insert_features": {
"search_index": true,
"query_index": true,
"constraints": true,
"disk_cache": true
}
}'
Related Documentation
- Basic Operations - CRUD operations and storage modes
- Chat & RAG - AI chat configuration and usage
- Security - Authentication, rate limits, and access control
- System Administration - Health monitoring and WAL management