Why build your tools on a database you own — instead of renting a silo per tool.
[Install →] [Apps] — thesis here; install and apps live on their own pages.
App A App B App C App D
| | | |
v v v v
Notes DB Health DB Msgs DB Finance DB
(silo) (silo) (silo) (silo)Every application rebuilds accounts, storage, indexing, and sync. Each stores its own copy of your information. No single system understands the full picture — and none of it is really yours.
Your data is fragmented, duplicated, and outside your control. Your tools are rented.
App A App B App C App D App E
\ | | | /
\ | | | /
+----------------------------------------+
| Your LastDB Database |
| local / permanent / yours |
+----------------------------------------+Applications become clients of the user’s database rather than owners of the data. That inversion is the whole product thesis: not a platform you join, but a foundation you own — every tool you use built on it, including the ones you write yourself.
Applications Brain · Kanban · Situations · yours | v Shared Structures public interfaces, standardized | v Transforms local computation, deterministic | v Vector Embeddings semantic index across all data | v Local Storage yours, append-only
Computation runs locally. The data stays yours, on your machine, in one place.
OWN THE WHOLE STACK
Your tools are clients of your database, not custodians of copies. Swap a tool, keep the data. Nothing about your setup is rented.
BUILD FAST
Declare a schema, write a thin client. A new tool is an afternoon — storage, indexing, and search are already there. No accounts, no ceremony.
DELIVER SLICES
Sharing is a first-class verb: hand a curated slice of your database to a person or an app, on your terms — without giving away the database.
Structures are public and standardized: how data is organized, what you can query, how derived results are produced. Apps can work against any user’s database without custom migrations.
Deterministic functions attached to structures. Outputs are written back into structures — so any tool on the stack can build on any other tool’s results.
Structure: Messages Fields id · sender · recipient · timestamp · body Transforms inbox(user_id) conversation(user_a, user_b) semantic_search(query) unread_count(user_id)
One semantic index across notes, messages, code, and structured records. Search is meaning-based, not stuck to one app’s schema.
A slice is a curated view of your database — a board rollup, a project digest, a dataset — that you deliver to another person or another node. The receiver gets a usable piece of your stack; you keep the source. This is how tools built by one person become useful to another without anyone standing up a platform in between.
LastDB is experimental and in active development. Early releases focus on local storage, apps on top of that node, semantic search, slice delivery, and the agent workflow we use to build it.