Build the infrastructure modern applications depend on.
PLOMID is building a unified data infrastructure platform for modern applications, bringing SQL, documents, vectors, graphs and distributed workloads toward a common data layer.
Open positions
4 open roles. Work on systems where the engineering itself is the product.
4 roles
- Engineering Founding Rust Engineer Build the storage layer behind PLOMID: pages, blocks, WAL, recovery and the durability contract every data model shares.
- Engineering Systems Engineer, Query Execution Run the plan close to the data: vectorized operators, parallel execution and bounded memory per query.
- Operations Infrastructure Operations Engineer Own build, release and test infrastructure: the pipelines and harnesses the engine team trusts.
- Marketing Technical Marketing Lead Explain the system truthfully: architecture writing, documentation direction and launch notes engineers respect.
No roles match these filters.
The problems are hard. That is the point.
Build from first principles
Work close to storage engines, query execution, concurrency, distributed systems and the underlying mechanics of data infrastructure.
Own the system
Small teams should be able to understand and influence the entire stack.
Engineering over theatre
We care about correctness, measurable performance, maintainability and long-term systems thinking.
Long horizon
Infrastructure compounds. The decisions we make today should still make sense years from now.
What you could build.
PLOMID is not another CRUD application. Some areas below ship today; others are the roadmap. The roadmap page says which parts ship today.
Storage
- Physical storage
- Pages
- Blocks
- Checksums
- WAL
- Recovery
- Checkpoints
Query engine
- SQL
- Query planning
- Execution
- Indexes
- Transactions
- MVCC
Data models
- SQL
- JSON
- Time-series
- Vector
- Graph
- Binary data
Distributed systems
- Replication
- Multi-region
- Consistency
- Placement
- Data sovereignty
AI data infrastructure
- Vector workloads
- AI memory
- Retrieval
- Hybrid data models
- Agent data infrastructure
Six rules for the work.
Consistent with the principles the company page publishes. These are the rules the work is held to, not perks.
Correctness before cleverness
The boring implementation that is right beats the brilliant one that is almost right.
Measure before optimizing
No performance claim without a benchmark behind it, and no benchmark without the workload beside it.
Simple systems scale further
Few moving parts, explicit boundaries, no machinery for its own sake.
Own the details
Page formats, error messages, documentation: the details are the product.
Make trade-offs explicit
Every shortcut is written down with its cost, so the future team can revisit it.
Build for the long term
Choose what will still be right years from now, not what demos best this quarter.
Three steps, no theatre.
The process is the work: read the system, write directly, and have the technical conversation the role would actually consist of.
- 01
Read the system first
The architecture page and the roadmap describe how the layer is put together and where it is going. If the problems there look like yours, the next step is short.
- 02
Write to the team
Email [email protected] and say what you would build first. A repository, a design note or a system you have shipped tells us more than a CV does.
- 03
A technical conversation
No puzzles or take-home theatre. A working session about storage, planning or execution. The same discussion the team has with itself, held with you.
Technical partnerships run through [email protected].
Prepare as though it is the job.
The strongest applications show familiarity with the system before the first conversation. Everything below is public and worth your time.
Prepare
- Read the architecture How the layer fits together, and where the hard problems live.
- Skim the roadmap Know what ships today and what is direction before you propose either.
- Run the playground Touch the query surface the team talks about every day.
- Browse the docs See how the team explains its own system, then match that bar.
What we evaluate
- Systems reasoning. How you break down an unfamiliar problem, out loud, with others.
- Engineering judgment. Trade-offs stated plainly, with costs attached, held to the same standard as the work.
- Written communication. Design notes and documentation are part of the job, so clarity on the page counts.
- Evidence over claims. Shipped systems, notes and code carry more weight than adjectives about them.
Every application is read Read by the people building the system, not screened by software or scored by keywords. If the work here is your work, write.