Can I ask why SQLite official release does not have 64bit for Windows? I guess with increasing the maximum database size[1], it is a shame that there is no option to handle big memory databases. Is there a technical reason or just no need for it?

[1]https://www.sqlite.org/limits.html

You appear to be operating under a misapprehension regarding the relation between database size and pointer size. The DB engine imposes the same limits whether it is built with 32-bit pointers or 64-bit pointers. Hence, there is no need for "an option to handle big memory databases."

There is a limit of ~2GiB, on the provided build of the shell:

SQLite version 3.39.3 2022-09-05 11:02:23
Enter ".help" for usage hints.
Connected to a transient in-memory database.
Use ".open FILENAME" to reopen on a persistent database.
sqlite> CREATE TABLE example(value INT);
sqlite> INSERT INTO example SELECT VALUE FROM generate_series(0, 300000000);
Runtime error: out of memory (7)
sqlite> .stats
Memory Used:                         2169632 (max 2014973744) bytes

The insert fails due to SQLite being unable to access more than 2GiB of memory.

However, on the same machine with a 64-bit build of the shell:

SQLite version 3.39.3 2022-09-05 11:02:23
Enter ".help" for usage hints.
Connected to a transient in-memory database.
Use ".open FILENAME" to reopen on a persistent database.
sqlite> CREATE TABLE example(value INT);
sqlite> INSERT INTO example SELECT VALUE FROM generate_series(0, 300000000);
sqlite> .stats
Memory Used:                         4207743544 (max 4207753328) bytes

As for providing such an executable: I'd imagine the need for such large in-memory databases is fairly esoteric. I have such a need, but I'm fine with just building the shell myself, since I also want to include some non-standard extensions as well.

Thanks for better showing the point. I guessed with such a world-popular library and with most machines using SQLite Tools using 64bit these days, a proper build and release for them is a proper choice. Yes, you can always build SQLite, but having a well-known URL that you can point to your colleagues (who don't have a C compiler, or not a programmer, and a DB user) and clients is a comfort. And at this point, I guessed asking why not there is not a build for X64. 

There are about 2.4 billion to 3 billion home computers in the world. Around one third of all adults own one.

There are about 6.4 billion to 6.8 billion smartphones (any phone with fullscreen graphics and touchscreen) in the world. Around 3/4 of all adults own one.¹

You can assume SQLite is installed on all the above. If the SQLite developers went by popularity of platform it would put most of its attention on smartphones and care less about home computers.

SQLite is a programmer's tool, not a user's tool. Anyone who is not a programmer (your colleagues in your text above) shouldn't be caring about it. They certainly shouldn't be looking around for libraries to install. If you want SQLite in your project, include the amalgamation C code in your project. Then you can forget about DLL files entirely, and you never have to worry about your users having no, or an incompatible, DLL.

1. ^{^} Ownership figures are averages across various online sources, and take into account one person owning many devices.

If you want SQLite in your project, include the amalgamation C code in your project. Then you can forget about DLL files entirely, and you never have to worry about your users having no, or an incompatible, DLL.

That's the ideal scenario, but there's a catch...

Some Linux distributions truly dislike packages including the amalgamation (namely Debian), at least in part because it keeps them from rolling out "critical updates system-wide" when 27 apps each embed their own copy of sqlite3.c. (Space usage is also an argument, but not one which holds much weight nowadays.) Even within the Fossil SCM project (sqlite3's closest sibling) we've gotten grief from package maintainers¹ about the project including its own copy of the amalgamation, and support use of a system-level copy of sqlite3 with the primary purpose of keeping distribution package maintainers² happy.

That is to say: though including the amalgamation is The Right Way to do it, it may, depending on the project's audience, lead to some level of grief.

1. ^{^} Who are simply passing along the grief from their policy-makers
2. ^{^} And/or their policy-makers

Thank you for the answer, but it seems you completely missed the point. First, I said "most machines using SQLite Tools using 64bit these days" the key part is "SQLite Tools". Second, many DB developers or power users are not professional programmers who can easily compile SQLite. Third, SQLite Tools is a tool for ease of use, and again "most machines using SQLite Tools using 64bit these days", so it can be a proper expectation to have a proper build for the platform.

I hope one of the team members like @drh can comment on this.

DB Developers / Power Users don't typically use a command line tool. They use something like SQLite Expert, SQLiteStudio or Navicat. All of which are 64-bit.

Yes but they are limited compare to SQLite Tools and for example you can not send a script to a client so they can run on a database. eg using the readfile function.

You realise SQLite Tools isn't developed by the same people that develop SQLite, right?

You can grab 64-bit Windows SQLite shell (sqlite3.exe) here: https://github.com/nalgeon/sqlite

It doesn't include sqldiff and sqlite3_analyzer though.

This argument has come up again and again, over the years, and will not be realized ever.

So therefore the closest "official" sqlite 64 bit tool you'll find for Windows would be the one embedded in the fossil scm.

> fossil sqlite --no-repository

As far as I am looking at the repo, it seem @drh is working on them.

It can not be realized, if it cant be find, I searched before posting and couldn't find an asnwer. Thank you, fossil way is a good hack!

SQLite is a programmer's tool, not a user's tool.

I deny.

I am not a programmer but am using SQLite daily for creating and managing my databases since last 4 years, especially on Android phone.

You are right.

On Android I use aSQLiteManager App and in Windows sqlitegui.exe by Little Brother (Git hub).