<title>Long Term Support</title>
<tcl>hd_keywords {long term support}</tcl>

<fancy_format>

<p>
The intent of the developers is to support SQLite through
the year 2050.

<p>
At this writing, 2050 is still 34 years in the future.
Nobody knows what will happen in that time, and we cannot
absolutely promise that SQLite will be viable or useful that
far out.
But we can promise this: we plan as if we will be
supporting SQLite until 2050.
That long-term outlook affects our
decisions in important ways.

<ul>
<li><p>
<b>Cross-platform</b> &rarr;
SQLite runs on any platform with an 8-bit byte,
two's complement 32-bit and 64-bit integers, 
and a C compiler.  It is actively
tested on all currently popular CPUs and operating
systems.  The extreme portability of the SQLite code will
help it remain viable on future platforms.

<li><p>
<b><a href="testing.html">Aviation-grade testing</a></b> &rarr;
Every machine-code branch instruction is tested in both
directions.  Multiple times.  On multiple platforms and with
multiple compilers.  This helps make the code robust for
future migrations.  The intense testing also means that new
developers can make experimental enhancements to SQLite and,
assuming legacy tests all pass, be reasonably sure that the
enhancement does not break legacy.

<li><p>
<b>Extensive, detailed documentation</b> &rarr;
SQLite has candid, developer-friendly,
and open-source documentation.  Docs are written by and
for programmers.
(A few examples:
<a href="./arch.html">[1]</a>
<a href="./fileformat.html">[2]</a>
<a href="./queryplanner.html">[3]</a>
<a href="./opcode.html">[4]</a>
<a href="./compile.html">[5]</a>
<a href="./malloc.html">[6]</a>
<a href="./debugging.html">[7]</a>
<a href="./howtocorrupt.html">[8]</a>)
The extensive documentation helps new developers
come up to speed on SQLite very quickly.

<li><p>
<b>Heavily commented source code</b> &rarr;
The SQLite source code is over 35% comment.  Not boiler-plate
comments, but useful comments that explain the meaning of variables
and objects and the intent of methods and procedures.  
The code is designed
to be accessible to new programmers and maintainable over a span
of decades.

<li><p>
<b>Disaster planning</b> &rarr;
Every byte of source-code history for SQLite is cryptographically
protected and is automatically replicated to multiple
geographically separated servers, in datacenters 
owned by different companies.
Thousands of additional clones exist on private servers around the
world.
The primary developers of SQLite live in different regions of the world.
SQLite can survive a continental catastrophe.

<li><p>
<b>Old school</b> &rarr;
Nobody is completely immune to trends and fads, but the SQLite
developers work hard to avoid being sucked into the latest programming
fashion.  Our aim is to produce timeless code that will be
readable, understandable, and maintainable by programmers 
who have not yet been born.
</ul>

<p>
In addition to "supporting" SQLite through the year 2050, the developers
also promise to keep the SQLite 
[cintro|C-language API] and [file format|on-disk format] 
fully backwards compatible.
This means that application written to use SQLite today should be able to
link against and use future versions of SQLite released decades in the
future.

<p>
Our goal is to make the content you store in SQLite today as 
easily accessible to your grandchildren as it is to you.

<p>
<b>Update on 2018-05-39:</b>
Our goal of supporting SQLite long-term have apparently come to the
notice of the preservations at the 
[https://www.loc.gov|US Library Of Congress] who have identified
SQLite as a [recommended storage format] for the preservation of
digital content.
