Timelinize: A Self-Hosted SQLite Timeline for Exported Personal Data
Store your data from all your accounts and devices in a single cohesive timeline on your own computer
At a glance
- What is it?
- Timelinize imports Google Takeout archives, chat exports, photo libraries and location history into one SQLite-backed timeline on your own machine. The README is explicit that the schema still changes between builds and that timelines must be recreated when you upgrade.
- Who is it for?
- Adopt Timelinize if you already hold export archives and want to browse them as one timeline on hardware you control, and if you can accept deleting and rebuilding that timeline at each upgrade. Do not adopt it if you need a stable database schema, a supported migration path, or a tool that fetches data from live accounts on your behalf.
- Can I use it commercially?
- Yes, with strict conditions. AGPL-3.0 is a network copyleft licence: if people use a modified version over a network, for example as a hosted service, you must offer them its source code under the same licence.
- Is it still maintained?
- Yes. The repository last received commits 117 days ago.
- What is it written in?
- Mainly Go, according to GitHub's language statistics.
Answers come from the project's GitHub data, last synced on September 15, 2026, and from our analysis. They are not legal advice.
DEEP OPEN-SOURCE ANALYSIS
The problem Timelinize targets: exports that never become a timeline
Personal data arrives as separate archives. A Google Takeout request produces one bundle, a Facebook export produces another, and a phone backup produces a third. Each has its own folder structure and its own idea of what a photo or a message looks like. The README frames the result as data you can keep, but the practical problem is that nothing connects the archives to each other, so a message sent in 2016 sits in a different file tree from the photo taken that afternoon.
Timelinize is aimed at people who want those archives merged on their own computer rather than in a hosted service. The README describes the target audience indirectly through its feature list: family history work, long-term archival, and the kind of person who requests a Takeout archive before it is needed. It is not a backup tool and not a sync client. It reads files you already have and writes a timeline you can browse. The topics attached to the repository (archival, data-import, family-history, self-hosted) match that scope.
How the import pipeline actually works
The README describes a four-step loop. You obtain your data, usually by requesting an archive such as Google Takeout. You import it with Timelinize. You explore and organise the result. Then you repeat as often as you like.
The mechanism worth noting is the second step. According to the README, you do not need to extract or decompress .tar or .zip archives before importing; Timelinize will attempt to recognise your data in its original format and folder structure. That is a deliberate design choice: the importer reads archives in place rather than requiring a normalised staging directory. The same paragraph states that imported data is indexed in a SQLite database and stored on disk organised by date, with no obfuscation or proprietary formats, so the files remain browsable outside the application.
The repeat step has its own behaviour. The README says Timelinize will skip any existing data that is the same and only import new content, which is what makes a periodic re-import of a busy account practical rather than a full rebuild each time. The screenshots section adds two structural details. Entities (people, pets, organisations) are treated as first-class data points, and the README states that Timelinize will automatically recognise the same entity across data sources with enough information, with a manual merge available when it cannot. Conversations are described as emergent from the database by querying relationships between items and entities, which means a conversation view is a query result rather than a stored object.
Getting it running: releases, source builds and what the README does not pin down
The README's download section is short. It points to the latest release on GitHub and says to download the build for your platform, then refers to the website for installation instructions. It does not list package names, container images or configuration keys in the material available here, so any claim about a specific install command would be invention.
What the material does establish is that the project is written in Go and that the README links to a project wiki for instructions on compiling from source. The releases listed are v0.0.28, v0.0.27 and v0.0.26, all tagged in October 2025, with the repository's last push recorded in May 2026. The version numbers are the more useful signal: three releases inside six days at the 0.0.x level indicate rapid iteration rather than a stabilised interface.
The configuration surface visible in the README is the import step itself: you choose archives, and Timelinize decides whether it recognises the folder structure. The README notes that the file picker is custom because browser APIs were too limiting, and that the import flow is being revised. Treat the import UI as a moving part, not a fixed contract.
The schema warning is the real limitation, not a footnote
The README carries a caution block that is unusually direct. It states that Timelinize is in active development and still unstable, that the schema is still changing, and that this necessitates starting over from a clean slate when updating. It advises keeping your original source data and expecting to delete and recreate your timelines as you upgrade to new versions or builds.
That single constraint reshapes how the tool can be used. A timeline is not a durable artefact you maintain across years of releases; it is a view you can regenerate from source archives. Anyone who imports a decade of data, discards the original exports, and then upgrades has lost the work. The README's instruction to always keep your original source data is therefore not generic caution, it is the operating procedure.
The second limitation is scope. Timelinize reads exports. If a service does not offer an export, or offers one the importer does not recognise, there is no documented fallback in the material provided. The README's own framing, that you should request archives early because some services take days to provide your data, makes the dependency on third-party export tooling explicit. The project sits downstream of decisions made by Google, Apple, Meta and others, and it has no control over when those formats change.
Where Timelinize sits next to a general media library
The obvious comparison is a photo manager such as Immich or a media organiser such as PhotoPrism. The difference is in what counts as a record. Those tools are built around media files: an image or a video is the unit, and everything else (albums, faces, places) is metadata attached to it. Timelinize treats items and entities as separate first-class things and derives conversations from the relationships between them, which is why the README can show a text message on a map even when that message carries no geolocation data, using the location of the surrounding context instead.
A second comparison is the export-and-forget approach: unzip everything into a dated folder tree and search it with a desktop indexer. That keeps your files plain, and Timelinize also keeps files plain, but the indexer has no notion of an entity or a conversation. It cannot tell you that the same person appears in a Facebook thread and an SMS thread, which is exactly the merge the README describes as automatic when there is enough information.
The cost of Timelinize's approach is the database. A plain folder tree survives any tool. A SQLite index tied to a schema that the README says is still changing does not, which is why the two approaches are not interchangeable even though both leave your originals untouched.
Licence terms and the cost of keeping a timeline current
Timelinize is licensed under AGPL-3.0. For an individual running it on a personal machine to browse their own archives, the network-copyleft clause is unlikely to be triggered, because there is no user interacting with a modified version over a network. For anyone who modifies Timelinize and exposes it to other users remotely, the AGPL's source-availability obligation applies to the modified version. This is a description of the licence, not legal advice; if you plan to host it for others, read the licence text and take your own advice.
Maintenance cost is dominated by the schema warning rather than by dependency churn. The README's instruction to expect deletion and recreation of timelines means the recurring cost is re-importing archives, not patching. The skip-existing behaviour softens this, since a re-import only processes new content, but a schema change that forces a clean slate removes that advantage entirely: the new database starts empty and the whole archive set is read again. Plan storage and time for that, and keep the exports on a separate volume from the timeline database so a rebuild never risks the source data.
Who should wait
Anyone who needs a stable store of record should wait. The README's own caution block rules out using Timelinize as the only copy of anything, and the 0.0.x release cadence, with three releases in six days in October 2025, suggests the import formats and UI are still being reworked. The README also notes that the screenshots are outdated and that the import flow is being revised, so documentation drift is expected.
The stronger fit is someone who already has export archives sitting on a disk, who wants to see them together without uploading them anywhere, and who is comfortable treating the timeline as a regenerable view. The AGPL-3.0 licence and the plain-file storage make that position defensible. The schema warning is what makes it necessary.
Editorial conclusion
Adopt Timelinize if you already hold export archives and want to browse them as one timeline on hardware you control, and if you can accept deleting and rebuilding that timeline at each upgrade. Do not adopt it if you need a stable database schema, a supported migration path, or a tool that fetches data from live accounts on your behalf. Before committing, verify that the release for your platform installs, that your largest archive is recognised without manual extraction, and that you have kept the original export files, because the README states the schema changes force a clean restart.
Community notes