The SQLite website has migrated to a new server in a different datacenter, running a different Linux distro. Everything should continue to operate as it always has, from your point of view. But as with all such moves, there is the possibility that something may have broken on the website in the process. So, if you see anything wrong or missing, please let us know about it. Thanks.

I just posted a new thread regarding https://sqlite.org/src/timeline.

Update

There are some performance problems on the new machine that we do not understand yet. So for the time being, sqlite.org is back on the old machine.

Other sites like https://fossil-scm.org/ and https://pikchr.org remain on the new machine for now.

https://www.sqlite.org/ now redirects to https://sqlite.org/

If you really think this kind of thing is necessary, it should be the other way around.

These days, most internet traffic comes from AI robots, not humans. Despite their name, these robots are not intelligent. If they have two different domain names available, say "www.sqlite.org" and "sqlite.org", they will mindlessly crawl every page in them both. Hence, it has become important not to give the robots too many choices. That is why www.sqlite.org now 301s to sqlite.org.

Shorter names seem better than longer names, which is why it is not the other way around.

That is why www.sqlite.org now 301s to sqlite.org.

Not any longer, as of a couple minutes ago. Confusion?

Not any longer, as of a couple minutes ago. Confusion?

That change was reverted because it disrupted lots of downstream automation which was unable to gracefully cope with the redirect.

If you really think this kind of thing is necessary, it should be the other way around.

I disagree. I happen to enjoy shorter names. I am probably one of the very few but, I seldom type "www." on a browser. I go right the name without the www. For example, when I what to go to the SQLite site, I just type "sqlite.org". But I am crazy like that. :-)

Exactly. The shorter, the better.

And the www doesn't tell anything.

Just wanted to let you know that from 2 different computers I received these errors:

computer 1 going to https://sqlite.org/forum/forum
...
The server load is currently too high. Please try again later.

Current load average: 10.549805.
Load average limit: 4.000000
This page was generated in about 0.007s by Fossil 2.26 [c98eec22c2] 2025-04-07 17:08:57 
...
...
computer 1 going to https://sqlite.org/src/timeline
...
The server load is currently too high. Please try again later.

Current load average: 14.732422.
Load average limit: 4.000000
This page was generated in about 0.007s by Fossil 2.26 [c98eec22c2] 2025-04-07 17:08:57 
...
...
computer 2 going to https://sqlite.org/forum/forum
...
The server load is currently too high. Please try again later.

Current load average: 7.068848.
Load average limit: 4.000000
This page was generated in about 0.004s by Fossil 2.26 [c98eec22c2] 2025-04-07 17:08:57 
...
...

I keep "top" running for that server in a window on my desktop all the time, and right now I have "watch 'ps uax | grep althttpd | wc'" running in a second window, all the time. I haven't noticed any large jumps in load. As I type this the load average is 0.24 and there are 106 active HTTP connections. So I don't know why you saw these problems.

When did they happen? Please be as close a possible in your estimates and state the times in UTC.

We did have to run "fossil rebuild" on the main SQLite repository a little while ago, and that burned some CPU cycles. But we haven't messed with the Forum repository.

It was 3-5 minutes before I placed the post. I wish there was a time stamp following the footer "This page was generated.... " phrase. It would have told us the time when it happen. Perhaps something to add to the end of that phrase: "This page was generated....Fossil 2.26 [c98eec22c2] 2025-04-07 17:08:57 (2025-04-07 XX:XX:XX)". Where XX:XX:XX was the specific time when it happened.

"This page was generated....Fossil 2.26 [c98eec22c2] 2025-04-07 17:08:57 (2025-04-07 XX:XX:XX)". Where XX:XX:XX was the specific time when it happened.

That's not a bad idea, but it has to be made separately in each skin so will take more than a minute to implement.

i've marked this in my email box as a near-term TODO.

Hello,

Actually downloads of https://system.data.sqlite.org/blobs/(VERSION)/(ZIPBINNAME) fails with :

Document Not Found The document /blobs/(VERSION)/(ZIBINNAME) is not available on this server

Ex :

https://system.data.sqlite.org/blobs/1.0.119.0/sqlite-netFx-source-1.0.119.0.zip

https://system.data.sqlite.org/blobs/1.0.119.0/sqlite-netStandard20-binary-1.0.119.0.zip

Document Not Found The document /blobs/(VERSION)/(ZIBINNAME) is not available on this server

That's resolved now but only the v119 files are available. There are no plans to restore the older versions.

Getting a Server Overloaded message from lua.sqlite.org.

Its causing issues with the luarocks models.

https://luarocks.org/modules/javierguerragiraldez/lsqlite3 https://luarocks.org/modules/javierguerragiraldez/lsqlite3complete

The server load is currently too high. Please try again later.

Current load average: 2.274414.
Load average limit: 1.500000
This page was generated in about 0.004s by Fossil 2.26 [7ed4d030cf] 2025-04-08 18:02:02

I been running some builds on the server over the past hour or so, which might be why you encountered a higher than normal load average.

• As I type this, the load average is current 0.23
• I raised the limit to 6.0

Every URL beginning with https://sqlite.org/contrib/ returns HTTP 200 but no content.

HTTP/1.1 200 OK
Connection: keep-alive
Date: Wed, 09 Apr 2025 21:12:51 GMT
Content-length: 0

I'm trying to access https://www.sqlite.org/contrib/download/extension-functions.c. Is there a better way to get that?

Yikes. That is a link I had forgotten about. It's an ancient CGI script using an obsolete framework. I'll need to port the application. Please check back in 24-hours to see if I have it working again. Sorry for the delay.

No worries, thanks for the quick reply!

Should be working again now.

Are there any plans to improve resilience by relocating the mirrors (www2.sqlite.org and www3.sqlite.org) to different continents?

Can you share the details of the OS you're using these days? I believe things were hosted on Debian before, correct?

For the previous 10 years or so, the server was running Ubuntu. The new server is built atop Alpine. SB recommended that I look at Alpine, and am so happy that he did, because I found Alpine much easier to deal with when setting up a server like this.

I think that my home IPv4 address is blocked on www.sqlite.org, but not www2 or www3. (I'm writing this from my university connection instead. I used to post anonymously on this forum.) Connections to the website time out; ordinary traceroute reaches the destination, but traceroute --tcp --port=443 sqlite.org times out after the second-to-last hop somewhere in the Akamai network. Could you please let me know whom I can contact about this?

(I originally tried to post this at https://www2.sqlite.org/forum/forumpost/411cf62e352b6073, before I realised that moderation is focused on the main website. I'm sorry for the inconvenience; please feel free to discard either message.)

Edit: As of 2025-09-05, it has been working well for a few days. Unfortunately I cannot tell whether the anonymous comment was right or Akamai needed to fix something.

Your IP address might be one of the 8 IP addresses that are currently null-routed due to excess server load. Every now and then, I'll see the server load spike and after checking, find some robot or run-away wget trying to follow every single link on the website, at a rate of 10 or more per second. In as much as that behavior slows down access to everyone (and runs up my bandwidth charges) I typically add them to the null-route list. The list gets purged from time to time, but not on any particular schedule.

If you care to post your home IP address here, or send it to me via private email, I can check.

Assuming from the nick (my guess it's Russia) and my observation, this may have something to do with how web censorship by technical means in Russia is working now. The ip of the new sqlite.org falls into some range previously blocked for some reasons. It depends on the provider, the current version of a government controlled firewall and probably other details. For me it's working on some computers/networks in Moscow and almost always failing on others.

The OP sent me a trace-route via private email. He is coming from inside of Russia, however, packets are well into North America before they stop being routed, so it doesn't seem like a Russian firewall is to blame here. His IP is not on my null-route list.

The packets make it into Akamai (which is the ISP for the sqlite.org server) but never actually get to my server. I'll send a support request to Akamai and see what they say.

The packets make it into Akamai (which is the ISP for the sqlite.org server) but never actually get to my server.

Martin G. (from the fossil project) has been telling me off-list that his office's (in Canada) access to this domain is also blocked since the move and they have exactly the same symptoms you describe above (i'll post the traceroute to you off-list).

I'll send a support request to Akamai and see what they say.

FWIW, they reached out to their "abuse@" address and got this response:

Please note that, we will no longer be actively monitoring the reports sent to the 
"abuse@akamai.com" mailing address, effective March 1st, 2025 (01/03/2025).

But he has no trouble reaching fossil-scm.org? It's the same IP address. I don't understand.

But he has no trouble reaching fossil-scm.org?

My understanding is that his office (only) can't reach either. Access from his home and mobile network work fine. It started with the server migration, in any case.

These days censorship tools work not only by IP, proto and ports, but also can intercept traffic and decide based e.g. on TLS certificate. So bare traceroute is not necessarily shows the problem...