TimeSpaceDB is a time-series database where history is a first-class citizen: reconstruct any past state exactly, branch it to re-run alternatives, and the original record never changes.
Write to us How a proof of concept worksAn AI decision made on Tuesday is questioned on Friday. Can you show what it knew then?
Records get corrected later, so today's data is not what the AI saw. A stricter rule tried on Tuesday's data must not touch the original. And teams building AI agents, programs that act on their own, cannot roll one back or try another path.
A general-purpose database can hold this history, but every query must carry the right time condition, each what-if run needs its own copy of the data, and comparing two runs is written by hand.
A storage layer, not an application framework. Four things it does that your current database does not.
Nothing is overwritten. A new figure or a correction is added as a new version. Rebuild any past state exactly, or re-run it under other rules.
PostgreSQL or TimescaleDB stays the record of current data. TimeSpaceDB keeps the history of what your systems knew, when, and what they decided, and refers to your rows by identifier and hash. It replaces nothing.
Values are stored as written. No AI model summarizes or rewrites them on the way in. A slice handed to a model is deterministic: the same question returns byte-identical context.
In production, TimeSpaceDB is installed on your machines and all of its state stays there. A single static executable plus a data directory, no external dependencies, with an HTTP/JSON API and SDKs for C, C++, Python and TypeScript.
Nothing is overwritten, so any past state can be seen again or replayed under other rules.
How this differs from other branching. Managed database services branch by copying the database, copy-on-write, each branch with its own compute; versioned databases branch by pointing to a commit of tables or files. TimeSpaceDB adds one entry to a timeline and copies nothing, so a branch is cheap enough to open per case, per task or per agent, and its cost does not grow with the number of branches. The trade-offs today: an HTTP/JSON API instead of SQL, a single node, and a younger ecosystem.
For as-of reads, yes, by hand: every write must be an insert and never an update, every table must carry the time a value was true and the version it arrived in, and every query must carry the time condition. The property then depends on that discipline holding in every table and every query for as long as the system runs. For what-if runs, each needs a branch key on every row or a copy of the database. For comparing two runs, a script you write and maintain. TimeSpaceDB makes the property a guarantee of the storage layer instead: there is no update path, a branch is one entry on a timeline, a diff is a query, and the verification suite shows the guarantees hold under a forced stop and a simulated power cut. None of this says PostgreSQL cannot; it says what each approach costs. The proof of concept exists so you can check it on your workload rather than take our word.
Guarantees and observable behaviour, with the limits stated. Each of these is verified in the first phase of a proof of concept.
By version: exact and unlimited in depth. By clock time: resolved to the latest saved version at or before that time; you set how often versions are saved, by time or by number of writes.
Valid time (when it happened) is recorded per point; transaction time (when it became known) is kept per saved version, not per individual entry.
A late arrival or a correction is a new version of the same key, written when it arrives. The original stays.
A branch is metadata only; nothing is copied. Writes on a branch never appear on the parent. Merge is git-like, with conflicts handled by a policy you set. Diff is entity-keyed over a time window and lists the entries that differ.
Up to 1,048,576 branches per store by default (configurable); beyond the limit a new branch is refused with an explicit error and nothing else changes. Branch depth up to 64. Branches are archived, not deleted: an archived branch stays readable and can be branched again.
Memory per agent and per branch: conversation turns, branching at a version, comparison, and a causal trace of what led to what.
Three acknowledgement levels: every write durable before it is acknowledged; every record handed to the operating system before it is acknowledged; or a periodic sync (default one second). With the default level, a process crash loses at most the writes not yet handed to the operating system, and a power cut can also lose up to one sync interval. After a crash a branch is either complete or absent.
Every log record and every data block carries a checksum; the catalog history and the audit log are hash-chained. This covers accidental corruption of data and deliberate changes to the catalog and the audit history, not deliberate byte changes inside data files. Per-file digests, which extend detection to data files, are in development.
Online, crash-consistent copy with no downtime, or a volume snapshot. Restore replays the log; an offline verification tool reports per file and never repairs anything silently.
An export tool and a documented export format from day one. The on-disk format is documented under the annual license.
Scoped API keys or JWTs; each tenant sees only its own data; fail-closed. Authentication failures, denials and administrative actions are appended to a hash-chained audit log.
Single node today. Redundancy relies on the hosting environment: backups, volume snapshots and process supervision.
Append-only by design. A whole store can be deleted today; erasure of individual records is on the roadmap.
Every number below says what was measured, where, and when. Figures on a test environment come in the first phase of a proof of concept, with the scripts that reproduce them.
To open a branch, inside the engine (in-process); about 0.19 ms median through the HTTP API, the way an application calls it. Apple M2 development machine, September 2026.
On disk per numeric point, at one billion points on one node, after compression. Apple M2 development machine, July 2026; evidence records are extra.
Points written per second, sustained: inside the engine at one billion points (log and compaction included) / through the HTTP daemon with 8 to 16 clients. Single node, development machine, 2026.
One yes is enough: do you need to rebuild a past state exactly, try another rule without touching the record, or branch and roll back the state of AI agents? If all three are no, the database you already run is probably enough.
Record each observation and each decision with its evidence. Ask what the system knew at T. Turn a policy change into a branch at T, re-run the later decisions under the new policy, and list the cases that come out differently, while the decisions on record stay exactly as they were.
It does not run your rules, and it does not replace your PostgreSQL or TimescaleDB records.
A snapshot before a run is the baseline. Each risky task works on its own branch; a branch that passes your checks is merged back, a failing one is archived, and the model receives only what was true at the time, as a deterministic slice.
It does not orchestrate agents, and it does not decide what an agent remembers.
Two time axes keep when something happened and when you learned it. A late correction is written as a new version; "what did we know at 10:05" and "what do we know now about 10:00" are both answered, side by side.
It does not decide what counts as evidence; it gives a reproducible reconstruction for your compliance team to use.
Every decision date T is served as of T: the backtest gets the value on record at T, and later restatements do not leak backwards. Alternative rule sets run against the same inputs, each on its own branch, and a comparison lists where their results differ.
It does not provide market data, and it does not run the strategy; your code does.
Memory frameworks decide at write time what to keep, often through a language model. Underneath them, TimeSpaceDB keeps every exact value and every version, so memory can be audited, rolled back and compared, with an as-of notion that similarity search does not have.
It does not extract or summarize; nothing passes through a language model on the way in.
Insurance, healthcare, energy and autonomous systems ask the same questions about what a system knew and why it decided. We have not worked with customers in these fields yet; if you are one, we would like to hear how your case differs.
Three walkthroughs: what an agent does at each step, what TimeSpaceDB records there, and what you can ask afterwards. The rules, the orchestration and the language model stay in your code.
| In your agent | In TimeSpaceDB | Why it matters |
|---|---|---|
| An observation: a quote, a trade, a tool output, a message | A versioned value written at the time it happened, carrying the source identifier and hash you supply | The raw input is kept as written and stays traceable to its source row |
| A decision, with its reasoning | A value on the decision line, with an evidence record (up to 1 MiB) listing the observations used, the policy version and the reasoning | "Why did it decide?" is answered from the record, not reconstructed later |
| A recovery point | A snapshot: a named, saved version of the store | The baseline to return to, compare against, or branch from |
| A what-if, another policy, a risky task | A branch opened at a version; nothing copied; writes stay on the branch | Thousands of alternatives side by side; the main line is never touched |
| "Which cases came out differently?" | A diff between two branches over a time window, entry by entry | The comparison is a query, not a script you maintain |
| "What did the agent know at that moment?" | An as-of read at the version current then | Later corrections and later knowledge stay out of view |
| A correction that arrives late | A new version of the same key, recording both when it happened and when it became known | Both answers remain available: what was true, and what was known |
| Rolling back | Reading at a version, or branching from it; failed branches are archived, not deleted | Nothing is destroyed, so the record of what went wrong stays available |
| Context for the model | A deterministic as-of slice: the same question returns byte-identical context | Two agents see the same facts, and inputs stay small (see the June 2026 evaluation under Evidence) |
Afterwards you can answer: what the agent knew, why it decided, which decisions would change under the new policy, and whether anything on record was altered since.
What we measured: opening a branch takes well under a microsecond in-process; automated tests create 40,000 branches in one store; with 10,000 branches, writes ran at the same rate as with one (Apple M2 development machine).
Division of labour: similarity search stays in your vector store. TimeSpaceDB adds what it lacks: as-of reads, versions, branches and lineage.
One internal evaluation, with its design stated, and what it does and does not show. Your own numbers come from phase 1 of a proof of concept, on your workload.
June 2026. A synthetic scenario: 500 or 5,000 companies publish quarterly figures over eight years, and some figures are later restated. Each question asks for a figure as it was known on a given date. Model: Gemini 3.5 Flash. Five question types, two of them controls; answers scored by exact text match. Three ways of giving the model its context: an as-of slice from TimeSpaceDB (only the values true at that date), a consolidated memory (facts extracted and merged by a model), and the full log.
| Context given to the model | History of about 3K characters | About 89K | About 900K | Over 1M |
|---|---|---|---|---|
| As-of slice from TimeSpaceDB | 100% | 100% | 100% | 100% |
| Consolidated memory | 45% | 40% | 50% | 0% |
| Full log | 100% | 60% | 0% | Quota exhausted |
The slice's 100% comes from the structure: the database selects the version that was true at the date, and the model receives only that slice. It does not mean the model became smarter. The consolidated-memory percentages mix in the control questions.
Context for one as-of question, as a slice from TimeSpaceDB. It does not grow with the history.
The same question with the full log as context: 500 companies, then 5,000. It grows with the history, and past a certain size it no longer fits.
One synthetic company's first-quarter 2024 earnings per share, asked at three dates: three different answers, each correct for its date, each in about 24 to 29 tokens.
The question is the same in both cases: for one company, one figure and one date, what was the value as known on that date?
So the difference is not compression. It is which side does the finding: with the log, the model searches and dates the versions itself; with the slice, the storage engine has already done that, and the slice stays the same size however long the history becomes. The same selection applies to an agent's observations and decisions; what it amounts to on your workload is what phase 1 measures.
Two phases. You validate on your own use case first, then license for your own servers.
A dedicated Linux x86-64 virtual machine in a region you choose, loaded with a dataset your team prepares, without personal data. You use TimeSpaceDB through its API and SDKs. Runs that touch the process or its files, such as a forced stop or a simulated power cut, are executed by us at a time you choose; you watch and receive the logs.
About ten working days of preparation after signing, then four milestones over about six weeks. It ends with an acceptance report and the scripts that reproduce every measurement. A point that does not pass is reported as it is.
TimeSpaceDB is installed in your environment and all of its state stays there. The license includes support, patches and updates, an export tool, and the documentation of the export format and the on-disk format.
Customers license and use the product; the core source code is not delivered.
We take on a small number of teams at a time and work through them in sequence, so the program is small by design.
The paid proof of concept is our default way to start, not the only one. If your situation calls for a different shape, whether a joint development, an integration into your own product, a research collaboration, or something we have not thought of, write and say so. We read every proposal and answer within one week.
A flat fee per deployment, known before signing. Not metered by usage, branches or tokens.
Fixed scope and fixed fee. Half at signing, half on delivery of the acceptance report. Credited in full toward the first-year license.
Standard support, patches and updates included. Single node; multi-node deployments are priced separately. Paid annually in advance; minimum term one year.
In exchange for a reference and a case study after go-live, product feedback and roadmap input.
| Severity | Meaning | Response |
|---|---|---|
| Channel | support@uting-tech.com | Monday to Friday, 09:00 to 18:00 Taipei time (UTC+8) |
| P1 | Production down, data loss or a security vulnerability | Acknowledged within 24 hours, weekends included, with a status update every business day |
| P2 | Major function impaired, workaround exists | Acknowledged within one business day |
| P3 | Minor issues and questions | Acknowledged within two business days |
Response times are commitments; resolution times are targets, which is the usual practice.
TimeSpaceDB is built by UTing Technology Co., Ltd. (優婷科技有限公司) in Taipei, Taiwan. The founder, Teddy (Jing-Ting Xiong), wrote the storage core and leads its engineering; background in semiconductor manufacturing, edge computing and distributed systems.
More about the company, and its other products, at uting-tech.com.
Technical questions, design-partner and proof-of-concept enquiries, investor and institutional requests: one address. We answer within one week.
support@uting-tech.comA written pack is available on request: a three-minute explainer, use cases with evidence, a technical FAQ, and pricing.