Four data shapes hiding in one measurement set

Open a characterization order and you will usually find one folder. Inside it: a parametric table, a set of I–V sweeps, a double-pulse scope capture, and a short list of parts that failed destructively. The lab treats them as files. The database, if there is one, usually treats them as rows with a blob attached. Neither model survives the volume.

The problem is not storage. It is that those four objects are different shapes, and one schema cannot hold them without lying about at least three.

Scalars

Threshold voltage, Rds(on), leakage — a named parameter, a number, units, conditions, and a part identity. This is relational work. You want indexes on part, lot, temperature, and extraction version. You want to ask for the distribution of Vth at 25 °C across the last three lots without unpacking archives. If your "database" is a directory of CSVs, that question already costs a person an afternoon.

Curve families

An I–V family is not a long list of scalars. It is an array: gate voltages as columns, drain current as the response, and a shared condition set. Treating each point as a row blows up cardinality and makes the natural operations — overlay, interpolate, extract a point on the curve — expensive. Array storage (or a typed curve object with a codec) keeps the family together and lets you compare curves without reconstituting them from millions of atomic facts.

Waveforms

Scope captures from switching tests are time series at rates that make full retention optional. You need the raw blob for audit and re-extraction, and a decimated view for browsing. Mixing those two requirements into the same "measurement table" is how query times go from seconds to minutes. Blob plus catalogued metadata (probe setup, deskew, bandwidth) is the boring correct answer; decimation is a policy, not a feature someone invents later.

Small-sample destructive results

Twelve parts taken to failure are not a production distribution. They are a censored reliability experiment. A box plot over those twelve points is the wrong chart — it implies a sample of a continuous process when you have a deliberately small, deliberately destroyed set. Weibull with censoring (and an explicit statement of what was left on the shelf) is what the number means. If your system only stores "value" and "unit," you have already thrown away the statistics.

What a usable model looks like

• A catalogue that names the dataset, the product family, the instrument, the setup, and the extraction version — so two runs can be declared comparable or not.
• Typed stores per shape: relational for scalars, array/curve objects for families, blob plus decimation for waveforms, experiment records for destructive work.
• Tiering: what stays hot for query, what ages to cold, what is retention-locked for qualification.
• Provenance on every released figure — which parts, which conditions, which exclusions, which extraction. Regenerating the figure either reproduces the number or says precisely what changed.

None of this requires a particular cloud. It requires refusing the fiction that measurement data is one table with a file column. Labs that hit the wall usually add more storage. The ones that do not redesign the shapes.