Since March 2026, I've been building 8DB as a solo founder working with AI. I've built and refined native capabilities within days. An expanding core of reusable operations has been part of what makes that pace possible.
For an application team, the opportunity is substantial: a new requirement can become an extension of the engine you already use, with useful operations close to the rest of your data. You can spend more effort on the new question and less on assembling another data system around it.
That development experience is why I expect many missing native capabilities to be added within days. The scope still matters. A useful implementation, an application integration and a qualified customer deployment have different finish lines.
Give the database a new question
A flexible record format can hold unfamiliar data. A native capability adds operations that understand what the data means.
Suppose your application starts receiving measurements with uncertainty. It needs to distinguish a precise reading, a bounded estimate, a reading below the instrument's detection limit and a missing observation. Storing four labels is straightforward. Answering what those observations collectively support requires rules for combining them.
That is where a reusable core becomes valuable. The engineer defines the domain's meaning and connects it to existing operations. The application gains a new way to ask questions, with less machinery to invent and maintain.
8DB's native modalities provide several starting points. Two implemented examples show how the reuse works.
Add a new question to an existing engine.
Storing candidate scores gives you values. Supplying their meaning to a native operator gives you a question the engine can answer.
The frontier operation already exists.
BioTwin supplies its candidate order to 8DB’s existing maximal operation. The application reuses the frontier algorithm instead of writing another one.
- Domain inputCandidate orders
Scores interpreted by a domain adapter
- Reused operationSelect the frontier
Existing lattice::ops::maximal
- Useful outputCandidate indices
Retain the non-dominated alternatives
Which candidates remain worth considering when several objectives conflict?
A frontier retains candidates that no other candidate matches or improves on every axis while improving at least one. It can preserve several alternatives without choosing a single weighted winner.
The new work defines what “better” means.
The inspected BioTwin adapter defines six coordinates: four benefits increase with preference; two costs decrease. Those directions make the same generic operator useful for a new domain.
- Domain policySix chosen axes
Four benefits ↑ · two costs ↓
- Meaning suppliedOrder and value rules
Directions, equality, bounds and rounding
- Native questionWhat is non-dominated?
Apply the shared frontier operation
What does the domain author still own?
Candidate generation, score meaning and valid-value rules. A benefit score remains an estimate or heuristic when its source is one. Frontier membership does not establish biological effectiveness.
Reuse makes the remaining checks more specific.
Check the domain’s order and edge cases, then test the connected application path. The existing operation reduces repeated implementation; its caller still needs a correct contract.
- Semantic checksTies and trade-offs
Equal or incomparable candidates stay eligible
- Change checksFreshness and lineage
An input change can stale its result
- Delivery checksSelected integration
Interface, protection, persistence and recovery
What would make the result useful in a product?
Preserve the original scores, frontier membership and input derivations. Qualify the actual package and update path. Property tests exercise laws; they do not prove every possible input or deployment.
Read all three parts without switching
Shared foundation
BioTwin supplies its candidate order to 8DB’s existing maximal operation. The application reuses the frontier algorithm instead of writing another one.
A frontier retains candidates that no other candidate matches or improves on every axis while improving at least one. It can preserve several alternatives without choosing a single weighted winner.
New questions
The inspected BioTwin adapter defines six coordinates: four benefits increase with preference; two costs decrease. Those directions make the same generic operator useful for a new domain.
Candidate generation, score meaning and valid-value rules. A benefit score remains an estimate or heuristic when its source is one. Frontier membership does not establish biological effectiveness.
Prove behavior
Check the domain’s order and edge cases, then test the connected application path. The existing operation reduces repeated implementation; its caller still needs a correct contract.
Preserve the original scores, frontier membership and input derivations. Qualify the actual package and update path. Property tests exercise laws; they do not prove every possible input or deployment.
Keep the alternatives worth considering
BioTwin, our research application, compares alternatives across several criteria. A single weighted score can produce a convenient ranking, but it also commits the user to a particular tradeoff between benefits, confidence and costs.
The implemented alternative is a frontier: retain the options that no other option improves upon without giving something up. Several can remain worth considering because each has a different strength.
BioTwin supplies the meaning of that comparison. Its ordering uses six coordinates, with benefits increasing in the preferred direction and costs decreasing. It then calls 8DB's existing lattice frontier operation. The application does not need a separate implementation of the generic selection algorithm.
The result also reaches the research graph. Output retains the original scores, marks which alternatives are on the frontier and links to supplied inputs and the method used. That gives a reviewer more to inspect than a winning score.
The scientific interpretation still belongs to the domain. The current scores include heuristics, and the ordering uses an explicit numerical projection. Reusing the selection machinery does not validate the underlying estimates. It makes their comparison and presentation reusable.
Make uncertainty useful in time series
The same foundation supports a different kind of question: what range of values do these observations support, and where is evidence missing?
8DB's typed time-series implementation maps measured and bounded observations into existing interval operations. A missing observation contributes no numerical value. Combining observations produces an enclosing range rather than quietly turning an absence into zero.
The storage integration uses that operation to build summaries for time windows, alongside coverage counts. It writes those summaries through existing transaction machinery. The engineer adds the observation semantics and the connection to stored time-series data; the interval-combination algorithm is inherited. Typed time-series capabilities.
This can support more useful investigation. If a current summary's upper bound is below a threshold, its represented observations cannot contain a value above that threshold. Detailed reads can focus elsewhere, while coverage information keeps missing evidence visible.
The word “current” matters: stored summaries need an appropriate refresh path when inputs change. Reuse supplies building blocks; the implementation must still maintain the relationship between original observations, corrections and derived results.
Reuse the foundation, develop the meaning
These examples reuse algorithms and storage work while adding substantive new behavior. A developer still decides what comparisons mean, how invalid or missing values behave, which operations an application can call and what constitutes a correct answer.
Shared test machinery helps check mathematical properties. Domain examples must also establish that those properties express the intended behavior. Persistence, protection, access policy, updates and recovery need qualification on the actual integrated path. A new type definition does not complete those responsibilities.
Other databases offer meaningful reuse too. PostgreSQL's GiST extension interface lets an author define domain-specific index behavior while the engine provides tree traversal, concurrency and logging. That is a substantial foundation to evaluate alongside 8DB.
The useful comparison is what your required operation can inherit and what your team still has to build. My days-level experience is a firsthand account of developing 8DB, rather than a timed study of competing teams or a delivery guarantee for every request.
Let the next capability compound
An extension creates more value when the next feature can reuse it. A research comparison can feed a graph. A time-series summary can narrow a later investigation. Each useful addition can become another starting point for the application.
That is the commercial promise of a reusable core: more of the next requirement can become product work on an existing foundation. The choice can remain focused on the question users need answered, instead of automatically becoming a new database integration project.
Bring one capability your application is missing and an example of the answer it should produce. Explore it with us. We can identify the existing operations it can reuse, the domain behavior it needs and the evidence required to put it to work.
Continue the technical conversation
Where could this help your work?
Bring a research question, a database workload or an application you want to build. Let’s connect the ideas in this article to an evaluation that matters to your team.
Discuss this work