Versioned registers for any database — without rewriting the application
2B reads an existing database, finds its registers and the references between them, and rebuilds it so that every register keeps its full history. The application keeps working as before.
Every change overwrites the past
Operational systems keep their dictionaries and registers — services, fees, districts, vehicles, applicants — as plain tables.
Plain tables forget
Each update replaces the previous state. The history that audits and disputes need is simply not stored.
No answer for “as of”
Nobody can say what a record looked like on a given date, or which version a past transaction relied on.
Rewrites are not an option
Rebuilding the application to keep history takes years; migrating by hand takes months for every system.
How 2B works
A set of agents connects to the client’s database, analyses its metadata and data, and builds a new database on a versioned-register architecture — with the data carried over and checked.
Analyse
Reads tables, keys and references — declared and hidden. The source database is only read, never written.
Ask
Asks only what the data cannot tell, with the evidence, a recommendation and a confidence level. Every answer is stored with its author and date.
Generate
Builds a versioned model: every register keeps its history with valid-from and valid-to dates.
Load and reconcile
Loads the data in one pass and reconciles every column against the source.
Keep working
A compatibility layer exposes the same table and column names, so existing applications keep running.
Pilot on a government production database
September 2026: every register of the production database of a national government agency migrated and reconciled. The client is not named.
2B also found 610 references without a target — every one of them is broken in the source as well. Problems in the data are reported, not hidden.
October 2026: reproduced on the public Stack Overflow 2010 database — 19.3 M rows, 9 tables, no declared foreign keys. 2B proposed 9 references from column names and checked them against the data: 6 confirmed, 2 rejected because 12–20% of their values point to missing rows. All 5 registers (4.03 M records) migrated and reconciled with 0 mismatches. Data: Stack Exchange Data Dump, CC BY-SA 3.0.
Design principles
One time axis
Application time only: valid-from and valid-to. Simple to query, simple to explain.
Plain tables
No proprietary storage format — the result is ordinary database tables.
People decide
Heuristics are hypotheses. Decisions are recorded and survive every rebuild and re-run.
Every run journaled
What was generated, executed and failed is written to the target database itself.
Roadmap
Alpha
Analysis, model, DDL generation, load, reconciliation and the migration workbench; full pilot on SQL Server.
MVP
Register management interface, write-through compatibility layer, versioning API, access rights.
v1
PostgreSQL and Oracle behind the same interface; partitioning for large registers.
Team
Anton Bukur
Founder — product and engineering. LinkedIn
Contact
Have a legacy database whose registers should keep their history? We would like to hear about it.
ORACOL PRO S.R.L. · IDNO 1022600054129 · Chișinău, Republic of Moldova