Smart Data Engine
Open client libraries, a private control plane and a shared data contract. The next challenges include the integrated AI workflow, workload-qualified migrations and a complete customer setup path.
Work on Smart Data Engine, our open-core data layer, and the specialised engines behind it. The SDKs and control-plane components already exist. The work now is making the whole workflow dependable: placement, migrations and safe access to data.
From the client SDK to the storage engine. The public repositories show the engineering problems, tests and trade-offs you would work with.
Open client libraries, a private control plane and a shared data contract. The next challenges include the integrated AI workflow, workload-qualified migrations and a complete customer setup path.
The low-level half. C++20 with nothing between you and the machine, lock-free structures, seqlocks, cache lines you can count, and bespoke engines for clients whose workload nothing off the shelf fits.
Technical ownership, measurable results and direct contact with clients.
The libraries and control-plane components are working, but key integration and operational decisions remain. Your designs, code and measurements help turn them into a dependable product.
The target is a latency percentile agreed with the client before the work starts. You will profile, count cache misses, and defend numbers instead of opinions.
You sit in the call where the benchmark gets agreed. No one translates the requirement for you, and no one translates your answer back.
Our engines are written for specific hardware and never run in a container, because a container is overhead between the code and the machine. You tune against the real thing.
Real influence, clear expectations and ownership of what you ship.
Not only the code. How we hire, how we review, what we promise a client and what we refuse: those are decisions being made right now, and you would be in the room for them.
You hear the salary range in the first conversation, not after three rounds. It is transparent inside the company and it moves as the company does.
Said plainly so nobody wastes a week finding out. The work happens in the room together, and the hours around that are yours to arrange.
No ticket queue, no six-month roadmap, no handover to a team that owns deploys. You write it, you release it, you watch the graph afterwards.
No whiteboard puzzles. We read code, starting with yours.
A repository, a patch, a write-up of something you made faster. Anything we can actually read. A CV is welcome but it is not the first thing we open.
One conversation, with the person who writes the code rather than with a recruiter. Bring questions about the architecture. They are the interesting part for both of us.
Half a day on something from the actual backlog, side by side. No take-home marathon and no invented puzzle about binary trees.
Within a week, with the reason attached. If it is a no, you get to hear what would have changed it.
What we are looking for right now.
If you can build a control plane, write a storage engine, or run databases that other people depended on, write anyway. Tell us what you built and what it cost you to make it fast.
Send Us Something You Built