CronDB — Stop Writing Cron Jobs

Side by side

Delete the stack.
Just write a query.

The same free-trial expiry logic — one done the traditional way, one with CronDB's native temporal syntax.

WITHOUT CronDB — traditional stack

// 1. Insert user
db.query(`INSERT INTO users
  SET plan='Trial',
  trial_expires_at = NOW() + INTERVAL 14 DAY`);

// 2. Schedule expiry job (cron, SQS, etc.)
scheduler.schedule('0 * * * *', async () => {
  const expired = await db.query(`
    SELECT id FROM users
    WHERE plan = 'Trial'
    AND trial_expires_at < NOW()`);

  for (const user of expired) {
    await db.query(`UPDATE users
      SET plan = 'Free'
      WHERE id = ?`, user.id);
    await queue.publish('plan.downgraded', user);
  }
});

// 3. Worker listens to queue, calls webhook
// 4. Handle failed jobs, dead letters...
// 5. Monitor that all three are running...

WITH CronDB — two queries, done

// 1. Insert user with native FSM transition
INSERT INTO users
  name = 'Alice'
  plan = ('Trial' --> 'Free' @ 14 d)


// 2. Register webhook — fires exactly at transition
LISTEN users.plan --> 'https://api.app.com/downgrade'
WHERE plan = 'Free'




// That's it. Engine handles the rest.
// SELECT always returns the live, current state.
// No polling. No workers. No queue.

How it works

Three primitives.
Infinite possibilities.

01 // Finite State Machines

Encode time directly into your data model.

Any string column can hold a timed state chain. On every SELECT, the engine computes elapsed time against the insertion timestamp and returns the live, correct state — no app logic needed.

One-way transitions Multi-step chains Cyclic automata s / m / h / d / mo

temporal_fsm.sql

// Trial → Free after 14 days
INSERT INTO users
  name = 'Alice'
  plan = ('Trial' --> 'Free' @ 14 d)

// Traffic light — loops forever
INSERT INTO signals
  color = ('Red' --> 'Green' @ 30 s
           --> 'Yellow' @ 25 s
           --> 'Red' @ 5 s c)

// Multi-step device warmup
INSERT INTO devices
  state = ('Idle' --> 'Warming' @ 1 h
           --> 'Active' @ 30 m
           --> 'Cooldown' @ 2 h)

02 // Webhook Engine

Push events exactly at the moment of transition.

A background thread drives a min-heap priority queue, waking every 500ms to fire HTTP POST payloads at the exact moment an FSM state flips. Listeners persist across restarts — register once, forget about it.

Min-heap queue Filtered WHERE clause Restart-persistent JSON payload

webhook_setup.sql

// Fire on any plan change
LISTEN users.plan --> 'https://api.app.com/hook'

// Filter: only fire when plan becomes 'Free'
LISTEN users.plan --> 'https://api.app.com/downgrade'
WHERE plan = 'Free'

// Engine POSTs this payload at transition time:
{
  "table":     "users",
  "row":       42,
  "column":   "plan",
  "new_value":"Free"
}

03 // WAL Durability + ACID

Crash-safe by design.

Every mutating command is appended to cron.wal before execution. On crash, the bootloader replays the log to restore committed state. Full BEGIN / COMMIT / ROLLBACK transaction support with in-memory undo log.

Write-Ahead Log ACID Transactions Crash recovery CHECKPOINT compaction

transactions.sql

// Wrap multi-step writes in a transaction
BEGIN

INSERT INTO accounts
  name = 'Eve' balance = 1000

UPDATE accounts
  SET balance = 500
  WHERE name = 'Alice'

COMMIT

// Compact WAL + flush to disk
CHECKPOINT

Under the hood

An engine, not a framework.

01 // INDEXING

O(log N) B-Tree Lookups

Primary keys are mapped to a memory-resident Red-Black tree. Blazing fast reads at 100,000+ rows without an external index layer.

02 // STORAGE

Fixed-Width Binary Rows

Rows are stored as fixed-width binary records in .bin files. Row i is always at offset header + i × rowSize — O(1) random access, no heap scan.

03 // INTEGRITY

Foreign Key Hostages

Use LINK to establish referential integrity. Parent rows cannot be deleted while child rows reference them. FK columns can themselves be FSM-driven.

04 // CONCURRENCY

Reader-Writer Locking

Many simultaneous readers, serialised writes. The FSM clock thread runs independently every 500ms, never blocking query throughput.

05 // EMBEDDING

Load as a .dll / .so

Bypass the HTTP server entirely. Load CronDB into your process via ctypes, FFI, or a C bridge. Three exported functions: StartEngine, ExecuteQuery, StopEngine.

06 // SDKs

JS & Python ORM

Official npm (crondb-driver) and PyPI packages wrap the HTTP API with ORM-style insert, select, update, delete, and listen methods.

Real-world patterns

What people are building.

SaaS Subscription Lifecycle

Trials that expire natively, seats that auto-downgrade, and billing cycles that loop. No worker needed.

INSERT INTO subs plan = ('Trial' --> 'Free' @ 14 d)

Order State Machines

Pending orders that auto-cancel after a timeout. Shipping stages that progress on a timer.

INSERT INTO orders status = ('Pending' --> 'Cancelled' @ 15 m)

Game World Persistence

Crop growth, hero quest timers, equipment cooldowns — all driven by the engine. State survives process restarts.

INSERT INTO crops state = ('Seed' --> 'Sprout' @ 3 s --> 'Harvestable' @ 4 s)

Cyclic Automata

Anything that repeats: traffic lights, billing cycles, equipment maintenance schedules, rotating slot assignments.

INSERT INTO signals color = ('Red' --> 'Green' @ 30 s --> 'Yellow' @ 5 s c)

Pricing

Buy it once.
Own it forever.

No subscription. No seats. No vendor lock-in. Pay $29, get the binaries, ship your product.

✓ One-time payment · No subscription

^$29

Full engine, both SDKs, architecture docs, all future v1 updates.

✓ CronDB server binary (Linux / Windows)

✓ Shared library (.dll / .so) for embedding

✓ JavaScript SDK

✓ Python SDK

✓ Full architecture documentation (PDF)

✓ Temporal FSM · WAL · Webhooks · ACID

✓ All v1.x updates included

Get Binaries — $29 →

Questions? Join us on Discord · Read the Architecture Guide

Questions

Common questions, straight answers.

Is this a drop-in replacement for PostgreSQL / MySQL?+

Not exactly. CronDB is a purpose-built engine with its own query language. It's best used alongside your existing database for domains that require temporal logic — trials, expiry, cyclic state, event-driven workflows — rather than replacing your primary relational store entirely.

How does FSM evaluation actually work — is there a background ticker?+

CronDB uses lazy evaluation. Each FSM cell records its insertion timestamp and state durations. On every SELECT, the engine computes elapsed time and walks the state chain to find the current value — no background ticker required for reads. A separate clock thread (500ms interval) handles the webhook queue, but this never blocks query execution.

What happens to webhook delivery if my server is down?+

Webhook tasks are persisted to disk and re-queued on engine boot. If CronDB restarts, it replays the pending webhook queue. If your endpoint is unreachable, the current version does not retry — fire-and-forget. The webhook architecture doc covers this in detail.

Can I use the .dll / .so in a Python game or desktop app?+

Yes. Load it with ctypes.CDLL('./crondb.so') (or .dll on Windows) and call StartEngine(), ExecuteQuery(query), and StopEngine(). The architecture doc includes a full persistent game-world example showing exactly this pattern.

What platforms are the binaries available for?+

The current release targets Linux (x86_64) and Windows. Join the Discord to request other targets or ask about building from source.

Is $29 really a one-time payment?+

Yes — one payment, no subscription, no seats, no SaaS. You get the binaries, the shared library, both SDKs, and the architecture docs. All v1.x updates are included. Built by a solo engineer who charges once and maintains it.

Your database should knowwhat time it is.

Your database should know
what time it is.