Built to be extended.
Some search problems are universal. Others belong to your business. JemDB keeps a narrow public core while allowing specialized compact storage, filters, calculated values, and sorting to ride alongside it.
One engine. Two layers.
The extension boundary lets JemDB own query execution, partitions, cursors, and concurrency while application code owns the domain-specific representation.
JemDB
- Schemas and typed fields
- Partitions and bitmap filters
- Sorting, limits, and result cursors
- Single-writer, many-reader execution
- General location and distance features
Domain knowledge
- Compact application-specific storage
- Request-dependent calculated values
- Custom filtering and sorting
- Private algorithms stay private
- The same query and cursor pipeline
Vacation-rental prices are not one number.
A nightly stay can depend on arrival date, length of stay, occupancy, fees, availability, and business rules. Storing every possible answer as ordinary rows wastes memory. Calculating everything after search wastes time.
That problem helped shape the extension model: compact source data plus a virtual value calculated for the current request, participating in filtering and sorting like the rest of JemDB.
Keep the specialized representation compact instead of expanding every possible price.
Derive the relevant interval or value from the current search request.
Filter, sort, limit, and stream through JemDB's normal result path.
Ship the reusable engine publicly without publishing proprietary business logic.
Proven as a boundary, still a preview API
The model has already been exercised by a private vacation-rental price extension against real listing data. That gives us more confidence than a diagram and a hopeful shrug. It does not mean the extension API is frozen.
The first public preview focuses on a small custom integer-field interface. It is deliberately narrower than opening JemDB's internals. Extensions can participate in storage and queries without receiving a backstage pass to every engine detail.
What belongs in the public core?
Capabilities that make sense across domains—such as point distance—belong in JemDB. Application-specific pricing, ranking, and compact encodings belong in extensions. The goal is a useful core, not a kitchen drawer.
Have an odd little search problem?
Good. Those are usually the interesting ones. The first preview will include the supported extension surface and examples.