01
Per-tenant Postgres on your own box
Each workspace gets its own Postgres database on a per-tenant Hetzner box. There is no shared schema. No multi-tenant noisy neighbors. Your row counts and your query plans are yours alone.
Kosh · Sovereign data tables
The Airtable shape, on your own database.
Kosh is what we run when we want Airtable's ergonomics — typed tables, saved views, page drawer, CSV import — but on a database we own and a box we administer. Per-tenant Postgres. No multi-tenant. No vendor reading your rows.
Tables, views, and a Notion-style drawer — sitting inside your tenant box, not on someone else's cloud.
Surface signal
Status
LIVE
Tenancy
Per-tenant
Workspace
kosh.<tenant>.eleven11.pro
Why this exists
Your operating data is too important to live on someone else's cloud.
Every team that grows past a spreadsheet ends up on Airtable, Notion, Smartsheet, or one of their lookalikes. The data on those tools is rarely just notes — it's customer rosters, hiring loops, contract pipelines, partner lists. Things you'd want a copy of when the vendor changes terms or starts training on your inputs. Kosh is what we built so our team — and yours — doesn't have to migrate those tables every two years.
Same shape. Different gravity. Your tables live where your trust lives.
Self-sustained by design
Owned, not rented.
Kosh exists because the operating data of a serious team should not depend on a third-party SaaS pricing change, an opaque AI feature flag, or a multi-tenant cloud's next outage.
02
Direct SQL access, when you want it
Postgres is Postgres. When you outgrow the UI, you don't have to ask permission to run SQL — the database is in your network. Read replicas, custom indexes, pg_dump, all available.
03
Workspace isolation via Postgres RLS
Every server action runs inside `withKoshSession` — workspace ID is set via `SET LOCAL` and row-level security enforces the boundary at the database, not the application. One bug in the app cannot leak across tenants.
04
CSV/XLSX import without an ETL contract
Drop in a CSV, infer column types, get a typed table. The shape we ship is the shape your data already has — no integrations vendor between you and your spreadsheet.
05
Export and deletion are part of the contract
Every workspace can be dumped to plain SQL and imported anywhere Postgres runs. Deletion paths complete and prove they did.
The primitive
Three things you can name. Typed.
Kosh is built on a small, opinionated trio — a table to store typed records, a view to save the ways you read them, and a page drawer to edit them. Everything else is a server action that mutates one of those three.
01 · Schema
Table
tables[]
A schema with columns and types. Every table comes with a default Grid view. The migration that creates the table is what's in the catalog — no ORM-inferred drift.
02 · Saved query
View
views[]
Saved filters, sort, and column-visibility scoped to a table. Each table has exactly one default view — enforced by a partial unique index on `tableId WHERE is_default = TRUE`, not a runtime check.
03 · Editing
Page drawer
/t/[slug]
Click the primary column cell, get a Notion-style side drawer. Click any other cell, edit inline. The shape your team already knows.
How it fits the fleet
The substrate adjacent tools read from.
Kosh is rarely the surface customers think they're buying — but it's the table the rest of the fleet sits on. Architect canvas tiles, outreach prospects, harvester captures, alerts events — they all read and write through the same typed shape.
architect
A Kosh table view appears as a Tier-B canvas widget. Asks recall rows; locked sessions promote rows into citable memory units.
outreach
The prospects table is a Kosh source. Cadence rules, opt-out plumbing, and queue-and-drain workers read from typed rows, not free-text columns.
operator
Structured ops state — runbooks, partner contacts, contract pipeline — lives in Kosh, not in spreadsheets stuffed into a Slack pin.
alerts
Every row create, update, and delete emits a normalized event. The audit trail is the same one platform observability watches.
harvester
Capture jobs land typed records straight into a Kosh table — no intermediate CSV, no manual import step.
granth
Document metadata and citation indices live in Kosh tables, so research findings join the same searchable substrate as everything else.
Surfaces & contracts
Six things you actually call.
Two routes a person opens; the rest are server actions. The smallest contract that does the job.
/
Workspace home
Table list, + New table, Import file, empty-state template picker.
/t/[slug]
Single-table view
Grid + page drawer; supports `?page`, `?q`, `?filters`, `?view`.
/api/health
Health
Public liveness check. The only public endpoint.
createTable / deleteTable
Schema actions
Server actions creating and dropping typed tables.
createRow / updateRow / deleteRow
Row actions
Per-row mutations; all wrapped in `withKoshSession` for RLS.
parseCsv / parseXlsx / importIntoNewTable
Import actions
Type inference + 500-row batched insert with monotonic position.
Senior engineering, visible
The proofs are in the substrate.
Five decisions visible in the migrations, the role grants, and the transaction shapes — not adjectives, design choices.
RLS at the session level
`withKoshSession` sets the workspace ID via `SET LOCAL` for every transaction. Postgres row-level security enforces tenant isolation — not an application middleware that one bug can bypass.
Default-view uniqueness as an index
Each table has exactly one default view. Enforced by a partial unique index, not a runtime guard. The database will refuse to break the invariant.
Bulk insert with monotonic position
CSV imports stream in 500-row batches with monotonic `position` values, so reorderable lists don't fight the database after import.
kosh_app is non-superuser by design
The application connects as a narrow role. Superuser is for migrations only. Every grant is reviewed — no `GRANT ALL ON DATABASE` to make the error message go away.
Schema actions create the default view in the same transaction
`createTable` auto-creates an `All records` Grid view in the same DB transaction. There is no in-between state where a table exists without a view to read it from.
Who this is for
Teams whose data has gravity.
Kosh earns its keep when the cost of someone else owning your operating data starts to exceed the cost of running a database.
Teams whose operating data has compliance weight that doesn't fit a SaaS DPA.
Companies who want Airtable shape without becoming an Airtable customer.
Engineering teams that already run Postgres and want their internal tools on the same primitives.
Architecture-first organizations where 'the schema is your contract' is a real principle, not a slogan.
Operators who need direct SQL access when the UI isn't enough.
FAQ
Final friction, reduced.
How is this different from Airtable, Notion, or Smartsheet?
Those are shared multi-tenant SaaS. Kosh is a per-tenant Postgres database with an Airtable-shape UI on top. You own the data, the queries, and the network it sits in. The migration story is one direction.
Can we self-host without Eleven11 infrastructure?
Yes. The container ships standalone. Bring your own Postgres + reverse proxy that injects an authenticated-user header (Cloudflare Access, oauth2-proxy, your own SSO).
Does it work without an Architect workspace?
Yes. Kosh is bundled with Architect's per-tenant box pattern by default, but its server actions and REST surfaces work standalone. Architect is the most polished consumer; not the only one.
What about real-time multi-cursor editing?
Single-user editing today. Live presence and multi-cursor are deliberately deferred — first ship the primitives, then layer realtime. The pattern matches Manch's lock ceremony for shared workspaces.
Discuss Kosh
Bring your operating data home.
Kosh is partner-deployed today — bundled with Architect's per-tenant box pattern. Talk to us about migration, schema design, or running it standalone.
Direct line
Consultation requests stay owned. We reply from e11 after reviewing fit and timing.