Features

What is actually in the box

Eight systems that fit together. Each one is useful on its own; the point is that the next one always knows what the last one built. Everything below is built and running today - nothing here is a plan.

Real columns, not a bag of JSON. Types with lengths and scale, signed and unsigned, defaults, nullability, auto-increment, primary keys, unique constraints and secondary indexes - the things that make a database worth having.
Relationships you can see. Foreign keys are drawn as edges, and the editor ranks which columns are plausible candidates, so joining two tables is a gesture rather than a lookup.
The browser never sends SQL. It says what it wants; the server diffs that against the live catalogue and decides what it costs. Accepting a client-supplied statement list would make the save endpoint “run any DDL, authenticated by a cookie”.
Nobody clobbers anybody. A save carries a fingerprint of the structure it was based on. If the schema moved underneath you while you were drawing, the save is refused rather than merged badly.
Three engines, one vocabulary. MariaDB, PostgreSQL and SQL Server. Only three files in the codebase know a native type name; everything above them is engine-agnostic, and the type mapping has to round-trip or a save would schedule a table rebuild nobody asked for.
System tables are off limits. A floor beneath the permission system protects the tables DB Craft runs on, and no setting - not even administrator - lifts it.

Rows, columns, twelve of them. Components sit in rows and take a width. Containers - tabs, sections, groups - hold other components, so the layout goes as deep as you need.
Nine kinds of component. Text, table, joined data table, chart, form, plugin view, action button, tabs and spacer. The list is closed on purpose: a fixed vocabulary is what lets every one of them be validated, permission-checked and drawn without a surprise.
Tables with filters. Fix a filter and it always applies; mark it prompted and it becomes a control on the page. The filter is applied to the count as well as the rows, so the pager tells the truth.
Charts and text. Bar, line and pie, drawn from the same tabular data a table would show, and every chart keeps a table toggle. Markdown for the prose, parsed to a tree and rendered as elements - never injected as raw HTML.
Record pages. A page can be bound to a row, so /customers/482 is a page like any other with the record in hand.
Editing in place. A data table can add, edit and delete rows inline, with the form drawn from the columns and the constraints rather than configured twice.

Related tables are discovered, not configured. The live foreign-key graph is the source, one hop out. Nothing to declare, nothing to keep in step, and nothing to get wrong.
Direction decides the maths. A to-one relation is joined and contributes columns. A to-many is never joined - it becomes its own subquery and contributes counts and totals. That is why one row out per row in is structurally true, and why the record count is honest without a DISTINCT.
Counts, sums, averages, minimums, maximums. Plus calculated columns - concatenate, coalesce, add, subtract, multiply, divide, and the year, month or day of a date.
Thirteen filter operators, including pattern matching with * and ?, is-any-of, and is-empty. Group rows by any column, colour them by a condition, and drill into one from a panel.
It respects the permission model at every hop. Every table a query touches needs its own grant, and the tables that get authorised come out of the live key graph rather than out of the request. A relation you may not read is reported as unreadable rather than silently dropped, so a page author can tell “no such table” from “not for you”.

Data is denied until granted. Access rules name a user or a group directly - no permission invented in between. “Finance or Sales may read invoices” is two rules and nothing else.
Pages are visible until closed. The opposite default, on purpose: a page builder where every new page starts invisible is a page builder nobody uses. What is only displayed defaults to displayed; what acts defaults to denied.
Both are enforced, not merely displayed. A hidden page returns a 404 by address, and the data endpoint refuses a table the caller has no rule for. Hiding a link is not security, and DB Craft does not pretend otherwise.
Nothing subtracts. There are no deny rules to reason about. Restriction happens because naming one group excludes everyone else, and depth decides precedence - the closest rule wins.
A floor underneath all of it. Sessions, credentials, the audit trail, the outbox, second-factor material and identity-provider secrets are never served by the generic data endpoint and never written by it - because a session id is a bearer token in plaintext, and one read of that table would be unlimited impersonation. Administrator does not lift the floor.

No duplicates across one column or several together. Matches a pattern - a postcode, a reference number, an email shape. Within a range. One of a list, which also turns the field into a dropdown and can display something different from what it stores. A kind of file. One of another table, which renders as a dropdown of that table's rows. Cannot delete while in use.
Checked inside the write's own transaction. A uniqueness probe on a separate connection reads a snapshot the insert will not be part of, and that window is exactly the race the rule exists to close.
The same check runs in the browser on every keystroke, so a bad value is refused before a request is made and the message is the one the server would have given. That copy is a convenience, never the security claim - the endpoint evaluates every rule regardless.
Adoptable on data you already have. A rule runs when the value it reads is being written, so adding one does not make every legacy row unsaveable.
A rule that cannot be checked refuses the write. Deliberately loud. A constraint that quietly stopped running is one nobody finds out about until the data is already wrong.

Single sign-on over OIDC. Several providers at once, endpoint discovery, PKCE, nonce-checked tokens, configurable claim mapping, and group mapping from a claim to local group membership.
An identity is keyed on the provider and the subject, never on an email address. Email is mutable and a provider may return one it never verified, so matching on it is an account-takeover route. A first link on a verified address is the only path that looks at one at all.
Second factors: an authenticator app, a one-time code by email, or a passkey. Passkeys also work as a first factor, with user verification required - possession alone is weaker than the password it would be replacing.
Ten recovery codes, hashed at rest. Trusted devices for up to a year, or switched off entirely.
Policy can only ever add a requirement. Nothing in the settings screen can make a factor optional for somebody who has already enrolled one, because that would let an administrator silently weaken an account they do not own.
An audit trail, and a throttle computed from it rather than from a second table - so what happened and what gets rate-limited are the same fact stored once, and cannot disagree. Every session is listed and revocable, named “Chrome on macOS” rather than ninety characters of user-agent.

Five kinds of schedule - every N minutes, daily, weekly, monthly, or a raw cron expression - all compiling to one matcher, in the timezone you name. The daylight-saving cases are decided rather than discovered: a wall time that does not exist runs once, shifted forward, and a monthly job on the 31st skips February rather than quietly becoming the 28th.
Two workers cannot both win a job. A run is claimed with a compare-and-swap, which is what makes the worker container optional - run the scheduler inside the app, in a container of its own, or from a host crontab, and running two is redundant rather than wrong.
No catch-up. A box that was down for a weekend fires each job once, not three hundred times. And a job too big for one run can save its place and ask for another go.
A plugin is a folder with one file in it. Drop it on the server and it is there - no build, no upload form, no restart, no marketplace approval.
It can bring an interface. Views render inside a page or in a dialog, handed the row or the record they were opened from, and drawn with the host's React rather than shipping a second one. It declares the settings it wants and DB Craft draws the form; a stored value that no longer fits falls back rather than breaking the page.
It can react. Subscribe an action to a table and it fires after a write commits - after, deliberately, so a plugin bug cannot make a table unsaveable. Every action is bounded to thirty seconds, every run is recorded with its output, and there is a kill switch.

CSV import that validates first. Types and column names inferred from the file, a mapping screen you override, and then the whole file is checked before a single row is written - all of it lands or none of it does. Errors name the line and the column, and the line is the real one rather than the row number, which differs the moment a quoted field holds a newline.
Guesses that earn their place. A leading zero means the digits are a code, not a number, so 01803 stays 01803. More than eighteen digits is text. A column with a blank anywhere in it is nullable, so the import does not fail on the first gap in the tail of the file.
Files and images. A file column is a foreign key onto the uploads table and nothing else - no flag, no naming convention - so what DB Craft calls an image cannot drift from what the database enforces. Image dimensions are read out of the header bytes rather than by decoding somebody's upload.
Email. SMTP settings with the password in a sealed vault, a queued outbox with retry, and a test-send button. The operator's view of the queue shows status and never a message body.
A machine-readable API. Every route is described in one table that a test enforces against the filesystem in both directions, so a new endpoint cannot ship undocumented. GET /api/openapi renders it as OpenAPI 3.1 - and the permission each operation needs is in the document, so a client knows it needs manage_users before it calls rather than discovering the model one 403 at a time.
A recovery command line. For the day the permission system is the thing that is broken. It talks straight to the database, and dbcraft user grant-admin is the way back in for a locked-out administrator.
Branding. A six-slot palette, four chrome colours and your logo. A table or a row stores a slot rather than a colour, so repainting a slot repaints everything in it at once.

Waitlist

Want to try it on your own data?

DB Craft is not open to the public yet. Leave your name and we will get in touch when there is something for you to log into - no newsletter, no drip campaign.

Form not loading? Open it in a new tab.

What is actually in the box

Draw the database

Build the screens

Joins, without SQL

Two axes, opposite defaults

Constraints without code

Authentication that survives a review

Scheduled work, and plugins

The operational half

Want to try it on your own data?