When nanoseconds are not enough
For most systems, nanosecond timestamps are already more precise than the workload can justify. Application logs, dashboard metrics, industrial telemetry, trades, and ordinary machine data rarely need anything finer. In many cases, the source clock or acquisition path cannot justify that precision anyway.
Quasar has supported nanosecond-resolution timestamps for a long time, and time is a first-class part of the database model. You can ingest time-series data, query by time, aggregate over time, and keep the time axis attached to the data rather than hide it behind an application convention.
But some workloads are starting to outgrow nanoseconds. This is not only a particle physics problem. IEEE 1588-2019, the current Precision Time Protocol standard, improves synchronization to better than one nanosecond, and its high-accuracy profile targets sub-nanosecond accuracy, influenced by systems such as White Rabbit. The timing stack is moving. Databases should not pretend the time axis stops at nine decimal places.
Where the problem shows up
Let’s look at a use case where nanoseconds are far from enough: particle physics.
Particle physics uses accelerators to push particles to very high energies and make them interact with targets, beams, or fields. The goal is not just to “make particles go fast.” The goal is to create events that reveal something about matter, energy, materials, radiation, or fundamental physics. Those events happen fast enough that the timing relationship between signals becomes part of the measurement: which detector saw something first, how far apart two pulses were, whether two measurements belong to the same event, or whether a signal was just noise.
At that level, the unit people often care about is the picosecond. A nanosecond contains one thousand picoseconds. This is not a case where you can find a little unused slack inside a nanosecond timestamp and call it done. If the detector, digitizer, or timing system operates at picosecond resolution, the database now has to represent a different time class.
And picoseconds are not the end of the story. Ultrafast laser experiments live in femtosecond territory: pump-probe spectroscopy, femtochemistry, free-electron laser experiments, and high-harmonic generation all depend on resolving events at that scale. A femtosecond is one thousandth of a picosecond, and one millionth of a nanosecond. So the problem does not grow due to rounding errors. It grows by orders of magnitude. Once you move from nanoseconds to picoseconds to femtoseconds, the timestamp stops looking like “a normal timestamp with extra digits.” It becomes a new representation problem.
That is why these facilities build robust data-acquisition systems around the experiment. Detectors, digitizers, timing systems, FPGAs, GPUs, and custom software pipelines exist to capture what happened before the moment disappears. Entire projects exist just to move that data out of the instrument with enough timing precision to reconstruct the event later. But once the run is over, the data has to live somewhere.
That is where the database problem starts. If the acquisition system captured picosecond or femtosecond timing, but the storage layer rounds it, splits it into helper columns, or hides the real timestamp in payload, the data did not survive cleanly. You may still have the bytes, but you no longer have a clean time axis. Every later query, correlation, replay, and analysis step now depends on a timestamp workaround.
Particle physics is the obvious example because the timing requirements are extreme, but it is not the only one. Semiconductor simulation has the same shape. A processor, memory subsystem, or interconnect operates around nanosecond-scale events, so the trace you use to understand it often needs finer resolution than that. If you simulate or measure something at the same granularity as the event itself, you leave yourself very little room to understand ordering, propagation, and causality.
And we do not think the story stops at femtoseconds. We are already having real conversations with users who see attosecond timestamps as a realistic requirement in the near future. That sounds absurd until you remember that the same thing happened to nanoseconds: first they sounded excessive, then they became normal in the systems that needed them.
How can you solve this?
The first answer is usually: keep the raw files.
That can be the right thing to do at the edge of the acquisition system. You do not want to lose the original run, and for many experimental workflows, the raw file is the source of truth. But raw files are not an analytical system. At some point someone will want to search across runs, compare channels, filter by time range, correlate events, or ask a question nobody thought about when the file format was designed.
If the answer is “parse the raw files again,” you have mostly kicked the can down the road. You preserved the data, but every query now pays the CPU cost of decoding it again. Worse, every analysis tool has to understand the same file format, timestamp convention, and edge cases. That can work inside a narrow pipeline. It becomes painful when the data needs to be reused, queried, joined, or explored.
The second answer is: fit the timestamp into an existing database management system.
That is possible, but it usually means one of the following hacks. You store the timestamp as a BIGINT, with a private unit such as picoseconds since epoch or femtoseconds since the start of the run. You store it as binary and push the interpretation into the application. Or you split the value across multiple columns, for example, seconds in one column and sub-second precision in another.
The difference matters as soon as the data grows. Range filters need custom logic. Ordering may need more than one column. Joins need both sides to agree on the same convention. Compression sees a workaround instead of a clean time axis. The query engine cannot fully help you because, from its perspective, the real timestamp is no longer a timestamp.
And the data volumes are not small. CERN says particles collide in the LHC detectors roughly one billion times per second, generating about one petabyte of collision data per second before filtering. Even after a drastic reduction, the CERN Data Center processed on average one petabyte per day during LHC Run 2, and more recent LHC running has recorded a little under three petabytes per day on disk.
That is the part that compounds the problem. A timestamp workaround on a small dataset is annoying. A timestamp workaround on petabytes of time-indexed experimental data becomes part of the cost model. You pay for it in storage layout, compression, scan speed, CPU time, and every query that has to reconstruct time from something that was not stored as time.
It’s not just a matter of elegance; it’s first and foremost about cost and performance.
How we solved this at Quasar
We realized we needed native support for this use case. Not a workaround, not an encoding convention, and not a “store it as an integer and let the application deal with it” answer. If high-resolution time matters to the workload, the database has to understand it as time.
The constraints were:
- The disk representation had to work well with Delta4C v2 compression;
- The in-memory representation had to stay efficient for scans, aggregations, and analysis;
- The timestamp had to remain easy to partition, filter, and reason about;
- The implementation had to leave enough headroom for future use cases without forcing users into a new timestamp model later.
What we came up with is a generalization of how Quasar already handles time-series data: a larger native timestamp representation, encoded internally as a base plus an offset. That matters because the engine does not need to store every value as a giant absolute counter from epoch at the finest possible resolution. Within a block, Quasar can store a base timestamp and represent each value as an offset from it.
This gives us the precision headroom without throwing away the properties we care about. On disk, the data still has the structure Delta4C v2 likes: nearby values, repeated patterns, monotonic or near-monotonic sequences, and acquisition runs where time advances in a predictable way. The extra theoretical range does not mean every row becomes expensive on disk, because compression removes the parts that do not carry information.
In memory, the timestamp is still native and fixed-size. That keeps scans and aggregations simple. The engine does not have to parse a blob, reconstruct time from multiple columns, or ask application code what a private integer unit means. It can compare, filter, group, and partition on time as time.
The result is that Quasar can support timestamps far below the nanosecond scale, down to femtoseconds, attoseconds, and even Planck-time-scale offsets, if anyone ever has a real reason to go there. That last case is not the point of the feature. The point is that the timestamp model no longer serves as the limit. If the instrument, simulation, or acquisition system can produce the time axis, Quasar should be able to preserve it natively.
Want to try it out?
Ultra-high-resolution timestamps are currently available for select clients, you can request access here. We are especially interested in teams that already have a real sub-nanosecond timestamp problem: scientific instruments, simulation traces, high-speed acquisition systems, semiconductor workloads, or anything else where the usual timestamp model is starting to get in the way.
This change does not affect every Quasar table. High-resolution timestamps are enabled at table definition time, so there is no impact on workloads that do not need them. If nanosecond timestamps are enough for your data, nothing changes. If they are not, you can define the table with the timestamp precision your workload actually requires.
Quasar’s mission is to unlock AI by solving the infrastructure layer below it: the storage, compression, ingestion, and analytical systems that make useful data available in the first place. Sometimes that means working on a feature that looks very small from the outside, like making timestamps behave correctly down to the nanosecond. But in scientific and engineering systems, small gears matter. If this helps researchers, engineers, or laboratories preserve the data they need to do better work, we are thrilled to play that part.
