A field technician edits an inspection while her laptop is offline. At the same time, an agent schedules the follow-up work. The browser closes, the agent retries after a timeout, and both reconnect later.
Which changes are real? Did the follow-up get scheduled once or twice? What can safely continue when no server observed the whole sequence?
Most application stacks answer those questions above the database—with cache policy, retry code, queues, idempotency tables, synchronization logic, and recovery procedures assembled by each application team.
That is a consequence of an older architecture. For decades, building an application has meant choosing PostgreSQL, MySQL, SQLite, MongoDB, or something else, then building the application around it.
You define schemas and migrations. You manage connections and caching. You add queues, replication, and recovery paths. Eventually, the database becomes the place where the application remembers what happened.
That model remains excellent for many centralized applications. But applications are no longer confined to a single server. They run in browsers, phones, laptops, edge locations, containers, serverless functions, and autonomous agents—on machines that may disappear and reconnect at any time.
The constraint is not the database itself. It is the assumption that all meaningful state must pass immediately through one permanently reachable authority.
State is the primitive
An application isn’t fundamentally a collection of tables.
It is a collection of state.
A document has state. A shopping cart has state. A collaboration session has state. An AI agent has state. A workflow has state. A user’s local workspace has state.
The important question is no longer simply:
Where is my database?
It is:
Where does my application state live, and how does it remain correct?
That distinction matters.
If state is the primitive, the application should not have to translate every state transition into a remote storage convention and reconstruct its meaning later.
The database needs to preserve more of that meaning: identity, ordering, authority, and the conditions under which a transition is valid.
Local is not a cache
This is where most architectures still make an assumption that feels increasingly strange.
The browser, server, edge, and agent all have state. But we often treat every copy except the central database as temporary: the browser is a cache, Redis is a cache, an in-memory process is a cache, a local file is a cache.
Then, somewhere in the center of the architecture, PostgreSQL is declared to be the “real” state.
That model works remarkably well when applications are centralized.
It becomes much harder when applications are distributed by default.
If a user can continue working while disconnected, local state cannot merely be a disposable cache. It is part of the application. The same is true of an agent’s durable working state.
If two instances of an application can independently mutate state and later reconcile, the database needs to understand that reality.
FeltDB starts from that premise
FeltDB is a state-first database.
Not a database with a better ORM. Not another hosted PostgreSQL alternative. Not a cache pretending to be durable storage.
Unlike a CRDT library that focuses on merging values while leaving storage and recovery to the application, FeltDB treats durability, operation identity, transactions, and recovery as parts of the same state contract. Unlike a traditional client/server database, it does not require every runtime to pretend that a central server is always reachable.
FeltDB is designed around the idea that application state can exist wherever the application exists.
That means local state can be durable. It can be replicated. It can be synchronized. It can survive process boundaries. It can recover after failure. It can operate without assuming that one machine is permanently authoritative.
And when multiple authorities exist, the system needs a principled way to determine what state is valid.
This is why FeltDB is concerned with things application stacks often push into infrastructure: durability, causality, replication, recovery, deduplication, and authority. In a distributed application, those concerns shape whether state is valid—not merely where it is stored.
Different runtimes need different truths
There is no honest universal consistency token for every deployment, so FeltDB does not invent one.
A remote FeltDB authority serializes commits and advances a durable revision in the same critical section. That revision can answer whether a cached read is current. In the browser, IndexedDB provides a similar serialization boundary across tabs: the storage engine assigns the revision inside the transaction that writes the record.
Replicated state is different. Operations carry durable identity and causal context, and vector clocks describe what happened before what. Two replicas can legitimately hold different state at the same numeric count, so FeltDB refuses to call a scalar counter globally authoritative. That runtime advertises explicit refresh semantics instead.
This is a deliberate trade-off. FeltDB does not claim that every concurrent value can be merged automatically, or that distribution is free. It makes the consistency domain visible, preserves causal order, and surfaces conflicts where application policy is actually required.
For the technician and agent, that means the local inspection can survive offline in browser storage, while scheduling the follow-up can use an idempotency key. Replaying the same request converges on one durable operation identity; reusing that key for different work is rejected as a conflict. When replicated changes reconnect, their causal history is not reduced to “the last packet won.”
Authority should be a capability, not a location
A traditional database architecture often makes authority geographical: the primary database is authoritative because it is the primary database, and everything else talks to it.
But distributed applications don’t always have a single permanent center.
A laptop can be authoritative over its local work. A server can be authoritative over a shared workflow. An agent can own a task while disconnected. Another node can later take over when the first one fails.
This means authority has to become something the system can reason about.
Not:
Which server is the master?
But:
Which authority currently has the right to advance this state, and how can another authority safely recover that responsibility?
That is a fundamentally different database problem.
Recovery is part of correctness
Most systems treat recovery as infrastructure: backups, restart policies, failover scripts, queues, health checks, and disaster recovery.
But if an application depends on state, recovery is part of correctness.
If a process accepts an operation and crashes, did the operation happen? If another node receives it twice, should it apply twice? If an operation arrives before its causal dependencies, should it be rejected, blocked, or stored? If authority moves, what state is safe to continue from?
These aren’t questions you should have to reinvent inside every application.
They belong underneath the application.
This changes what a database should feel like
The promise of a database has historically been:
Give me your data and I will store it reliably.
The next generation needs to be closer to:
Give me your application state and I will help you keep it correct.
That means the developer experience should get radically simpler. Instead of assembling a persistence and recovery system before modeling the application, a durable offline browser can begin with:
import { createFeltDB } from '@feltdb/core';
const db = createFeltDB({
namespace: 'inspections',
browser: true
});The same collection API can connect to a remote authority when centralized serialization is the right consistency domain.
Locally when appropriate. Remotely when appropriate. Across multiple authorities when necessary.
Without making distribution the application’s problem.
One database. Different realities.
This doesn’t mean every application needs to become a distributed system. Most don’t. A classic CRUD application with one durable authority is often exactly right.
The point is to make that simple case simple without making the distributed case impossible. A browser can own durable state, a server can provide shared authority, and a replicated application can use causal history when no global sequence exists.
And an application that starts local should not need to be fundamentally rewritten when it eventually needs to become distributed.
That is the direction FeltDB is exploring.
The database disappears into the application
The best infrastructure eventually becomes boring.
You don’t want to think about connection management every time you save an object, build a recovery protocol every time a worker crashes, or invent synchronization semantics for every offline application and agent framework.
You want to build the application.
The database should handle the state.
That is the thesis behind FeltDB:
Application state should be durable by default, local when possible, distributed when necessary, and recoverable by design.
The database shouldn’t sit outside the application.
It should understand the state the application is built from.