Deploy knowing. Not hoping.
Give Kijun your queries, the targets they have to hit, and the scale you're heading for. Kijun builds each candidate table at that size, measures your queries against a real engine, not a model, and hands back the structure that holds every target. Before you touch production.
sort-order.sql
ready-to-run Iceberg DDL
You choose a structure. You are held to a number.
The decision in front of you is how the table is laid out. What anyone downstream notices is something else: how fast a query comes back, and how much it brings with it. Kijun measures the second one while the first is still a decision.
A number you cannot test is a wish with a unit on it. A number you can test is a requirement.We don't model your table. We build it.
Kijun writes real Parquet files, assembles Iceberg manifests and snapshots, registers the table in a catalog, and runs your queries through Amazon Athena.
Then it finds what in the layout caused each miss: the filter that skipped nothing, the data that had to travel before it could be combined, the aggregate that read the whole table to answer one question. It changes the levers responsible, rebuilds, and measures the whole workload again. Every query, every round. A layout that fixes one query by breaking another doesn't survive.
Three tables. Same rows, same queries. Only one holds.
Same data, same queries, three candidate layouts, measured under query latency and sustained write load.
The write test doesn't ask whether you survive a number you picked. It ramps load until the table stops keeping up, then tells you where that was, and how many months of growth you have before you get there.
Today, every option is bad.
There is only one question, and each query answers it differently. The one behind a search box has about 300 milliseconds before it feels broken. The one behind the month-end close can take a full minute, as long as all 12 million rows come back. Will they still do that when the table is at full size?
Almost nobody writes those numbers down. Not because they don't matter, but because checking them has been the hard part. So you find out what the number really was on the day it fails.
Checking it properly means building the table at full scale, filling it with data that behaves like yours, and running your queries against it. Per table. Per database. Again every time anything changes. So the question gets approximated instead, and every approximation breaks somewhere:
Test on staging.
Copy production data.
TPC-DS or sysbench.
Build the benchmark yourself.
Ship it and pray.
The answer is one bit long. There is no way to read your way to it.
And no, the model won't save you here. It read the same documentation you did. It will just answer faster, and sound more certain.
The decision is cheap. Undoing it isn't.
You define. Kijun measures. You decide.
You define the table
Already have the table? Upload its metadata as a zip. Kijun reads the profile straight out of it, shows you what it found, and leaves blank what it couldn't measure. Those files contain no rows, and none are needed.
Building something new? Describe it instead: the shape, and the volumes you're heading for.
Then the queries, either way. Yours, as written. For each one you say what you need from it: how fast it must return, how many rows it should return, how fresh the data has to be.
That's the profile. Kijun builds a table to match it and measures every result against the targets you set, query by query.
Kijun measures
Synthetic data built to the profile. Never sampled, never derived from anything of yours. Real Parquet, Iceberg manifests and snapshots, and Athena reading them exactly as your engine would.
Candidate layouts run under query latency and sustained write load, at the scale you're growing into. Never your infrastructure.
You decide
A readable report in the UI: which layout won, what it cost, the trade-offs. Export the winning layout as ready-to-run Iceberg DDL. You pick the one that fits.
You also get the maintenance the winning layout was measured under: the compaction interval and snapshot retention the result depends on, the compaction cost the run incurred, and a monthly projection you can see the arithmetic behind. Metered, not estimated. A run that compacted nothing projects nothing.
Every number in the report is a measurement, something you declared, or arithmetic over those two with its factors shown. Nothing is filled in.
Your data has a shape. So does Kijun's.
A fleet of sensors reporting every thirty seconds spreads its rows evenly. A marketplace where twelve sellers do half the volume does not, and those twelve are the ones whose dashboards someone important is watching. Both are normal. They are not the same table to build, and nobody can guess which one you have.
So you set it: which column identifies an account, how much of the data the heaviest slice carries, how far it falls away to the long tail. Kijun works out what you have just asked for and shows you before it writes anything: the top 4% of accounts hold 61% of the rows, about 3.2 million each.
Then it builds to that shape, and checks the layout holds under it. A structure that spreads perfectly across even data can collapse on a heavy tail. The first person to find out is your largest customer.
Don't take the report's word for it.
The tables Kijun measured are real, and they're still there when the run ends. Open the playground, write a query, and watch the rows come back: the same count the report gave you, in the same range. Not a screenshot. The table.
- 01Query the winning layout. Query the ones that lost. Query the winner grown to next year's volume.
- 02Every execution shows you what it scanned.
Your monitoring started the day you installed it.
The query takes 4 seconds. Datadog will tell you that much. It cannot tell you it took 2.5 last year, because it wasn't there. And it cannot tell you whether 2.5 was ever the right answer.
That is what a run leaves behind. Not an average of how things happened to be, but a target for how they should be. Dated, reproducible, and yours to export.
- 01On the roadmap: the baseline is built to plug into Datadog, Grafana, and New Relic so every dashboard has something to measure against. Not built yet.
- 02Rerun on demand after a schema change, an engine upgrade, or a new compaction policy, and keep it current.
Iceberg first. Not Iceberg only.
Apache Iceberg
Apache Iceberg is the only engine Kijun supports today. One database, modeled completely: every lever that shapes an Iceberg query plan, measured against your targets on real metadata and a real engine.
MongoDB is next.
You picked the shard key before you had the data to justify it. You picked the compound index order from a blog post. Now the collection is 400M documents. Nobody wants to be the one who tests the alternative in production.
We're building the MongoDB engine next. No dates. We'd rather ship one engine you can trust than five you can't.
MongoDB's own documentation puts a live reshard of 10 billion documents at three months.